1. 事件回顧

6 月 18 日晚，多位網友在技術社區 LINUX DO、V2EX 等論壇貼出復現步驟：在小紅書 App「設置」頁標題處連續點按 6 次（部分說 10 次），隨后在彈出的對話框中輸入弱口令 xhsdev 即可進入隱藏的開發者模式。開發界面不僅提供了日志、抓包和網絡代理開關，還暴露了數據庫表結構、推薦算法參數和多項內部服務地址，被社區稱為“P0 級事故”。

2. 可訪問的敏感信息

根據上述截圖與描述，泄露內容主要包括：

這些信息 并非簡單的“調試彩蛋”，而是足以被黑灰產用來繞過反作弊、批量刷量甚至精準釣魚的高價值情報。

3. 事故成因推測

雖然截至 6 月 19 日凌晨，小紅書官方尚未發布公開聲明，但從常見失誤模式推測，可能觸發路徑包括：

1. CI/CD 流水線混用測試版 (A/B 或內部灰度包) 與正式版簽名或渠道標記混淆，導致含調試開關的構建產物被投放到生產。
2. Feature Flag 配置失控開發者模式原本由后端配置中心控制開關，但灰度期間誤將默認值設為 true，且未限制白名單。
3. 安全審計缺口移動發布流程缺少二進制掃描和動態檢測，對危險字符串、域名、調試 Activity 未做阻斷。

4. 影響評估

5. 行業教訓

1. 生產規范：只要在生產包里，就要被當成公開接口處理。
2. 安全審計前置：移動端灰度 A/B 流程中，安全掃描應與功能測試并行，避免“測試用”邏輯漏到線上。

6. 結語

移動互聯網早期常見的“debug 泄露”在 2025 年依舊重演，證明安全左移與防御縱深依舊是 App 生態的硬剛需。對于年活過 3 億、商業化高速推進的小紅書，這次事故是一記及時而沉痛的警鐘：當技術棧愈加復雜、交付節奏愈加緊湊，唯有把安全內建到工程文化中，才能守住最后的護城河。

閱讀原文：原文鏈接