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 亿、商业化高速推进的小红书，这次事故是一记及时而沉痛的警钟：当技术栈愈加复杂、交付节奏愈加紧凑，唯有把安全内建到工程文化中，才能守住最后的护城河。

阅读原文：原文链接