原始来源：SafeDep
LiteLLM 是统一调用不同模型服务的开源网关。其官方 10 月 21 日事故说明与 SafeDep 的样本分析确认，1.107.0 的七个 PyPI wheel 包含窃取凭据和加载远程代码的恶意文件；官方 GitHub 源码标签却没有这些文件。受影响 PyPI 包在当天 11:39—13:23 UTC 公开可用，即北京时间 19:39—21:23。Docker Hub 部分标签的受影响窗口为 11:46—14:20 UTC；GHCR 的时间线不同，官方记录在 13:51 已发现相关标签不可用。
官方称，攻击者取得多个开发者凭据后，改动私有发布工作流，使它从外观相似的另一个仓库构建，再经正式流水线签名并发布。团队怀疑凭据来自暴露在公网的内部部署日志，但初始入侵路径仍在调查，不能把怀疑写成已确认根因。SafeDep 对安装产物的分析则说明，恶意启动文件会随 Python 进程执行，应用不必主动导入 litellm 才可能受影响。
官方已移除受影响产物，并建议曾运行这些产物的环境按受损处理，重建环境及轮换其可访问的凭据。处置前应阅读原始公告；简单启动受影响环境里的 pip 也会再次触发 Python 启动逻辑。本刊没有检查读者环境，不据版本新闻判断任何具体服务器是否受影响。
可信度 65 · 重要性 85 · 新颖度 78
技术与主题
Agent 系统 · AI 编程 · Software Supply Chain · Artifact Provenance · Credential Isolation
LiteLLM 事故响应团队
10 月 21 日更新的官方事故报告，状态为已控制事故、调查继续。
忠实转述（非原句）：团队解释，先前已加入私有发布、受信发布者和产物签名，但本次被窃凭据仍被用于改动工作流与通过发布批准。它承认尚未确认攻击者最初怎样进入内部部署，因此保留了调查中的不确定性。
编辑评读
这次事故说明，源码审查、构建授权、产物签名各自回答不同问题。签名可以证明某条被信任的流程签发过文件，却不能自行证明它构建了审查者原本批准的那份源码。攻击者如果改写流程所使用的来源，后面的正式手续仍可能顺利完成。
对 AI 工具团队，可迁移的做法是把“批准的源码标识、构建时实际来源、最终产物”保持可核对的关联，并限制能够同时修改这些环节的权限。这里不是说签名无用，而是要给每项保证写出条件。事故时间线已经支持构建来源被替换；开发者凭据究竟如何被窃取，仍应等待后续调查。
安全响应也不能只以包被下架作为结束：已经运行过的环境与其中可访问的秘密需要另外处理。这一段依据官方现有处置建议，并非本刊执行过清理或独立确认全部影响范围。读者需要的是明确受影响产物和核查入口，而不是从热门标题推断整个生态都不安全。