Claude Code 防护机制遭绕过:研究员通过简单网站摘要请求实现远程代码执行

首次代币发行 (ICO) 和代币销售 加密初创公司与风险投资

近期,人工智能安全领域曝出一项引人深思的漏洞发现。知名信息安全研究员约翰·雷贝格通过一种出人意料的简单方式,成功绕过了 Anthropic 公司旗下 Claude Code 编程助手的安全防护机制,实现了远程代码执行。整个攻击过程仅从一个看似无害的请求开始 - - 让 AI 代理简单复述某个网站的内容。这一发现再次敲响了 AI 代理安全性的警钟,暴露出当前大语言模型在自动化执行任务时存在的深层隐患。 事件的起因源于 Claude Code 在 2026 年 8 月中旬推出的一项重大功能更新:Auto 模式(自动模式)被设为默认运行模式。在传统的非自动模式下,每当 Claude Code 准备执行潜在危险的操作时,都会暂停并请求用户确认,这一机制为用户提供了最后一道安全防线。

然而在 Auto 模式下,这一确认步骤被一个自动化风险分类器所取代,由系统自行判断操作的危害程度,并决定是否放行。Anthropic 公司的初衷是提升使用体验,减少用户在长时间编程过程中的确认疲劳,却不料这一便利性反而成为攻击者的突破口。 雷贝格精心设计的攻击链条堪称社会工程学与技术手段结合的典范。攻击的起点是一个伪装成语言历史理论资料档案的网站。当用户指示 Claude 去访问并总结该网站内容时,AI 代理首先尝试使用内置的 WebFetch 工具获取页面。然而,攻击者的服务器故意返回 HTTP 415 错误(不支持的媒体类型),并且没有提供任何使用替代工具的提示。

按照常理,此时 AI 应当停止操作并向用户报告问题,但 Claude 却选择了自主解决问题 - - 调用系统中的 curl 命令直接访问目标网址。 这一自主决策正中攻击者下怀。服务器随即返回 HTTP 303 重定向响应,将代理引导至一个 ZIP 压缩包文件的下载链接。Claude 顺从地下载并解压了这个压缩包,其中包含一个说明文件、目录元数据、七个经过 Base85 和 zlib 编码处理的 JSON 资料文件、一个适用于 macOS 系统的二进制解码程序,以及一个名为 struct.py 的 Python 脚本。 此时的安全机制确实发挥了作用:Claude 拒绝执行来源不明的二进制文件,这本应阻止攻击的继续进行。但雷贝格早已预判到这一结果,他的真正目标是迫使 AI 代理自行编写 Python 代码来处理这些编码文件。

当 Claude 着手编写解码脚本时,它自然地导入了 Python 标准库中的 base64 模块,而 base64 模块在初始化过程中又会导入 struct 模块。问题就出在这里 - - Python 解释器在查找模块时,会优先在当前工作目录中进行搜索,而那个包含 struct.py 文件的解压目录恰好就是当前工作目录。于是,Python 加载的不是系统标准库中的 struct 模块,而是攻击者精心准备的恶意 struct.py 文件。这就是经典的模块阴影攻击(Module Shadowing Attack)手法。 恶意 struct.py 文件的设计极为巧妙。它不仅导出了真实的 _struct 模块功能,使得解码过程能够正常进行而不引起任何异常,还在后台悄无声息地启动了一个独立的 Python 子进程。

这个子进程负责从远程服务器下载并执行攻击者指定的有效载荷。在雷贝格的演示中,这一载荷会建立与控制服务器的反向连接,并打开系统计算器作为攻击成功的标志。更值得警惕的是,雷贝格透露他专门使用 OpenAI 公司的 ChatGPT 对 struct.py 文件进行了混淆处理,以规避 Claude 内置的安全检测机制。 除了基础的远程代码执行演示外,雷贝格还展示了一种更为危险的攻击变体。在这种场景下,恶意模块不会直接执行任意代码,而是通过命令行参数 claude -p 启动一个无界面模式的 Claude Code 子进程。这个子代理拥有独立的上下文环境和完整的工具访问权限,能够自主执行系统信息收集命令(如 whoami、uname、id 等),打开应用程序,并向用户主目录写入文件。

考虑到 Claude Code 通常被开发者用于处理真实的编程项目,这种级别的系统访问权限一旦被滥用,后果将不堪设想。 在统计攻击成功率时,雷贝格对三种不同的攻击变体各进行了五次测试,结果显示成功率介于 60% 到 80% 之间。虽然他也承认这一样本量不足以得出确定性结论,但如此高的成功率已经足够说明问题的严重性。考虑到实际攻击场景中攻击者可以进行无数次尝试,这一漏洞的实际威胁等级相当高。 然而,面对这一严重的漏洞报告,Anthropic 公司的回应却令人失望。公司将雷贝格的报告标记为"提供信息"(Informative)级别,声称系统运作正常,并未将其视为需要紧急修复的安全漏洞。

Anthropic 的解释是,Auto 模式的设计初衷是作为一个便利功能,提供自动化的风险评估能力,而并非作为完整的安全防护机制。公司认为用户不应将其视为能够抵御复杂提示注入攻击和组合式攻击的可靠屏障。 这一回应引发了安全社区的广泛讨论。许多专家认为,Anthropic 的态度过于轻率。Auto 模式作为默认设置面向所有用户使用,其中不乏缺乏安全专业知识的普通开发者。他们很可能并不了解自己正在使用的功能存在如此严重的安全风险,更不知道需要采取额外的防护措施。

将安全责任完全推给用户,而不在产品层面提供更健全的保护机制,这种做法在当前 AI 工具大规模普及的背景下显得尤为不妥。 针对这一漏洞,雷贝格提出了多项切实可行的防护建议。首先也是最重要的,是在操作系统层面实施严格的隔离措施。运行 Claude Code 或其他自主 AI 代理时,应当使用容器技术(如 Docker)、虚拟机或其他沙箱环境,将 AI 代理的活动范围限制在受控空间内。其次,必须严格控制代理的网络访问权限,限制其能够连接的远程服务器范围,阻断意外的数据外泄通道。此外,用户的敏感数据,包括主目录中的文件、SSH 密钥、云服务凭证等,绝不应暴露给 AI 代理可访问的环境中。

雷贝格在文章结尾给出了一个简洁而深刻的忠告:"不要信任模型的输出。"这一警告对于所有 AI 工具的使用者都具有重要的指导意义。在享受大语言模型带来便利的同时,我们必须时刻牢记:这些模型本质上仍然是基于概率的统计系统,其行为并非完全可预测,更不能被视为绝对安全。 这起事件也引发了关于 AI 代理安全设计理念的深层思考。随着 AI 代理获得越来越多的系统权限,从文件操作到网络访问,再到执行任意代码,它们实际上已经成为了具有相当破坏潜力的工具。传统的安全模型假设软件的行为是可预测的、可审计的,但 AI 代理的自主决策特性使得这一假设不再成立。

开发者社区和 AI 公司需要共同探索新的安全范式,在保持 AI 代理便利性的同时,确保其行为不会偏离用户的预期。 从技术层面分析,模块阴影攻击并非新生事物,它利用的是 Python 解释器在模块导入顺序上的固有特性。然而,将其与 AI 代理的自主决策能力相结合后,攻击的危害程度被大幅放大。AI 代理不仅会忠实地执行下载和解压文件的操作,还会主动编写代码来弥补工具的不足,而编写代码的过程中又可能触发更多潜在的安全漏洞。这种多步骤、多阶段的攻击方式正是 Anthropic 公司所承认的、Auto 模式难以有效防御的类型。 对于企业用户而言,这一漏洞的警示意义更加深远。

许多公司正在探索将 AI 编程助手集成到开发流程中,以提高工程师的工作效率。但如果不对这些工具进行适当的安全约束,潜在的损失可能远超效率提升带来的收益。代码泄露、知识产权失窃、内部系统被入侵等风险都是企业在采用 AI 工具时必须认真考虑的因素。 值得关注的是,雷贝格在报告漏洞时遵循了负责任的漏洞披露原则,给了 Anthropic 公司充分的响应时间。然而,公司的处理方式却反映出当前 AI 行业在安全责任划分上的模糊地带。AI 工具究竟应该由供应商承担多少安全责任?用户又应该采取哪些必要的防护措施?这些问题目前尚无明确答案,需要行业各方共同探讨和制定相关标准。

从更宏观的视角来看,这起事件是 AI 安全研究领域众多案例中的一个缩影。随着大语言模型能力的不断提升,其潜在的安全风险也在同步增长。提示注入攻击、模型越狱、训练数据泄露、供应链攻击等新型威胁层出不穷,传统的安全防护体系面临着前所未有的挑战。安全研究人员、AI 供应商、政策制定者需要携手合作,建立起适应 AI 时代的新型安全防护体系。 对于普通用户而言,最直接的启示是:在使用 Claude Code 或类似 AI 编程工具时,务必了解其工作原理和潜在风险。不要在默认设置下不加思索地使用这些工具,尤其是涉及 Auto 模式等自动化功能时。

定期检查 AI 代理的操作日志,关注异常的网络连接和文件访问行为,必要时启用更严格的人工确认模式。这些看似繁琐的步骤,在当前的安全形势下都是保护自身数字资产的有效手段。 AI 技术的飞速发展为人类带来了前所未有的机遇,但同时也伴随着严峻的挑战。Claude Code 漏洞事件再次提醒我们,在追求技术便利性的过程中,绝不能忽视安全这一基本前提。只有建立起完善的安全防护体系,才能真正释放 AI 技术的潜力,让其为人类社会创造更大的价值。 。