安全研究人员发现，CPython中存在的一个内存安全漏洞可能让恶意的AI模型模板绕过代码沙箱，在推理服务器内部执行任意代码，这一发现来自RunSybil安全团队。
RunSybil安全研究员达里乌斯·霍尔在一篇博客文章中写道："攻击者利用这一漏洞，可以在负责处理数百万用户请求的服务器中获得立足点。他们还可能直接攻击托管这些工作负载的底层云基础设施。"
研究人员演示了一个经过特殊构造的模型如何利用该漏洞绕过Jinja（一种基于Python的模板引擎，用于构建用户与大语言模型之间的交互结构）的沙箱防护机制，并在服务模型的过程中执行代码。文章补充说，这种攻击可能影响那些允许客户上传并运行自有模型的AI托管服务商，使攻击者有可能在处理多个客户请求的基础设施中获得立足点。
然而，负责处理涉及CPython的安全报告的Python安全响应团队（PSRT）在回复CSO时对此次演示的安全影响提出了异议。该团队表示："我们承认RunSybil报告的底层CPython漏洞，并感谢他们为修复问题做出的贡献。但是，我们不认为所演示的沙箱逃逸属于CPython的安全漏洞。"
双方分歧的核心在于：解释器是否应该负责防止沙箱逃逸。RunSybil认为该漏洞给AI推理基础设施带来了风险，而PSRT则表示，在沙箱中执行不受信任的Python代码超出了CPython的安全威胁模型范畴。
霍尔写道："我们发现的这个漏洞利用了CPython处理泛型类型的方式来实现突破。我们利用沙箱在每个模板中都会提供的对象完成了攻击，即便是在空沙箱环境下也是如此。"
研究人员发现，即使某个对象已经通过回调被修改过，CPython仍可能使用缓存的参数列表。当解释器随后在原始列表中查找一个新引入的参数时，可能会得到一个无效的索引。而用于捕获这种情况的断言机制在正常的发布版本中被禁用，这就使得解释器能够访问预期范围之外的内存。
RunSybil利用这一行为获取了本应被沙箱屏蔽、无法访问的Python对象的引用。
霍尔写道："虽然无效地址通常会导致解释器崩溃，但如果该地址恰好指向一个有效的Python对象，我们的回调就能获得该对象的引用（即使沙箱从未打算暴露这个对象）。"
随后，研究人员利用获取到的对象引用访问了构造可执行代码所需的Python类和函数。
为了演示这种攻击，RunSybil对Qwen2.5-0.5B-Instruct模型进行了修改，植入了一个带后门的chat_template.jinja文件。当该模型通过vLLM等推理服务引擎加载并使用时，这一模板便能在服务进程中实现任意代码执行。
霍尔写道："突破聊天模板沙箱并执行代码，代表了一种供应链风险，会危及推理服务提供商、库开发者以及模型用户的安全。"
研究人员表示，他们已将概念验证漏洞利用代码分享给多家支持"自带模型"（BYOM）功能的推理服务提供商，这一功能允许客户上传来自外部来源的模型。
RunSybil将此问题披露给了CPython、维护Jinja的Pallets Project以及Hugging Face。研究人员称，在应该由哪个项目来解决这一底层问题上，他们遇到了相互矛盾的看法。
CPython方面坚持认为，该解释器并不支持将沙箱化不受信任的Python代码作为一种安全边界。在回复CSO时，PSRT引用了该项目的安全政策，其中指出沙箱逃逸问题应由受影响的沙箱软件维护者负责解决。
该团队表示："因此，此类沙箱的逃逸行为不在我们的安全威胁模型范围之内，应由受影响的沙箱软件维护者加以解决。"
该团队还对RunSybil关于缺乏协调修复流程的说法提出了异议。团队表示，研究人员是通过电子邮件提交的报告，而非通过CPython指定的私有GitHub漏洞报告渠道。
RunSybil向CPython提交了一个补丁，该补丁已于8月14日合并到主开发分支。据PSRT介绍，这一修复也被回溯应用到了3.13、3.14和3.15分支，但是作为常规错误修复而非安全修复处理的。
这一区分十分重要，因为RunSybil曾担忧该修复无法覆盖所有受支持的Python版本。
研究人员表示，未能将修复回溯至Python 3.12，可能会延迟该修复在整个AI基础设施部署中的采用进度。
霍尔写道："鉴于AI生态系统中的大部分力量仍然坚定地锁定在Python 3.12上，我们可能要到2028年末（该版本到达生命周期终止日期时）才能看到这一内存安全修复的自然普及。"研究人员建议，AI托管服务提供商应将沙箱化代码、模板引擎和表达式求值器视为尽力而为型的安全控制手段，而不应将其作为独立的安全边界加以依赖。
本文最初发布于CSO。
