2026-10-24 14:26:32 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

【热点安全风险】10月23日｜LiteLLM 1.107.0 官方包被植入后门，攻击者可窃取云密钥与模型凭据

华顺信安威胁情报中心

2026年10月23日 07:30
湖南

去阅读

PART.01

风险汇总‍‍‍

风险一：LiteLLM 官方发布渠道被投毒，1.107.0 的包与镜像被植入凭据窃取器

LiteLLM 是面向大模型调用的统一网关，常被部署为代理以集中管理各厂商模型密钥、配额与路由。厂商于 10 月 21 日发布事件公告，确认发布到 PyPI 的 1.107.0 被植入恶意代码：七个 wheel 全部受影响，暴露窗口为 11:39 至 13:23；Docker Hub 与 GHCR 上的 v1.107.0、latest、main-latest、main-stable 四个标签同样被替换为恶意制品，浮动标签会让未指定版本的环境在重新拉取时一并中招。载荷通过 cook.pth 与 sitecustomize.py 实现自启动，任何 Python 进程启动都会触发，先收集浏览器保存的口令、SSH 私钥、云与 Kubernetes 凭据、.env 文件以及各类 AI 工具的配置，再拉起常驻进程按远程地址加载代码。1.107.0 的源码标签本身干净，恶意文件是在构建阶段注入、经形近仓库打包的。厂商已下架全部制品、收缩凭据权限并恢复发布流程，要求受影响主机按已外泄处理，轮换代理库中的上游密钥、主密钥、数据库口令与进程环境变量中的凭据，并重新安装锁定到 1.106.2。

建议排查

核对暴露窗口内是否安装过 1.107.0 或拉取过上述标签
检查 site-packages 中是否存在 cook.pth、cook.py 与sitecustomize.py
检索持有 remote\_code\_loader 锁文件的异常 python 进程

加固建议

不要直接重装，先删除恶意文件并终止常驻进程
重新安装并锁定到 1.106.2，镜像与虚拟环境整体重建
轮换该主机可触达的云、数据库与模型厂商密钥

参考来源

https://docs.litellm.ai/blog/security-incident-oct-21-2026

风险二：GMO 互联网集团（GMO Internet）旗下云桌面遭未授权访问，官方称最多 26,739 台客户服务器被植入恶意程序

お名前.com 是日本域名注册商 GMO 互联网集团旗下的域名与主机服务品牌，其桌面云（Desktop Cloud）以虚拟机形态向客户交付可长期在线的远程桌面。厂商于 10 月 21 日在官网发布公告，确认 10 月 20 日在部分客户的服务器环境中发现第三方植入的恶意程序，可能受影响的服务器数量为 26,739 台，服务器内保存的信息存在被浏览的可能，具体细节仍在调查。为阻止影响扩大，厂商自 10 月 21 日 4:00 起按顺序停止客户服务器，桌面云全部套餐暂停，新申请与控制面板登录同时不可用，恢复时间确定后另行通知。公告称目前尚未确认客户个人信息外泄，也未确认被浏览的信息遭到滥用，并说明公司不持有包含信用卡号的支付信息；厂商要求客户尽快修改存放在服务器内的账号口令等认证信息，同一口令用于其他服务的也要一并修改，并提醒警惕借此事实施的钓鱼邮件与电话，强调不会以邮件或电话索要口令与信用卡信息。公告未披露入侵入口与攻击者身份，也未说明是否收到勒索要求。

建议排查

核对是否有业务部署在该云桌面平台上
检查相关服务器是否存放长期有效的密钥与凭据
复核 10 月 20 日以来该平台的登录与操作记录

加固建议

暂停受影响服务器上的业务与自动化脚本
轮换服务器上保存的全部口令、API 密钥与证书
恢复后按最小权限重建实例并开启主机侧监控

参考来源

https://www.onamae.com/news/article/11584

风险三：西门子（Siemens）Software Center 遭 DLL 侧加载在野利用，攻击者可借签名程序在终端执行代码（CVE-2026-110936）

西门子（Siemens）Software Center 是用于下载、安装与激活所购西门子软件并获取更新的桌面客户端。厂商 10 月 15 日发布 SSA-580366 公告，指出该程序会从不受控的搜索路径加载动态链接库（CWE-427），本地攻击者在可写入的搜索目录放置特制 DLL 后即可借该程序执行代码；评分 CVSS 3.1 为 6.7、CVSS 4.0 为 8.4，低于 4.0.9.8 的版本全部受影响。西门子 10 月 19 日追加说明确认该问题已遭在野利用：攻击者把正版签名程序与自己的文件放在同一目录分发，程序本体未被篡改，恶意代码位于其加载的 DLL 中，因为 3.5.8.7 会从自身目录加载辅助文件且不做校验。官方公布的控制端点为 96.62.218.59 与域名 wizardexpensive.com；主机侧特征包括 AppData 下的 SM Software Provisioning Service 目录、与主程序同级的 activate.bak，以及开机项中出现从未安装过的该程序。CISA 已于 10 月 20 日将其列入已知被利用漏洞目录，处置期限为 11 月 3 日。

建议排查

清点终端上 Software Center 版本是否低于 4.0.9.8
检查 AppData 下是否存在 SM Software Provisioning Service 与 FTSuite 目录
检索主机与代理日志中对 96.62.218.59 的访问

加固建议

升级到 4.0.9.8 及以上并只从官方渠道获取安装包
在防火墙、代理与 DNS 上封禁公告列出的地址与域名
禁止用户把网页给出的命令粘贴进运行框或 PowerShell

参考来源

https://productcert.siemens.com/news/2026/10/19/active-exploitation-of-cve-2026-110936-in-siemens-software-center/

风险四：Apache 软件基金会修复 Tomcat 三枚 9.1 分漏洞，未认证攻击者可绕过口令认证（CVE-2026-101296）

Apache Tomcat 是运行 Java Servlet 与 JSP 的应用服务器，大量企业门户与内部系统以其作为 Web 容器。Apache 软件基金会于 10 月 20 日公开三枚评分 9.1 的漏洞，均在 11.0.27 中修复。CVE-2026-101296 位于 JNDIRealm，当该域配置非 GSSAPI 的 SASL 认证机制时，认证流程缺少关键校验步骤，攻击者无需提供正确口令即可通过认证；CVE-2026-101356 是 HTTP/2 处理异步 Servlet 时的对象回收与复用错误，可造成不同用户之间的请求或响应错配，使一方读到另一方的内容；CVE-2026-103119 是大尺寸非阻塞写入触发缓冲区下读，响应体会被拆分到同一连接的下一个请求，可能把前一个响应的数据泄露给后一个请求。三枚均属未认证可达，受影响范围覆盖 11.0 分支早于 11.0.27 的版本，10.1 与 9.0 分支的对应区间同样受影响，已停止维护的 8.5 与 7.0 也在影响之列，官方给出的修复版本为 11.0.27、10.1.61 与 9.0.123。

建议排查

清点 Tomcat 版本与 11.0/10.1/9.0 分支的补丁状态
检查是否启用 AJP 连接器与 HTTP/2 异步 Servlet
核查 JNDIRealm 是否使用非 GSSAPI 的 SASL 机制

加固建议

升级到 11.0.27、10.1.61 或 9.0.123
非必要不启用 AJP，必须启用时限定来源地址
隔离承载多租户应用的实例，减少响应错配的横向影响

参考来源

https://nvd.nist.gov/vuln/detail/CVE-2026-101296

风险五：OpenStack Manila 公共共享接口越权，租户可改动他人共享规则并窃取数据（CVE-2026-71195）

OpenStack Manila 是 OpenStack 的共享文件系统服务，为虚拟机与容器提供可挂载的共享存储。OpenStack 安全团队于 10 月 20 日发布 OSSA-2026-046，披露 Manila 在公共共享相关接口上存在越权问题（CVE-2026-71195，CVSS 3.1 为 9.9）：接口先按调用方自身项目完成授权，再加载另一个项目的公共共享，却没有针对共享的真实属主重新鉴权，因此非属主可以修改他人共享的访问规则、软删除或恢复该共享，也可以为他人共享创建备份。兼容的存储后端会据此改动既有访问规则，导致属主与已授权用户的使用中断。同一公告还指出，导出位置元数据接口没有把查询限定在请求所指向的共享上，已认证的项目成员只要提交自己掌控的共享标识与目标的导出位置 UUID，就能读取、修改或删除他人项目的导出位置元数据，配合公共共享更易利用。受影响版本为早于 20.0.3、21.0.3、22.0.2 的各分支以及 23.0.0，修复已按分支合入 20.0.3、21.0.3、22.0.2 与 23.0.1；未启用公共共享、也不使用导出位置元数据的部署不受影响。

建议排查

清点 Manila 版本是否落在受影响的分支区间
核查是否启用公共共享与导出位置元数据功能
审查跨项目共享的访问规则变更与备份创建记录

加固建议

升级到 20.0.3、21.0.3、22.0.2 或 23.0.1
暂不能升级时关闭公共共享并停用导出位置元数据
对共享访问规则与备份操作设置告警与审批

参考来源

https://security.openstack.org/ossa/OSSA-2026-046.html

风险六：vLLM 推理服务未认证端点存在代码执行漏洞，攻击者可指定模型修订版本加载任意代码（CVE-2026-114053）

vLLM 是面向大模型推理的服务框架，常被用于自建推理集群与内部模型服务。其安全公告披露，0.7.3 起至 0.31.0 之前的版本会把请求中携带的 mm\_processor\_kwargs.code\_revision 原样转发给 Transformers 的 AutoProcessor.from\_pretrained，等于允许调用方指定加载模型动态处理器代码的哪个修订版本。在开启 trust\_remote\_code 的部署中，攻击者只要能在被服务的模型仓库中控制某个修订，就可向未做认证的 /tokenize 端点发送一个多模态请求，使服务进程导入其指定修订的处理器代码，从而在 vLLM 的 API 进程中执行任意 Python。评分 CVSS 4.0 为 9.2、CVSS 3.1 为 8.1，后者因需先取得对模型仓库某个修订的控制而被标记为高复杂度，攻击路径也因此取决于模型来源是否可信。0.31.0 已修复该问题，公告同时给出了对应的修复提交，便于自建镜像核对是否已合入。

建议排查

清点 vLLM 版本与是否启用 trust\_remote\_code
确认 /tokenize 等推理端点是否对公网开放
核查所用模型仓库的写入权限与修订来源

加固建议

升级到 0.31.0 及以上版本
关闭 trust\_remote\_code，改用本地固化的模型目录
对推理端点强制认证并只允许可信网关调用

参考来源

https://nvd.nist.gov/vuln/detail/CVE-2026-114053

PART.02

总体处置建议‍‍‍

总结

本期两条事件指向同一类结构性风险：信任链上游被攻破。LiteLLM 的恶意制品并非源码被改，而是构建阶段被注入、再用形近仓库打包发布，因此校验源码标签、比对官方提交都无法发现问题，只有比对制品哈希或锁定版本才拦得住；其载荷还会读取进程环境变量与代理库中的上游密钥，等于把网关长期储蓄的凭据一次性搬走。云桌面服务则说明托管方一旦被入侵，客户侧的脚本、密钥与自动化任务会同步暴露，官方只能停机止损而无法替客户判断哪些数据被读过。余下四条漏洞中，Tomcat 与 Manila 都是授权边界被绕过：前者由未认证请求触发，可造成跨用户响应错配、或直接就着配置缺陷跳过口令校验；后者需要有效租户，却能让一个项目动到另一个项目的共享规则与备份。这类越权往往没有明显的攻击特征，只能靠版本基线与跨项目操作审计发现。西门子 Software Center 与 vLLM 则分别从终端加载路径与模型处理器加载路径被绕过，两者都不是程序逻辑被攻破，而是信任了不该信任的来源。