Claude Code源码泄露事件复盘：Source Map配置不当引发的安全思考

2026年3月31日，一个普通的夜晚，独立安全研究者 Chaofan Shou 正像往常一样结束一天的工作。对他而言，夜深人静时网络通畅，思路也更清晰，是进行安全检查的绝佳时段。

那天晚上，在浏览新发布的 npm 包时，一个名为 @anthropic-ai/claude-code 的包引起了他的注意。

他下载、解压、开始检查代码——这已是他深入骨髓的职业习惯。对于任何新工具，他从不满足于仅仅使用，而是要探究其内部的运作机理。

在检查过程中，dist 目录下 JavaScript 文件末尾的一行注释引起了他的警觉：sourceMappingURL。对安全研究者来说，Source Map 文件有时就像潘多拉魔盒，可能藏着意想不到的东西。他访问了注释中指向的 URL，结果远超预期：返回的并非简单的映射文件，而是一个包含了完整 TypeScript 源代码的巨大 JSON 文件。

这个公开的 R2 存储桶里，存放的远不止编译后的产物。从主入口到核心引擎，从工具实现到命令系统，数百个文件、数十万行原始代码一览无余。完整的注释、清晰的变量名、详细的类型注解，甚至一些尚未公开的实验性功能都暴露在外。

他立刻意识到此事非同小可，随即在社交媒体上发布了一条简短的推文并附上截图。消息不胫而走，整个安全社区为之震动——如此完整的企业级 AI 产品源码遭泄露，在近年实属罕见。

实际上，这已不是 Shou 的首次“重大发现”。在安全研究这个小众圈子里，他早已因专注于挖掘那些容易被忽略的“角落”而小有名气。

让我们简单回顾一下他的部分发现记录：

• 2024年12月：发现某知名 CDN 服务的 S3 存储桶权限配置过于宽松，导致可公开读写。
• 2025年2月：在三个不同领域的热门 npm 包中，发现其 Source Map 均指向公开存储桶并包含完整源码。
• 2025年5月：测试某 AI 公司演示网站时，发现 API 密钥被硬编码在前端 JavaScript 中。
• 2025年10月：分析12个开源项目的 GitHub Action 配置，发现其中直接嵌入了 AWS 访问密钥，存在资源滥用风险。
• 2026年1月：揭示五个热门 npm 包存在“依赖混淆”漏洞，其使用的内部依赖名易与公网恶意包冲突。

他的方法论听起来简单得甚至有些枯燥：每天刷刷 npm，看看有什么新发布的热门包，下载几个，解压，然后重点检查 Source Map。用他自己的话说，驱动这一切的纯粹是“好奇心”——不是为了赏金或名声，仅仅是想知道“这里面到底是怎么工作的”。

这种好奇心，或许是每位优秀安全研究者的共同特质。就像孩童时期热衷拆解玩具以窥其内部结构，如今不过是将玩具换成了软件。他们不满足于黑盒使用，总是渴望理解其原理，并下意识地寻找其中可能存在的薄弱环节。

这次事件给整个行业上了生动的一课。Source Map 作为现代 前端开发 的标配，极大方便了调试。但许多开发者并未意识到，当 Source Map 中的 sourcesContent 字段被启用时，它会包含完整的原始源代码。为了图省事，很多团队会将 Source Map 文件部署在公开可访问的存储桶或 CDN 上，却完全忽略了其中潜在的巨大安全风险。

事件曝光后，Anthropic 反应迅速，很快更新了 npm 包，移除了 sourcesContent 字段，并修复了存储桶的权限配置。不少其他公司也以此为鉴，开始紧急排查自家产品是否存在类似隐患。

对于广大开发者而言，这次事件提供了几条宝贵的安全实践建议。如果项目中必须使用 Source Map，请务必注意：

1. 生产环境禁用：尽可能在生产构建中完全禁用 Source Map 的生成。
2. 避免包含源码：如果确需启用，确保配置不包含 sourcesContent 字段。
3. 严格控制访问：将 Source Map 文件存放在需要身份验证的私有服务器或存储空间中。
4. 发布前检查：建立发布前的安全检查流程，确认没有意外泄露任何敏感信息。

Shou 的发现再次证明，致命的安全漏洞往往隐藏在最司空见惯、最容易被忽视的配置细节中。有时候，培养一个简单的习惯——比如在发布前多看一眼构建产物，或许就能避免一场灾难。

在互联网的阴影面，像 Shou 这样的研究者还有许多。他们可能鲜为人知，却像数字世界的“巡夜人”，用枯燥而细致的排查，默默提升着整个生态的安全水位。他们的工作提醒我们，安全无小事，任何微小的疏忽都可能被放大。

这次对 Claude Code 源码泄露事件的探讨，不仅是一个技术案例分析，更是对开发流程安全性的集体反思。如果你对类似的开源项目安全、前端工程化或更广泛的安全实践话题感兴趣，欢迎来到 云栈社区 与其他开发者一起交流探讨。