2026 年 10 月中下旬安全事件梳理

By 陈成 · Published October 22, 2026

2026-10-08 至 10-22 公开的安全事件：影响、核实状态与处置优先级

• 整理日期：2026-10-22
• 覆盖范围：2026-10-08 至 10-22 公开的安全事件
• 材料来源：厂商与项目的官方公告、安全研究机构分析、相关 X 线程和 GitHub issue/PR，以及一篇微信综述文章中的说法（已逐项核实）。详见文末来源列表
• 可信度标注：已确认 指有一手公告或多家独立机构交叉证实；二手 指只有媒体或第三方转述；未证实 指只有当事方或攻击方的单方说法

摘要

1. 造成实际损失的主要是凭据泄露。 Zeabur（明文、永不过期的管理令牌）、LiteLLM（被盗的 GitHub CLI OAuth 令牌）、OpenCode Console（托管的第三方 API Key）、TiDB Cloud（被盗的服务账号凭据）都是一组凭据泄露后被横向放大。PHP、Node.js、GitLab 的 RCE 关注度更高，但目前已确认的损失主要来自凭据类事件。
2. PHP 核心 RCE 已有在野利用尝试和公开 PoC，是本期唯一确认被利用的软件漏洞，需要当天处理。目前公开 PoC 只在 ARM64 或关闭 ASLR 的 x86-64 上能稳定 RCE，但这道门槛预计很快会被突破。
3. eMudhra 中间 CA 事件的风险在浏览器以外。 主流浏览器强制证书透明度（CT），伪造证书无法通过；暴露面在语言运行时、操作系统自带工具、代理/VPN 和 IoT 设备。mitmproxy 已内置利用选项，复现已经不需要密码学知识。
4. 漏洞发现和利用的速度都在提高。 AI 辅助扫描批量产出高危报告，补丁发布后通过补丁比对生成利用的时间在缩短。这是趋势判断，目前没有量化数据支撑。

事件总览

1. PHP 核心未认证 RCE（CVE-2026-109618 / 109619）

可信度：已确认（php.net、Cisco Talos、watchTowr、VulnCheck、Datadog Security Labs）

概况：PHP 核心中的两个漏洞，CVSS v4.0 均为 9.2，可在未认证条件下远程执行代码，影响范围可追溯至 PHP 5.4。

关键事实

• 修复版本：8.5.12 / 8.4.27 / 8.3.36 / 8.2.35（10-21 发布）。
• php.net 指出 mod_php 部署风险最高，已有可在应用代码运行前触发的利用演示。
• 披露过程：漏洞细节于 10-20 约 15:20 UTC 在禁运期结束前流出，补丁于 10-21 14:00 UTC 发布。
• 在野利用：Talos 截至补丁发布时未观察到；watchTowr 蜜罐网络记录到 10-21 当天已出现在野利用；VulnCheck 观察到使用 php2shell-scan/109618 UA 的扫描，以及一次经 session upload-progress 路径植入 webshell 的尝试（未成功）。Datadog 称有多家厂商报告利用活动，并转引 AWS 称利用尝试最早始于 10-17，即补丁发布前四天（AWS 原始通报未找到）。应按“已被利用”处理。
• 公开 PoC（截至 10-22 05:30 UTC，据 VulnCheck）：GitHub 上已出现数百个 PoC 仓库，绝大多数无效，部分可能夹带恶意代码。合格的公开 PoC 只能在 ARM64（ASLR 可暴力绕过）或关闭 ASLR 的 x86-64 上实现 RCE；目前没有公开 PoC 能在开启 ASLR 的 x86-64 上独立完成 RCE。VulnCheck 自己的商业利用已能在 x86-64 + ASLR + display_errors=off 的 PHP 8.4.26 上实现 RCE，说明这道门槛可以突破。
• FPM：CVE-2026-109619 的上传处理路径在 mod_php 和 PHP-FPM 上都已确认；在 FPM 上还需要应用在启动后执行特定操作。php.net 称所有 Web 部署（含 FPM）均受影响。
• EOL 分支：7.4、8.0、8.1 没有官方发布版本，但 PHP 安全团队提供了最小化源码 backport 分支（PHP-<版本>-CVE-2026-109618-109619），部分发行版和 LTS 厂商也提供 backport。8.2 将于 2026-12-31 EOL。
• Talos 说明 WAF 等临时控制无法提供完整防护。
• 日本首相高市早苗于 10-21 21:55 JST 在 X 上发布紧急提醒（“大至急のお願い”），建议无法及时打补丁的网站暂时下线。

处置

1. 升级到上述修复版本，mod_php 部署优先。
2. 7.4–8.1：使用发行版或 LTS 厂商的 backport，否则基于官方 backport 分支自行编译；同时将其列入迁移计划。
3. 无法立即升级时，应用 php.net 给出的缓解配置并重启所有 worker（ini_set() 和 .user.ini 无效）。这只是临时止血：VulnCheck 指出 session.upload_progress 相关设置只能挡住已确认的 session 路径，挡不住其他变种；Datadog 指出 memory_limit=-1 也不是长期方案。
4. 核对容器镜像和托管面板中的实际 PHP 版本，不能只看宿主机命令行。
5. 测试公开 PoC 只在隔离环境中进行，不要在存有凭据的机器上运行。

“补丁不完整”说法的来源：没有任何机构称官方补丁对已知利用无效。最接近的说法来自 Datadog：补丁“对已知利用看起来是完整的”，但 PHP 8.5.12 中哈希表插入仍然先更新计数器再分配键，修复只改了周围的错误处理；Datadog 认为这种代码模式有风险，未来可能出现同类漏洞，尤其是老版本特有、不会再被修复的变种。微信文章中的“补丁可能不完整”应理解为对这一残留风险的转述，而不是补丁失效。

常见误读：“高市早苗本人的 PHP 网站已被入侵”没有来源支持，相关报道只提到她对网站运营者的提醒。

2. LiteLLM 1.107.0 供应链投毒

可信度：已确认（JFrog、Chainguard、The Hacker News 及 LiteLLM 官方说明）

概况：10-21 发布的 LiteLLM 1.107.0 为恶意版本，PyPI 和 Docker Hub 均受影响。这是 LiteLLM 今年第二次被投毒（3 月为 1.82.7 / 1.82.8）。

关键事实

• 受影响制品：PyPI 上 7 个 wheel 全部含恶意代码；Docker 的 latest、main-latest、main-stable 三个 tag 约 3 小时内指向恶意镜像。
• 执行方式：通过 cook.pth 在任何 Python 解释器启动时执行，不需要 import litellm。
• 窃取范围：云凭据、SSH/GPG 密钥、浏览器数据、环境变量、20 余种 AI 编码工具的配置文件、LiteLLM 代理中存储的上游 API Key；并每小时拉取并执行远程代码。
• 攻击路径（据 LiteLLM 官方事件页，最后更新 10-21 20:30 UTC）：攻击者持有三名工程师的 GitHub CLI OAuth 令牌。其中一个属于 GitHub 组织所有者，被用来关闭分支保护、force push 修改后的发布工作流并触发运行；第二个满足了生产发布的审批门槛；第三个用来删除生产和预发布的工作流记录。恶意制品由仿冒仓库 Berri-AI/litellm（正牌为 BerriAI/litellm）构建，官方 v1.107.0 源码 tag 中没有恶意文件。
• 令牌来源（官方推测，未确认）：LiteLLM 发现一个暴露在公网的内部部署。他们观察到 Claude Code 在某些情况下会把用户的 GitHub CLI OAuth 令牌写进响应体，而记录响应体的 LiteLLM 部署会把这些令牌落进日志。官方认为攻击者进入了该部署、从日志中拿到令牌，并怀疑入口是一个“最近修补的漏洞”。目前只找到其中一个令牌的可能泄露途径，另两名工程师的令牌如何泄露仍在调查。
• 归因：官方未点名攻击者。CERT-EU 曾将 3 月的投毒归于 TeamPCP，但本次事件尚无归因。

时间线（10-21，UTC，据官方）

LiteLLM 已从 PyPI、Docker Hub、GHCR 移除恶意制品，吊销相关令牌，移除 trusted publishing 关联，并把 GitHub 组织成员缩减到一名未受影响的用户。

处置

1. 排查所有主机、CI runner 和镜像：pip show litellm，并在 site-packages 中搜索 cook.pth。
2. 10-21 拉取过上述浮动 tag 的，核对镜像 digest。
3. 命中即视为该主机上的全部凭据已泄露：在干净环境中吊销并重新签发，隔离或重建主机。
4. 按 digest 锁定 1.106.2。
5. 自建 LiteLLM 代理如果记录响应体，检查日志中是否出现 gho_ 开头的 GitHub CLI 令牌；有则吊销，并关闭响应体日志或做脱敏。

3. Zeabur 平台入侵

可信度：已确认（Zeabur 10-19 初步调查报告、10-20 官方推文、10-17 停运公告）

概况：攻击者利用私有配置仓库中的明文凭据进入 Zeabur 共享集群、独立服务器和内部系统，并读取了平台数据库。Zeabur 已于 10-17 宣布停止运营，安全事件是公告列出的四项原因之一（另三项为增长瓶颈、早期架构负担和投入评估）。

根因

• 私有配置仓库中存有明文 AWS Key 和集群管理令牌（2024 年创建，从不过期），管理接口暴露在公网。
• 攻击者如何取得该仓库尚未确认。主要假设是 8 月事件中泄露的 GitHub App 私钥，但报告明确写道“目前没有证据直接证明这条路径”；Zeabur 已向 GitHub Support 调取记录，截至报告发布时尚未收到回复。8 月事件后只轮换了确认泄露的密钥，没有处理这些明文凭据；GCP root 密码问题 9-3 已发现但未修复。

时间线（UTC）

已确认的影响

• 平台数据库：约 320 万条环境变量记录、321,810 条账号记录（邮箱、用户名、电话）、566 个明文 zSend API Key、11,536 个哈希后的 Access Token。
• 一个客户数据库备份经预签名 URL 被下载。
• 865 个数据库服务容器内被执行过命令。
• 101 台 GCP 独立服务器被 root 登录，其中 50 台被植入攻击者 SSH Key。
• 607 个 n8n 实例中有 602 个的加密密钥存放在环境变量中，其中保存的第三方凭据应视为全部暴露。

尚未确认

• 数据库实际外传量无法确定：审计日志只记录了执行的命令，没有记录输出。攻击者在 865 个数据库服务中执行过命令（并非全部成功），对象主要是 n8n 实例，其次是 PostgreSQL；PostgreSQL 按表逐个读取，每表最多 5 万行。因此应按“每个被触及的库都可能被读走前 5 万行/表”评估。
• tpe1、hkg1 两个区域的用户数据库备份被攻击者列出过，是否被下载无法确认，报告要求按已泄露处理。
• Hetzner（359 台）和 DigitalOcean（48 台）的管理令牌已于 10-16 01:09 UTC 吊销。两家都不保留操作审计日志：Hetzner 侧的事件能对应到用户或定时任务，DigitalOcean 仍在核查。
• 10-16 某 OpenAI Key 被调用约 1,107 次是否与本次事件相关。

截至 10-22，初步报告页面仍为 10-19 版本，未见更新；status 页面在 10-20 将事件标记为已解决，但报告称调查仍在继续。

处置

1. 轮换存放在 Zeabur 的所有密码、API Key 和密钥，即使 8 月后已经轮换过。
2. 数据库内部账号密码需单独修改，修改环境变量不会改变数据库中的凭据；作废并重建存储的密码哈希、会话和令牌。
3. n8n：更换加密密钥并重建全部第三方凭据。new-api / one-api：吊销上游 AI Key。
4. PostgreSQL：检查陌生的 role、函数、触发器、定时任务和扩展；无法确认时重建数据库，仅导入数据。
5. 在 GitHub 审计日志中检查 Zeabur GitHub App 在 10-15 15:05–18:54 UTC 的活动（clone、push、新增 deploy key、webhook）。
6. 第三方服务账单从 10-14 开始核查；GCP 独立服务器从 9-1 开始追溯，查找带 @zeabur-pentest 注释的 SSH Key，并按官方要求从干净环境重建。
7. 8 月后已将环境变量迁到自有服务器的项目，不受本次平台数据库读取影响。

停运时间表：10-17 起停止销售；12-01 起独立服务器按到期日陆续关闭、共享集群暂停（可手动重启以备份）；12-31 全部停止。官方说明 12-31 只是最终期限，不保证每项服务都能运行到该日。数据删除日期和最晚导出期限尚待公布，备份、迁移和域名转出应按实际到期日推进。

4. eMudhra 中间 CA 私钥可推算

可信度：已确认（Cisco Talos、Go 安全公告、eMudhra 自查站、各浏览器厂商封锁记录）

概况：eMudhra 的 8 张中间 CA 证书使用了极弱的 P-384 私钥（部分私钥只是个位或两位整数），任何人都可以从公开证书直接推算出私钥。

技术细节

• 涉及 6 张 TLS 中间 CA（挂在 emSign Root TLS CA - G3 下）和 2 张代码签名中间 CA（挂在 emSign Root CS CA - G3 下）。出问题的是中间 CA，不是根证书。
• 根因：2025-04-30 一次为 24 张子 CA 生成密钥的仪式中，wrap/unwrap 步骤多生成了一套弱密钥，并被误用。
• 与 2011 年 DigiNotar 事件相比：DigiNotar 是 CA 被入侵后攻击者签发了伪造证书，并在伊朗用于实际的中间人攻击；本次事件不需要入侵，私钥对任何人公开可得。

时间线

影响边界

• 主流浏览器：Firefox、Chrome、Edge、Safari 强制 CT，即使不更新封锁列表，伪造证书也无法通过验证。
• 非浏览器客户端：不检查 CT、也不使用吊销数据的客户端是主要暴露面。公开实测显示，10-21 用 EM DV TLS CA - G3B 签发的 localhost 证书可通过某 Linux 系统自带 curl 8.21.0 + 系统 CA bundle 的验证。
• macOS：系统自带的 curl、git、python3、perl、ruby、openssl 读取的 /etc/ssl/cert.pem 尚未更新；自带 pip3 使用自己内置的旧根证书。
• 代码签名：有观点认为可借此为恶意固件签名。固件验签通常依赖厂商固化在 ROM 中的根证书，很少使用公共 CA 链，目前没有证据支持这一场景。

利用门槛：mitmproxy 维护者于 10-21 23:36 UTC 合并 PR #8500（对应 issue #8497），新增可选的 --emudhra 参数，使用已泄露的中间 CA 私钥签发证书。mitmproxy 并未默认内置这些证书。从此对未更新信任库的客户端做中间人只需要一个命令行参数；防守方也可以用同一选项测试自己的设备和程序。

修复进度（截至自查站更新时）

• 已修复：curl、Go（1.27.3 / 1.26.10，按 SPKI 哈希过滤，分配 CVE-2026-111943）、Java、Node.js、Python certifi、Rust 工具链、Electron、Docker Desktop、Claude Code 2.1.303。
• 待修复：Bottlerocket、Bun、Erlang certifi。
• Talos 截至 10-21 14:00 UTC 未观察到在野滥用。

处置

1. 浏览器无需额外操作。
2. macOS：用自查站提供的测试主机运行 curl，握手失败才说明已正确拒绝。
3. Linux：执行发行版更新。Go 程序用 1.27.3 / 1.26.10 重新编译；Python 升级 certifi。
4. VPN、代理、IoT 等设备逐一向厂商确认；不再接收更新的设备应列入隔离或替换计划。

常见误读：CVE-2026-111943 是 Go 的证书封锁编号，不是 PHP、Node、Java 的共同漏洞；“私钥为 4”这一具体值来自社区，官方材料未公布；“8 个中级根证书”应为 8 张中间 CA 证书。

5. Node.js 10 月安全更新与 Bun Brotli 漏洞

可信度：已确认（Node.js 官方公告、oven-sh/bun#46352、oven-sh/bun#46392）

概况：Node.js 于 10-21 发布 22.23.4 / 24.22.1 / 26.12.1，修复 10 个 CVE（4 高、3 中、3 低）；22.x 受其中 7 个影响，24.x 受 8 个，26.x 受全部 10 个。20.x（2026-04-30 EOL）和 25.x（2026-06-01 EOL）不再提供补丁。本次同时更新了 c-ares、CA 证书（含 eMudhra 封锁）、OpenSSL、SQLite、undici 等内置依赖。

Brotli RCE 的暴露面

• Bun 同样受影响：oven-sh/bun#46352 确认所有版本受影响，fetch()、node:zlib、DecompressionStream("brotli") 的默认路径都会调用解码器（≤1.4.2 内置 brotli 1.1.0，1.4.3 内置 1.2.0，均未打补丁）。上游修复为 google/brotli@0ed4268a，目前还没有包含它的 brotli 正式版本。Bun 在 PR #46392 中更新了 brotli 并关闭该 issue，修复版本为 Bun v1.4.4（10-22 10:11 UTC 发布）。
• Node.js 的 fetch（undici）对 Content-Encoding: br 同样默认自动解压。这一点是推断，官方公告未说明触发条件。
• 因此，请求攻击者可控 URL 的程序风险最高：爬虫、AI Agent、MCP server、Webhook 回调、链接预览服务等。

处置

1. 分别核对服务、CI、容器、Electron 应用、SEA 二进制和 npx 启动的 MCP server 的实际运行版本。
2. 容器：node:22 等浮动 tag 需重新 pull 并构建；锁定小版本的需手动修改。
3. 升级后重启 pm2 / systemd 管理的进程；仅更新二进制不会影响正在运行的进程。
4. Electron 应用内置独立的 Node，需等待应用发版，系统 Node 升级对其无效。
5. SEA：用新版 Node 重新打包，旧二进制中仍是旧快照（根据漏洞性质推断）。
6. 优先处理会抓取外部 URL 的服务；Bun 用户升级到 v1.4.4（bun upgrade），使用 oven/bun 镜像的重新构建。
7. 自行编译或静态链接 brotli 的 C/C++、Rust、Go 项目同样可能受影响，需检查是否已带上 0ed4268a 补丁（根据上游修复情况推断，本期材料未覆盖其他语言生态）。

6. GitLab CVE-2026-110264

可信度：已确认（The Hacker News）

概况：CVSS 10.0，影响自 7.0（2014 年）以来的所有自建版本。漏洞来自同一位研究者一个月内报告的第四个正则引擎问题。

关键事实

• 这是近期第二个 CVSS 10.0 漏洞。第一个是 10-12 修复的 CVE-2026-97229（仅影响 19.2 及以上）；9-23 修复的两个为 9.9，且需要认证。“六周内第三个 10.0”的说法不准确。
• 10-12 已升级的实例仍在本次漏洞影响范围内。
• 修复版本：18.11.13 / 19.0.10 / 19.1.9 / 19.2.9 / 19.3.6 / 19.4.3 / 19.5.1。其中 19.3.6 和 19.4.3 包含数据库迁移，单节点部署升级时会停机。

处置：无论 10-12 是否已升级，都需升级到本次版本；涉及迁移的版本需安排维护窗口。

7. OpenCode Console 第三方 API Key 可能暴露

可信度：已确认事件，影响程度未确认（OpenCode 官方通知、The Hacker News）

概况：OpenCode Console 中存储的 OpenAI、Anthropic、Google API Key 可能暴露。官方表述为“可能暴露”，尚未确认被复制或使用。

影响范围：约 1.4% 的 Console 用户，且仅限在 Console 中保存过第三方 Key 的用户。CLI 和桌面端将 Key 存在本地，不受影响。用户自报的盗刷金额（如 $281、$1,700）未经核实。

处置

1. 收到通知的用户应在 OpenAI、Anthropic、Google 控制台中吊销旧 Key。在 Console 中删除 Key 不会使其失效。
2. 从 10-16 起核查账单，设置消费上限。
3. 为每个工具单独签发 Key，便于隔离和追溯。

8. Linux 内核 PwnEscape（CVE-2026-99999）

可信度：已确认（Linux 内核 CNA 的 CVE 记录；NVD 收录状态为 “Received”，尚未完成分析）

概况：内核 IPv4 栈中 skb_checksum_help 未校验 checksum_start。恶意客户机可以通过 virtio-net 提交伪造的校验和元数据，经宿主机 TAP 设备进入 IPv4 分片路径，篡改已校验过的 IPv4 头，进而读取宿主机内存、使宿主机崩溃，或以管理员权限执行命令。

关键事实

• CVE 记录由 Linux 内核 CNA 于 10-15 发布，标题为 “ipv4: validate checksum_start before completing checksum”，CVSS 3.1 9.3（AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）。评分场景写明：攻击者只需能从分配给自己的 virtio-net 接口发包，不需要宿主机凭据，也没有竞态条件；信息泄露、宿主机崩溃和代码执行三种变种都已复现。
• 攻击面是客户机到宿主机的虚拟设备路径，不是从互联网接收数据包的路径。
• 上游修复提交为 6785011f8b16，已回合到多个 stable 分支（CVE 记录列出 8 个 stable 提交）。第三方报道列出的修复版本包括 6.18.57、6.12.113、6.6.159、6.1.190、5.15.223、5.10.272。
• 修复提交说明称这是“纵深防御”措施，更完整的入口校验仍在开发中，后续可能还有补丁。
• 发现者为 Paulos，CVE 记录引用了 pwn.ai 的技术文章和 Vercel 的 Sandbox 挑战赛报告。

影响范围：AWS 称其托管服务不受影响；日本 Sakura Internet 于 10-16 暂停了新 VPS 开通。各发行版进度不一：Debian 12/13 和 Amazon Linux 2023 已发布公告，Proxmox VE 部分内核系列尚未说明。“波及各家主流虚拟机厂商”的说法夸大了实际范围，风险集中在运行不可信客户机的自管 KVM / Firecracker 宿主机。

处置

1. 运行不可信客户机的宿主机（多租户 VPS、沙箱、CI runner、Agent 沙箱）优先升级到包含 6785011f8b16 的内核，并重启宿主机。
2. 以发行版安全公告为准确认修复版本，不要只看上游版本号。
3. 关注后续更完整的入口校验补丁。

9. IDCF Cloud 勒索攻击

可信度：已确认（IDCF 官方公告）

概况：日本 IDCF Cloud 自 10-07 起遭勒索攻击，官方确认 495 家企业和地方政府受影响。受影响区域的数据在服务商侧大概率无法恢复，客户需依赖自有备份。

启示：托管云平台的备份不能替代客户自己掌握、离线或跨供应商的备份。

10. PingCAP / TiDB Cloud 数据泄露

可信度：事件已确认（PingCAP 官方报告）；攻击方宣称的规模未证实

概况：PingCAP 于 10-19 发布安全事件报告，确认攻击者使用被盗的服务账号凭据访问了部分内部系统，复制了数据并取得了源代码。凭据如何被盗，报告没有说明。

时间线（据 PingCAP）

已确认被访问的数据

• TiDB Cloud 账号与产品使用：用户名、邮箱、组织/项目关联、SQL 编辑器中的文本和报错、部分组织/项目/集群标识。
• 商务与账单：客户联系人、合同条款、订单、价格、付款条款和账单配置。
• 源代码。
• 一张导出的表中包含加密的 TiDB Cloud API Key。外部机构测试了一个调查方自有的值，无法直接当作 API Key 使用；其他可用凭据是否暴露仍未确定。

未受影响或未发现证据：PingCAP 称没有证据表明存储在 TiDB 中的数据受到影响；在已审查的生产系统中，未发现攻击者执行命令或维持持久访问。生产日志中修补前是否有漏洞被利用仍在核查。

与攻击方说法的差异：FulcrumSec 声称窃取 10.6TB、约 490 万个文件，已公开约 200GB 首批数据，访问持续近两个月，涉及日本、中国大陆、香港、印度的机构，并称拿到了明文 API Key。PingCAP 报告没有回应 10.6TB 的说法，并把 API Key 描述为加密存储，至今没有证据表明被解密或使用。Bitget 确认其存放在 TiDB Cloud 的数据被访问，但称仅涉及公开交易日志。微信文章中“从代码仓库拿到云凭据”的说法在官方报告中没有出现。

处置

1. TiDB Cloud 用户轮换管理 API Key，审查组织成员和访问日志。
2. 假设 SQL 编辑器中输入过的内容（包括其中可能出现的连接串、密钥）已泄露，相应轮换。
3. 等待 PingCAP 按客户逐一发送的影响通知；有疑问可联系 security@pingcap.com。

11. 漏洞发现侧：Anthropic OSS Scanner

可信度：已确认（Anthropic 官方说明与发布文章、OSS Scanner 团队成员 Punit Shah 的公开线程）

概况：Anthropic 于 10-08 推出 OSS Scanner，为关键开源项目免费提供定期漏洞扫描。截至 10-20（上线 11 天），据团队公布的数字：约 650 个项目申请，114 个被接收，向维护者报告了 77 个 Critical、803 个 High 发现。这些等级都由模型评定，不等于人工确认的漏洞数，且被接收的项目尚未全部扫描完。

典型案例：curl CVE-2026-92392

• HTTP/2 上传中断后残留悬空指针，导致 UAF。9-15 提交，curl 团队数小时内确认，curl 8.23.0 修复（为此将发布周期从 8 周缩短到 6 周）。
• Daniel Stenberg 在博客中描述了一条 RCE 路径，但条件苛刻：受害者需向攻击者控制、持有有效证书的服务器上传约 135KB 数据，可用载荷空间仅约 23 字节。他认为最可能的结果只是崩溃，成功利用的机会很小；同时对报告和复现材料的质量评价很高。

项目机制（官方说明）

• 需由核心维护者向 anthropics/oss-scanner 提交 PR 申请，参照 OSS-Fuzz 标准逐个审核。
• 常规 CVD 流程有人工复核，截至 10 月已复核 6,000 余份报告。
• 可选的快速通道直接发送未经人工审查的报告，可能存在误报；未经验证的发现不适用 90 天披露期。

准确率数据

• Anthropic 发布文章给出的早期验证：负责 CVD 复核的渗透测试人员抽查了扫描器在 48 个项目中的 97 个 Critical/High 发现，其中 85 个（88%）达到 CVD 披露标准，11 个真实但与已知问题或其他扫描结果重复，只有 1 个是误报。这是早期版本的小样本结果，没有独立审计。
• 第三方报道中的“真阳性率 92.7%”来自更早的内部项目 Project Glasswing，不是 OSS Scanner 的数据，不应混用。
• 维护者反馈：wolfSSL 称其 74 份早期报告中只有 2 份无效；也有维护者反映严重性评级偏高，或扫描器误解了项目自身的威胁模型。

投递问题：团队称首批报告大多被退信，推测是邮件过滤器把 PoC 当作恶意软件；维护者提供了密钥的，已改发加密报告。目前正在试点通过 GitHub Security Advisories 投递（维护者呼声最高的需求），并修订了 FAQ 中的接收标准，最常见的拒绝原因是项目许可证不属于开源许可证。

来源说明：申请数、接收数和投递问题来自 Punit Shah 在 X 上的线程（他是 OSS Scanner 团队成员）。官方说明页（10-13 最后更新）未收录这些数字。

评估：报告供给增加后，维护者的复现、去重和修复能力成为瓶颈。团队需要同步准备分诊流程，否则大量报告只会积压。

趋势判断

• 凭据是主要攻击面。 长期有效、明文存储、权限过宽的凭据，一旦泄露就会被横向放大。Zeabur 的攻击活动持续 16 小时没有触发告警，说明管理凭据的异常使用检测普遍不足。
• 补丁到利用的窗口在缩短，甚至倒置。 PHP 细节在禁运期结束前一天流出，据转引的 AWS 观测，利用尝试早于补丁四天开始，补丁发布当天出现大面积扫描和数百个 PoC 仓库；mitmproxy 在 eMudhra 事件公开后 4 天内内置了利用选项。
• 停止维护的组件风险上升。 Node.js 20.x / 25.x、PHP 8.1 及更早版本、不再更新信任库的 IoT 设备，都在本期事件中处于无补丁或补丁滞后状态。
• AI 同时加快了找洞和利用。 OSS Scanner 上线 11 天报出 880 个模型评级的高危以上发现，早期抽样误报率约 1%；GitLab 本次的 10.0 漏洞来自同一研究者一个月内报告的第四个同类问题；有人公开称借助大模型把只做验证的 PHP2Shell PoC 补全成了可执行命令的版本。利用侧的加速目前只有个案，没有量化数据。
• AI 工具本身成为凭据泄露的新渠道。 LiteLLM 事件中，AI 编码工具把 GitHub 令牌写进响应体，被网关日志记录下来，再从暴露在公网的部署中泄露（官方推测）。Agent、网关、日志系统之间的令牌流转需要纳入凭据治理。

处置优先级

长期措施

1. 维护一份组件清单，记录实际运行版本、维护状态、升级路径和能否隔离。
2. 将明文长期凭据替换为短期、可轮换、最小权限的凭据，并为管理凭据的异常使用配置告警。
3. 保留客户自主掌握的离线或跨供应商备份，并定期验证恢复。
4. 对外部漏洞报告建立复现、去重、定级的分诊流程。

待确认事项

10-22 逐项核查后的状态：

仍需跟进：

• Zeabur 报告的后续更新，以及 GitHub Support 的回复。
• LiteLLM 另外两个令牌的泄露途径，以及内部部署被入侵所用的漏洞。
• PingCAP 按客户发送的影响通知，以及对 FulcrumSec 已公开数据的核实。
• AWS 关于 PHP 漏洞在 10-17 即遭利用的原始通报（目前只见 Datadog 转引）。
• 公开 PHP PoC 何时能在开启 ASLR 的 x86-64 上稳定 RCE。到那时，未打补丁的主机将面临大规模自动化利用。
• 内核 IPv4 入口校验的后续补丁。

来源

官方与一手材料：Node.js 安全公告、php.net 发布说明、Cisco Talos：PHP、Cisco Talos：eMudhra、eMudhra 自查站、Zeabur 初步调查报告、Zeabur 停运公告、curl 作者博客、OSS Scanner 说明、mitmproxy PR #8500、mitmproxy issue #8497、Bun issue #46352、Bun PR #46392、Bun v1.4.4 release、IDCF 公告、LiteLLM 事件页、PingCAP 安全事件报告、CVE-2026-99999（CVE.org）、NVD：CVE-2026-99999、上游内核修复 6785011f8b16、Anthropic：OSS Scanner 发布文章、Zeabur status。

安全研究与媒体报道：watchTowr：PHP FAQ、JFrog：LiteLLM、Chainguard：LiteLLM、The Hacker News：LiteLLM、The Hacker News：GitLab、The Hacker News：OpenCode、abmedia：高市早苗推文、VulnCheck：PHP2Shell、Datadog Security Labs：PHP2Shell、SecureLayer7：PHP 披露时间线、TechFlow：TiDB Cloud、RuntimeWire：PingCAP、The Hacker News：PwnEscape、SmartScope：CVE-2026-99999。

社交媒体与综述：Yachen Liu：eMudhra、宝玉：Node.js、Zeabur 官方推文、Karuboniru：mitmproxy、Karuboniru：证书验证实测、ClaudeDevs：OSS Scanner、Punit Shah：OSS Scanner 数据与投递更新、@iCleanAI 转述、冯若航《当互联网真被打成筛子》。

Read this report as Markdown · Cite it (BibTeX)