安全预警｜多起高危漏洞与供应链事件通报

京数安

2026年10月22日 09:44
北京

去阅读

一、通报摘要

2026 年 10 月 21 日，境内外集中披露并发布修复了四起高危漏洞及一起供应链投毒事件。经对厂商官方公告、CERT-EU、加拿大网络安全中心（Cyber Centre）、Mozilla 事件报告及多家安全厂商分析报告逐条核验，以下五项事件的真实性均已确认，关键时间线、影响版本与修复方案与公开来源一致。其中，PHP 预认证远程代码执行漏洞已出现公开概念验证代码并观测到在野利用尝试，属当前处置优先级最高事项；GitLab 免认证远程代码执行漏洞评分为 CVSS 10.0，影响自 2014 年以来的全部自建实例，官方未提供临时缓解方案；LiteLLM 1.107.0 供应链投毒事件已确认造成凭据外泄风险，相关环境应视为已失陷。

事件处置优先级一览

二、事件详情

2.1 PHP 预认证远程代码执行（PHP2Shell）

漏洞编号：CVE-2026-109618、CVE-2026-109619

CVSS 评分：9.2（CVSS v4.0）

漏洞类型：内存破坏、释放后使用（CWE-416）

风险等级：严重

漏洞概述

10 月 21 日 13:30（UTC），PHP 官方发布安全更新，修复两个可在应用代码执行前触发的未认证远程代码执行漏洞，官方将其统一称为 PHP2Shell。

• CVE-2026-109618（OOM 内存破坏）：PHP 通过 longjmp() 中断超出 memory_limit 的请求。当该中断发生在请求数据结构仅部分初始化时（如正在解析 multipart 文件上传），请求清理流程会将无效数据判定为有效数据并释放未初始化内存，该内存可能残留攻击者控制的上一轮分配内容。
• CVE-2026-109619（陈旧全局状态）：请求结束、内存释放后，内部状态未被完全重置。同一工作进程处理后续请求时，可能在正常初始化重置前访问该陈旧状态，构成释放后使用。官方已确认 session.upload_progress 为其中一条可利用路径。

影响范围

所有处理 Web 请求的 PHP 部署方式均受影响，包括 PHP-FPM、Apache mod\_php、php-cgi、FrankenPHP 与 LiteSpeed。官方判定mod\_php 风险最高，已演示的攻击链可在应用代码执行前由单个未认证请求触发。

第三方产品、设备与容器镜像中内嵌的 PHP 组件同样受影响，建议参照 NCSC-NL 维护的受影响软件清单进行比对。

利用状态

截至 10 月 22 日，公开概念验证代码（PoC）已流传，并已观测到在野利用尝试。CERT-EU 评估认为攻击者利用的可能性正在上升。

修复方案

升级完成后必须重启Apache、PHP-FPM 及所有常驻工作进程，确保新运行时生效。使用 Remi 第三方源的环境，该源在发布当日不提供更新，建议改用发行版官方软件包或自行编译。

临时缓解措施（不能替代升级）

官方明确说明，以下措施仅能降低特定攻击路径的暴露面，无法使系统达到安全状态：

• 将 memory_limit 设置为 -1，并通过 php_admin_value 等应用无法覆盖的方式配置，同时确认无其他 pool 或 .user.ini 重新设置有限值；
• 将 post_max_size 降至 8M（无文件上传场景）或 32M，并确保 upload_max_filesize 小于该值；
• 设置 session.upload_progress.enabled=0 并重启全部工作进程；PHP 8.5 环境同时设置 fatal_error_backtraces=0；
• 不得以 RLIMIT_AS 或 RLIMIT_DATA 替代内存限制，此类配置可能主动触发漏洞路径；
• 在 Web 服务器或反向代理层限制解码后请求体积、输入字段数、multipart 分段数、请求头数量及嵌套深度。

排查建议

升级后重点监测：异常 multipart 请求伴随内存超限错误、HTTP 500 响应激增、异常增大的 PHPSESSID Cookie、无法解释的工作进程重启。

2.2 GitLab 免认证远程代码执行

漏洞编号：CVE-2026-110264CVSS 评分：10.0（CVSS 3.1，AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）漏洞类型：整数溢出（CWE-190）风险等级：严重

漏洞概述

10 月 21 日，GitLab 发布关键补丁版本，修复正则表达式编译器中的整数溢出漏洞。攻击者构造特制正则表达式触发溢出后，在特定条件下可实现未认证远程代码执行。

漏洞位于 GitLab 自行打包分发的 Ruby 正则引擎 Onigmo 中，因此自 7.0（2014 年）起的全部自建实例均在影响范围内。GitLab 未公开利用前置条件，管理员无法通过配置排除自身风险；官方亦未提供临时缓解方案，升级为唯一可靠措施。

GitLab 同步发布两条检测规则（Sigma 格式，基于应用日志）：Onigmo native worker crash与Org mode render error burst，指向 Org-mode 文件渲染路径。据此判断，具备一个可存放特制 .org 内容的公开项目可能即为主要暴露条件。

影响范围与修复版本

其中 18.11.13、19.0.10、19.1.9、19.2.9 为 GitLab 超出常规维护策略的例外 backport，通常仅用于极严重问题。

重点提示

10 月 12 日 GitLab 曾修复同类满分漏洞 CVE-2026-97229（影响 19.2 及以上，修复版本 19.2.8 / 19.3.5 / 19.4.2）。已按该批次完成升级的实例，本次重新落入受影响范围，须再次升级。

升级影响

19.4.3 与 19.3.6 包含数据库常规迁移，19.4.3 另含 post-deploy 迁移。单机部署在迁移期间将停机，须提前安排维护窗口；多节点部署在满足负载均衡、高可用、逐个小版本升级及迁移顺序等条件时，可采用零停机升级流程。

升级前准备

• 确认部署方式与精确版本（帮助 → 帮助 页面可查），注意 GitLab.com 与 GitLab Dedicated 已运行修复版本，无需处置；
• 执行 gitlab-rake gitlab:check 健康检查，确认无未完成的后台迁移；
• 备份须包含 secrets 与配置文件，并预先验证回滚方案；
• 如怀疑已失陷，先行留存 Rails 异常日志、Puma worker 错误日志、Workhorse 日志及可疑载荷文件。

失陷判定与响应

GitLab 明确说明，成功利用不必然导致进程崩溃，检测规则无告警不能证明实例安全。一旦发现代码执行迹象，应按失陷处置：轮换实例密钥、全部 CI/CD 变量、Runner Token 及访问令牌。

利用状态

截至 10 月 22 日，GitLab 未报告在野利用，该漏洞未列入 CISA 已知被利用漏洞目录（KEV），暂无公开 PoC。

2.3 LiteLLM 1.107.0 供应链投毒事件

事件性质：开源组件发布流程遭入侵，恶意制品进入官方分发渠道风险等级：严重利用状态：已发生（第二次，本年度）

事件概述

10 月 21 日凌晨，攻击者利用三组窃取的 GitHub CLI OAuth 令牌，绕过分支保护、通过生产发布审批关卡，并删除工作流执行记录，使官方发布流水线对仿冒仓库 Berri-AI/litellm（与正牌 BerriAI/litellm 仅差一个连字符）执行构建，恶意制品经官方渠道发布。

暴露窗口（UTC）

重要：恶意文件仅存在于构建产物中，GitHub 官方 v1.107.0 源码 tag 与 sdist 均不含恶意内容。仅审查源码或比对 Git tag 的流程无法发现该风险。

恶意载荷构成

三个文件被写入 site-packages 根目录：

由于 .pth 与 sitecustomize.py 均在解释器启动阶段自动执行，即使应用从未 import litellm，只要在该环境中启动过 Python 或 pip，恶意代码即已运行。

窃取目标

SSH 与 GPG 密钥、AWS/GCP/Azure 凭据（含实例元数据）、Kubernetes 配置、CI/CD 密钥、浏览器保存的口令、包仓库访问令牌、15 类以上 AI 编码工具令牌，以及 LiteLLM proxy 数据库中存储的全部模型服务商密钥、master key 与 virtual key。

处置流程（须严格按序执行）

1. 禁止在受影响环境中执行 pip install 或 python，任何解释器启动都会再次触发载荷；
2. 手工删除各 site-packages 目录下的 cook.pth、cook.py、sitecustomize.py，及对应 __pycache__/cook*.pyc、sitecustomize*.pyc；
3. 终止持有 /tmp/remote_code_loader.lock 的分离式 Python 进程；
4. 回退并锁定至 litellm==1.106.2，建议从零重建镜像与虚拟环境；
5. 轮换宿主机可访问的全部凭据，包括实例角色、LiteLLM proxy 数据库内全部服务商密钥、master key 与 virtual key、DATABASE_URL 口令；
6. 核查云审计日志：安装时段是否存在来自实例角色的 GetCallerIdentity 调用，该角色凭据是否在基础设施外部被使用。

失陷判定原则

在可出网的宿主机上安装过 1.107.0，应默认数据外泄已成功；标记文件存在可确认外泄，不存在不能证明环境干净。

影响边界

历史版本、GitHub 官方源码 tag 及企业私有镜像仓库客户不受影响。当前观测到第二阶段载荷处于休眠状态（domain.txt 内容为空），但该文件可随时被重新填充以激活后门。

本年度该组件已两次遭投毒（3 月为 1.82.7 / 1.82.8，攻击者 TeamPCP 经 Trivy 供应链获取 PyPI 凭据，并横向扩散至 Kubernetes 节点、植入持久化后门），两次事件中 GitHub 源码均为干净。

2.4 Node.js 安全版本更新

修复版本：v22.23.4、v24.22.1、v26.12.1发布时间：10 月 21 日漏洞数量：10 项（高危 4 项、中危 3 项、低危 3 项）风险等级：高

高危漏洞

CVE-2026-111497 的触发条件为解压不可信数据，Web 服务的 Content-Encoding: br 处理、HTTP 客户端及代理链路均在风险范围内。

中危及低危漏洞

涵盖 keep-alive 套接字响应错序、非规范 IPv4 主机名的证书校验缺陷、crypto.randomUUID() / randomInt() 熵缓存被写入用户态启动快照与单文件可执行程序（SEA）导致进程重复产生相同随机值、ZIP 头校验失败后返回攻击者可控字节，以及权限模型的路径通配与 fs.realpathSync 绕过。

同步更新的依赖

根证书列表升级至 NSS 3.131.1，并新增被吊销中间证书黑名单机制，拒绝包含 eMudhra 受影响公钥的证书链；同时更新 c-ares 1.34.9、Undici、OpenSSL 3.5.9、SQLite 3.53.4。

处置要求

升级至对应分支修复版本；以 SEA 或启动快照方式打包的应用必须使用新版本重新构建，否则熵缓存中的重复随机值不会消除。

截至 10 月 21 日，未见在野利用报告，亦无公开 PoC。

2.5 eMudhra 中间 CA 私钥可被公开恢复

事件性质：证书颁发机构密钥生成缺陷，导致私钥可被任意恢复风险等级：高利用状态：未见伪造终端证书签发记录

事件概述

10 月 21 日，eMudhra 发布正式声明，确认其全球 TLS 业务下 8 张中间 CA 证书（6 张 TLS、2 张代码签名）的私钥随机性严重不足，任何人均可推算出对应私钥。

根因为 2025 年 4 月 30 日在该公司 ECC 根下进行的密钥生成仪式（KGC）。仪式脚本存在缺陷，在 wrap/unwrap 环节于原有强密钥之外额外生成了一套弱密钥，且标签高度相似，导致工作人员将弱密钥写入证书签名请求，其中包括提交给 Sectigo 做交叉签名的请求。受影响私钥应为 384 位随机数，实际仅为单字节整数：

4、56、66、115、155、156、230、237

响应时间线（UTC）

影响评估

浏览器强制证书透明（CT）机制，且 CT 日志显示封禁前无任何终端证书签发记录，浏览器用户未受实质影响。封禁后已观测到使用重建密钥为知名域名签发约 10.5 万张证书的行为，均被浏览器拒绝。

风险集中在不检查吊销状态、不强制 CT 的客户端：Go 程序、Python（certifi）、Node.js、Java、git 及各类包管理器，它们仅信任磁盘上的 CA 证书包，吊销对其不生效，直至证书包或运行时本身更新。

修复版本

处置要求

• 容器镜像须重建。 证书包在构建时冻结，宿主机更新对运行中镜像无效，须重新构建、重启并重新部署；
• Java cacerts 独立维护，每个 JDK/JRE 携带自有密钥库，单机可能存在多份；
• Go 二进制须重新编译，仅升级构建机工具链不改变已部署二进制，可用 go version <二进制路径> 核查；
• 双向 TLS 须重新评估。 一张受影响中间证书带 clientAuth 用途，若服务接受任意公共 CA 签发的客户端证书，风险即在此处；
• 静态信任库须重建。 网络设备、负载均衡、防火墙、IoT/OT 设备的固件内置证书包依赖厂商发布；
• 关注交叉签名路径。 即使 emSign G3 根被移除，仍留在部分旧平台根列表中的 Sectigo AAA Certificate Services 可提供第二条受信链；
• 持有 emSign 签发证书须在 10 月 27 日前完成替换。 Chrome 移除 G3 根将于 10 月 27 日（美西时间）全量生效，约 3 万张证书受影响，其中约 97% 通过 ACME 签发可自动重签。

根因旁证

2025 年 11 月，即仪式半年后，6 张 TLS 中间证书的 CRL 签名校验开始失败，Sectigo 已向 Mozilla 报告。当时 eMudhra 使用与证书匹配的密钥重新签署 CRL（该密钥即弱密钥），并将工单作为流程错误关闭。CRL 验签失败意味着签发密钥与证书不匹配，该现象在密钥生成仪式后数月出现，本应触发对密钥生成流程的核查。

三、处置要求

3.1 排查范围

3.2 时间要求

四、风险提示

1. GitLab 12 日升级不等于已修复。 10 月 12 日批次仅覆盖 19.2 及以上分支，本次修复版本位于其上一补丁位，已升级实例仍在影响范围内。
2. 源码审查无法发现 LiteLLM 投毒。 恶意文件仅进入构建产物，sdist 与 Git tag 均干净。依赖引入应校验实际安装的 wheel 内容与其 RECORD 清单。
3. 证书更新不等于生效。 容器镜像、虚拟环境、Java 密钥库、Go 二进制各自携带证书包副本，须逐一重建，无法通过宿主机更新统一解决。
4. 缓解措施不等于修复。 PHP 官方明确说明临时缓解仅降低特定路径暴露；GitLab 未提供任何临时缓解方案。
5. 无告警不等于未失陷。 GitLab 与 LiteLLM 两起事件均存在\"静默成功\"可能，安全设备无告警不能作为排除依据。

五、参考资料

1. PHP 官方安全公告，2026 年 10 月 21 日
2. CERT-EU Security Advisory 2026-018，《Critical Vulnerabilities in PHP》
3. 加拿大网络安全中心 Alert AL26-026
4. GitLab Critical Patch Release：19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13
5. Node.js，《Wednesday, October 21, 2026 Security Releases》
6. LiteLLM 官方事件通告，《Security Incident October 21, 2026》
7. JFrog Security Research、Datadog Security Labs、Upwind 相关分析报告
8. Cisco Talos，《Compromised eMudhra Intermediate Certificates》
9. Mozilla 事件报告及 eMudhra 2026 年 10 月 21 日公告