{"author":{"id":"4e3fvwoonbfzbvqtdwehr2fzdp","name":"陈成","avatar_url":"https://lh3.googleusercontent.com/a/ACg8ocLP6uaUWVTzl3dUQgZAldOJdTbU_NCUcOxb0Jx1K5CuD97UlDiQ=s96-c","handle":"sorrycc"},"mine":false,"report":{"topic_id":"2dwk5xq4o655","markdown":"# 2026 年 10 月中下旬安全事件梳理\n\n- **整理日期**：2026-10-22\n- **覆盖范围**：2026-10-08 至 10-22 公开的安全事件\n- **材料来源**：厂商与项目的官方公告、安全研究机构分析、相关 X 线程和 GitHub issue/PR，以及一篇微信综述文章中的说法（已逐项核实）。详见文末来源列表\n- **可信度标注**：**已确认** 指有一手公告或多家独立机构交叉证实；**二手** 指只有媒体或第三方转述；**未证实** 指只有当事方或攻击方的单方说法\n\n## 摘要\n\n1. **造成实际损失的主要是凭据泄露。** Zeabur（明文、永不过期的管理令牌）、LiteLLM（被盗的 GitHub CLI OAuth 令牌）、OpenCode Console（托管的第三方 API Key）、TiDB Cloud（被盗的服务账号凭据）都是一组凭据泄露后被横向放大。PHP、Node.js、GitLab 的 RCE 关注度更高，但目前已确认的损失主要来自凭据类事件。\n2. **PHP 核心 RCE 已有在野利用尝试和公开 PoC**，是本期唯一确认被利用的软件漏洞，需要当天处理。目前公开 PoC 只在 ARM64 或关闭 ASLR 的 x86-64 上能稳定 RCE，但这道门槛预计很快会被突破。\n3. **eMudhra 中间 CA 事件的风险在浏览器以外。** 主流浏览器强制证书透明度（CT），伪造证书无法通过；暴露面在语言运行时、操作系统自带工具、代理/VPN 和 IoT 设备。mitmproxy 已内置利用选项，复现已经不需要密码学知识。\n4. **漏洞发现和利用的速度都在提高。** AI 辅助扫描批量产出高危报告，补丁发布后通过补丁比对生成利用的时间在缩短。这是趋势判断，目前没有量化数据支撑。\n\n## 事件总览\n\n| # | 事件 | 类型 | 严重性 | 在野利用 / 实际损失 | 状态 |\n|---|---|---|---|---|---|\n| 1 | PHP 核心 RCE（CVE-2026-109618 / 109619） | 软件漏洞 | CVSS v4 9.2，未认证 RCE | **已有在野利用** | 已修复 |\n| 2 | LiteLLM 1.107.0 投毒 | 供应链攻击 | 严重 | **恶意版本已发布约 3 小时以上** | 已下架 |\n| 3 | Zeabur 平台入侵 | 云平台入侵 | 严重 | **已确认大规模数据读取** | 调查中，平台停运 |\n| 4 | eMudhra 中间 CA 私钥可推算 | PKI 信任失效 | 高 | 未见在野滥用，公开工具已支持 | 各层封锁进度不一 |\n| 5 | Node.js 10 月安全更新 / Bun Brotli | 软件漏洞 | 4 项 High，含 RCE | 未见报告 | 已修复（Node 10-21，Bun 1.4.4 于 10-22） |\n| 6 | GitLab CVE-2026-110264 | 软件漏洞 | CVSS 10.0 | 未见报告 | 已修复 |\n| 7 | OpenCode Console API Key 可能暴露 | 凭据泄露 | 中 | 用户自报盗刷，未核实 | 已通知用户 |\n| 8 | Linux 内核 PwnEscape（CVE-2026-99999） | 虚拟化逃逸 | CVSS 3.1 9.3 | 未见报告 | 上游已修复，发行版进度不一 |\n| 9 | IDCF Cloud 勒索攻击 | 勒索 | 严重 | **495 家机构受影响** | 恢复受限 |\n| 10 | PingCAP / TiDB Cloud 数据泄露 | 凭据泄露 / 数据泄露 | 高 | **已确认数据被复制**；攻击方宣称的规模未证实 | 凭据已作废，影响评估中 |\n\n---\n\n## 1. PHP 核心未认证 RCE（CVE-2026-109618 / 109619）\n\n**可信度：已确认**（php.net、Cisco Talos、watchTowr、VulnCheck、Datadog Security Labs）\n\n**概况**：PHP 核心中的两个漏洞，CVSS v4.0 均为 9.2，可在未认证条件下远程执行代码，影响范围可追溯至 PHP 5.4。\n\n**关键事实**\n\n- 修复版本：**8.5.12 / 8.4.27 / 8.3.36 / 8.2.35**（10-21 发布）。\n- php.net 指出 mod_php 部署风险最高，已有可在应用代码运行前触发的利用演示。\n- 披露过程：漏洞细节于 10-20 约 15:20 UTC 在禁运期结束前流出，补丁于 10-21 14:00 UTC 发布。\n- 在野利用：Talos 截至补丁发布时未观察到；watchTowr 蜜罐网络记录到 **10-21 当天已出现在野利用**；VulnCheck 观察到使用 `php2shell-scan/109618` UA 的扫描，以及一次经 session upload-progress 路径植入 webshell 的尝试（未成功）。Datadog 称有多家厂商报告利用活动，并转引 AWS 称利用尝试最早始于 **10-17**，即补丁发布前四天（AWS 原始通报未找到）。应按“已被利用”处理。\n- 公开 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，说明这道门槛可以突破。\n- FPM：CVE-2026-109619 的上传处理路径在 mod_php 和 PHP-FPM 上都已确认；在 FPM 上还需要应用在启动后执行特定操作。php.net 称所有 Web 部署（含 FPM）均受影响。\n- EOL 分支：7.4、8.0、8.1 没有官方发布版本，但 PHP 安全团队提供了最小化源码 backport 分支（`PHP-\u003c版本\u003e-CVE-2026-109618-109619`），部分发行版和 LTS 厂商也提供 backport。8.2 将于 2026-12-31 EOL。\n- Talos 说明 WAF 等临时控制无法提供完整防护。\n- 日本首相高市早苗于 10-21 21:55 JST 在 X 上发布紧急提醒（“大至急のお願い”），建议无法及时打补丁的网站暂时下线。\n\n**处置**\n\n1. 升级到上述修复版本，mod_php 部署优先。\n2. 7.4–8.1：使用发行版或 LTS 厂商的 backport，否则基于官方 backport 分支自行编译；同时将其列入迁移计划。\n3. 无法立即升级时，应用 php.net 给出的缓解配置并重启所有 worker（`ini_set()` 和 `.user.ini` 无效）。这只是临时止血：VulnCheck 指出 `session.upload_progress` 相关设置只能挡住已确认的 session 路径，挡不住其他变种；Datadog 指出 `memory_limit=-1` 也不是长期方案。\n4. 核对容器镜像和托管面板中的实际 PHP 版本，不能只看宿主机命令行。\n5. 测试公开 PoC 只在隔离环境中进行，不要在存有凭据的机器上运行。\n\n**“补丁不完整”说法的来源**：没有任何机构称官方补丁对已知利用无效。最接近的说法来自 Datadog：补丁“对已知利用看起来是完整的”，但 PHP 8.5.12 中哈希表插入仍然先更新计数器再分配键，修复只改了周围的错误处理；Datadog 认为这种代码模式有风险，未来可能出现同类漏洞，尤其是老版本特有、不会再被修复的变种。微信文章中的“补丁可能不完整”应理解为对这一残留风险的转述，而不是补丁失效。\n\n**常见误读**：“高市早苗本人的 PHP 网站已被入侵”没有来源支持，相关报道只提到她对网站运营者的提醒。\n\n---\n\n## 2. LiteLLM 1.107.0 供应链投毒\n\n**可信度：已确认**（JFrog、Chainguard、The Hacker News 及 LiteLLM 官方说明）\n\n**概况**：10-21 发布的 LiteLLM 1.107.0 为恶意版本，PyPI 和 Docker Hub 均受影响。这是 LiteLLM 今年第二次被投毒（3 月为 1.82.7 / 1.82.8）。\n\n**关键事实**\n\n- 受影响制品：PyPI 上 7 个 wheel 全部含恶意代码；Docker 的 `latest`、`main-latest`、`main-stable` 三个 tag 约 3 小时内指向恶意镜像。\n- 执行方式：通过 `cook.pth` 在任何 Python 解释器启动时执行，**不需要 `import litellm`**。\n- 窃取范围：云凭据、SSH/GPG 密钥、浏览器数据、环境变量、20 余种 AI 编码工具的配置文件、LiteLLM 代理中存储的上游 API Key；并每小时拉取并执行远程代码。\n- 攻击路径（据 LiteLLM 官方事件页，最后更新 10-21 20:30 UTC）：攻击者持有三名工程师的 GitHub CLI OAuth 令牌。其中一个属于 GitHub 组织所有者，被用来关闭分支保护、force push 修改后的发布工作流并触发运行；第二个满足了生产发布的审批门槛；第三个用来删除生产和预发布的工作流记录。恶意制品由仿冒仓库 `Berri-AI/litellm`（正牌为 `BerriAI/litellm`）构建，官方 v1.107.0 源码 tag 中没有恶意文件。\n- 令牌来源（**官方推测，未确认**）：LiteLLM 发现一个暴露在公网的内部部署。他们观察到 Claude Code 在某些情况下会把用户的 GitHub CLI OAuth 令牌写进响应体，而记录响应体的 LiteLLM 部署会把这些令牌落进日志。官方认为攻击者进入了该部署、从日志中拿到令牌，并怀疑入口是一个“最近修补的漏洞”。目前只找到其中一个令牌的可能泄露途径，另两名工程师的令牌如何泄露仍在调查。\n- 归因：官方未点名攻击者。CERT-EU 曾将 3 月的投毒归于 TeamPCP，但本次事件尚无归因。\n\n**时间线（10-21，UTC，据官方）**\n\n| 时间 | 事件 |\n|---|---|\n| 10:08 | 用特权令牌绕过分支保护，写入修改后的发布工作流 |\n| 10:46 | 预发布运行使用仿冒仓库 `Berri-AI/litellm` |\n| 11:11 | 第二个令牌通过生产审批 |\n| 11:39–11:40 | 7 个恶意 wheel 上传到 PyPI |\n| 11:46 | 发布含恶意内容的 Docker 镜像 |\n| 11:53 | 第三个令牌删除工作流记录 |\n| 13:23 | PyPI 下架 1.107.0 |\n| 14:20 | Docker Hub 受影响 tag 被删除或重新指向 |\n\nLiteLLM 已从 PyPI、Docker Hub、GHCR 移除恶意制品，吊销相关令牌，移除 trusted publishing 关联，并把 GitHub 组织成员缩减到一名未受影响的用户。\n\n**处置**\n\n1. 排查所有主机、CI runner 和镜像：`pip show litellm`，并在 site-packages 中搜索 `cook.pth`。\n2. 10-21 拉取过上述浮动 tag 的，核对镜像 digest。\n3. 命中即视为该主机上的全部凭据已泄露：在干净环境中吊销并重新签发，隔离或重建主机。\n4. 按 digest 锁定 1.106.2。\n5. 自建 LiteLLM 代理如果记录响应体，检查日志中是否出现 `gho_` 开头的 GitHub CLI 令牌；有则吊销，并关闭响应体日志或做脱敏。\n\n---\n\n## 3. Zeabur 平台入侵\n\n**可信度：已确认**（Zeabur 10-19 初步调查报告、10-20 官方推文、10-17 停运公告）\n\n**概况**：攻击者利用私有配置仓库中的明文凭据进入 Zeabur 共享集群、独立服务器和内部系统，并读取了平台数据库。Zeabur 已于 10-17 宣布停止运营，安全事件是公告列出的四项原因之一（另三项为增长瓶颈、早期架构负担和投入评估）。\n\n**根因**\n\n- 私有配置仓库中存有明文 AWS Key 和集群管理令牌（2024 年创建，从不过期），管理接口暴露在公网。\n- 攻击者如何取得该仓库**尚未确认**。主要假设是 8 月事件中泄露的 GitHub App 私钥，但报告明确写道“目前没有证据直接证明这条路径”；Zeabur 已向 GitHub Support 调取记录，截至报告发布时尚未收到回复。8 月事件后只轮换了确认泄露的密钥，没有处理这些明文凭据；GCP root 密码问题 9-3 已发现但未修复。\n\n**时间线（UTC）**\n\n| 时间 | 事件 |\n|---|---|\n| 10-14 01:36 | 首次使用泄露凭据 |\n| 10-14 12:39 | 读取共享集群全部服务的配置和密钥 |\n| 10-14 全天 | 持续 16 小时以上的攻击活动，未触发任何告警 |\n| 10-15 13:56 | 因用户报告开始调查（距首次使用约 36 小时） |\n| 10-17 | 发布停运公告 |\n| 10-19 | 发布初步调查报告 |\n\n**已确认的影响**\n\n- 平台数据库：约 320 万条环境变量记录、321,810 条账号记录（邮箱、用户名、电话）、566 个明文 zSend API Key、11,536 个哈希后的 Access Token。\n- 一个客户数据库备份经预签名 URL 被下载。\n- 865 个数据库服务容器内被执行过命令。\n- 101 台 GCP 独立服务器被 root 登录，其中 50 台被植入攻击者 SSH Key。\n- 607 个 n8n 实例中有 602 个的加密密钥存放在环境变量中，其中保存的第三方凭据应视为全部暴露。\n\n**尚未确认**\n\n- **数据库实际外传量无法确定**：审计日志只记录了执行的命令，没有记录输出。攻击者在 865 个数据库服务中执行过命令（并非全部成功），对象主要是 n8n 实例，其次是 PostgreSQL；PostgreSQL 按表逐个读取，每表最多 5 万行。因此应按“每个被触及的库都可能被读走前 5 万行/表”评估。\n- tpe1、hkg1 两个区域的用户数据库备份被攻击者列出过，是否被下载无法确认，报告要求按已泄露处理。\n- Hetzner（359 台）和 DigitalOcean（48 台）的管理令牌已于 10-16 01:09 UTC 吊销。两家都不保留操作审计日志：Hetzner 侧的事件能对应到用户或定时任务，DigitalOcean 仍在核查。\n- 10-16 某 OpenAI Key 被调用约 1,107 次是否与本次事件相关。\n\n截至 10-22，初步报告页面仍为 10-19 版本，未见更新；status 页面在 10-20 将事件标记为已解决，但报告称调查仍在继续。\n\n**处置**\n\n1. 轮换存放在 Zeabur 的所有密码、API Key 和密钥，即使 8 月后已经轮换过。\n2. **数据库内部账号密码需单独修改**，修改环境变量不会改变数据库中的凭据；作废并重建存储的密码哈希、会话和令牌。\n3. n8n：更换加密密钥并重建全部第三方凭据。new-api / one-api：吊销上游 AI Key。\n4. PostgreSQL：检查陌生的 role、函数、触发器、定时任务和扩展；无法确认时重建数据库，仅导入数据。\n5. 在 GitHub 审计日志中检查 Zeabur GitHub App 在 10-15 15:05–18:54 UTC 的活动（clone、push、新增 deploy key、webhook）。\n6. 第三方服务账单从 10-14 开始核查；GCP 独立服务器从 **9-1** 开始追溯，查找带 `@zeabur-pentest` 注释的 SSH Key，并按官方要求从干净环境重建。\n7. 8 月后已将环境变量迁到自有服务器的项目，不受本次平台数据库读取影响。\n\n**停运时间表**：10-17 起停止销售；12-01 起独立服务器按到期日陆续关闭、共享集群暂停（可手动重启以备份）；12-31 全部停止。官方说明 12-31 只是最终期限，不保证每项服务都能运行到该日。数据删除日期和最晚导出期限尚待公布，备份、迁移和域名转出应按实际到期日推进。\n\n---\n\n## 4. eMudhra 中间 CA 私钥可推算\n\n**可信度：已确认**（Cisco Talos、Go 安全公告、eMudhra 自查站、各浏览器厂商封锁记录）\n\n**概况**：eMudhra 的 8 张中间 CA 证书使用了极弱的 P-384 私钥（部分私钥只是个位或两位整数），任何人都可以从公开证书直接推算出私钥。\n\n**技术细节**\n\n- 涉及 6 张 TLS 中间 CA（挂在 emSign Root TLS CA - G3 下）和 2 张代码签名中间 CA（挂在 emSign Root CS CA - G3 下）。出问题的是中间 CA，不是根证书。\n- 根因：2025-04-30 一次为 24 张子 CA 生成密钥的仪式中，wrap/unwrap 步骤多生成了一套弱密钥，并被误用。\n- 与 2011 年 DigiNotar 事件相比：DigiNotar 是 CA 被入侵后攻击者签发了伪造证书，并在伊朗用于实际的中间人攻击；本次事件不需要入侵，私钥对任何人公开可得。\n\n**时间线**\n\n| 日期 | 事件 |\n|---|---|\n| 10-17 | 报告给各根证书计划；Firefox、Chrome 当天封锁 |\n| 10-19 | 通知下游；Apple 封锁 |\n| 10-20 | Microsoft 封锁（含 2 张代码签名 CA）；社区自查站上线 |\n| 10-21 | Node.js、Go 发版处理；Talos 发布分析；mitmproxy 合并 `--emudhra` 选项 |\n\n**影响边界**\n\n- **主流浏览器**：Firefox、Chrome、Edge、Safari 强制 CT，即使不更新封锁列表，伪造证书也无法通过验证。\n- **非浏览器客户端**：不检查 CT、也不使用吊销数据的客户端是主要暴露面。公开实测显示，10-21 用 `EM DV TLS CA - G3B` 签发的 `localhost` 证书可通过某 Linux 系统自带 curl 8.21.0 + 系统 CA bundle 的验证。\n- **macOS**：系统自带的 `curl`、`git`、`python3`、`perl`、`ruby`、`openssl` 读取的 `/etc/ssl/cert.pem` 尚未更新；自带 `pip3` 使用自己内置的旧根证书。\n- **代码签名**：有观点认为可借此为恶意固件签名。固件验签通常依赖厂商固化在 ROM 中的根证书，很少使用公共 CA 链，目前没有证据支持这一场景。\n\n**利用门槛**：mitmproxy 维护者于 10-21 23:36 UTC 合并 [PR #8500](https://github.com/mitmproxy/mitmproxy/pull/8500)（对应 [issue #8497](https://github.com/mitmproxy/mitmproxy/issues/8497)），新增可选的 `--emudhra` 参数，使用已泄露的中间 CA 私钥签发证书。mitmproxy 并未默认内置这些证书。从此对未更新信任库的客户端做中间人只需要一个命令行参数；防守方也可以用同一选项测试自己的设备和程序。\n\n**修复进度**（截至自查站更新时）\n\n- 已修复：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。\n- 待修复：Bottlerocket、Bun、Erlang certifi。\n- Talos 截至 10-21 14:00 UTC 未观察到在野滥用。\n\n**处置**\n\n1. 浏览器无需额外操作。\n2. macOS：用自查站提供的测试主机运行 curl，握手失败才说明已正确拒绝。\n3. Linux：执行发行版更新。Go 程序用 1.27.3 / 1.26.10 重新编译；Python 升级 certifi。\n4. VPN、代理、IoT 等设备逐一向厂商确认；不再接收更新的设备应列入隔离或替换计划。\n\n**常见误读**：CVE-2026-111943 是 Go 的证书封锁编号，不是 PHP、Node、Java 的共同漏洞；“私钥为 4”这一具体值来自社区，官方材料未公布；“8 个中级根证书”应为 8 张中间 CA 证书。\n\n---\n\n## 5. Node.js 10 月安全更新与 Bun Brotli 漏洞\n\n**可信度：已确认**（Node.js 官方公告、oven-sh/bun#46352、oven-sh/bun#46392）\n\n**概况**：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 等内置依赖。\n\n| 等级 | CVE | 内容 | 影响分支 |\n|---|---|---|---|\n| High | CVE-2026-111497 | Brotli 解码越界写入，可导致 RCE | 22 / 24 / 26 |\n| High | CVE-2026-105482 | `dns.resolve` 遇 NUL 字符截断域名 | 22 / 24 / 26 |\n| High | CVE-2026-105483 | 全角数字 IP 绕过证书主机名校验 | 24 / 26 |\n| High | CVE-2026-106069 | 被宽松解析为 IP 的主机名绕过校验 | 22 / 24 / 26 |\n| Medium | CVE-2026-105481 | keep-alive 连接处理了请求发出前写入的响应 | 22 / 24 / 26 |\n| Medium | CVE-2026-106072 | 非规范 IPv4 主机名使 DNS SAN 可认证 IP 端点 | 22 / 24 / 26 |\n| Medium | CVE-2026-106074 | 启动快照 / SEA 保存了随机数缓存，每次启动值相同 | 22 / 24 / 26 |\n| Low | CVE-2026-106070 | ZipFile 校验失败后返回攻击者可控的前缀 | 26 |\n| Low | CVE-2026-106071 | 权限模型通配符授权过宽 | 26 |\n| Low | CVE-2026-106073 | 权限模型可经 `fs.realpathSync` 绕过 | 22 / 24 / 26 |\n\n**Brotli RCE 的暴露面**\n\n- Bun 同样受影响：[oven-sh/bun#46352](https://github.com/oven-sh/bun/issues/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](https://github.com/oven-sh/bun/pull/46392) 中更新了 brotli 并关闭该 issue，**修复版本为 Bun v1.4.4（10-22 10:11 UTC 发布）**。\n- Node.js 的 `fetch`（undici）对 `Content-Encoding: br` 同样默认自动解压。这一点是推断，官方公告未说明触发条件。\n- 因此，**请求攻击者可控 URL 的程序风险最高**：爬虫、AI Agent、MCP server、Webhook 回调、链接预览服务等。\n\n**处置**\n\n1. 分别核对服务、CI、容器、Electron 应用、SEA 二进制和 `npx` 启动的 MCP server 的**实际运行版本**。\n2. 容器：`node:22` 等浮动 tag 需重新 pull 并构建；锁定小版本的需手动修改。\n3. 升级后重启 pm2 / systemd 管理的进程；仅更新二进制不会影响正在运行的进程。\n4. Electron 应用内置独立的 Node，需等待应用发版，系统 Node 升级对其无效。\n5. SEA：用新版 Node 重新打包，旧二进制中仍是旧快照（根据漏洞性质推断）。\n6. 优先处理会抓取外部 URL 的服务；Bun 用户升级到 v1.4.4（`bun upgrade`），使用 `oven/bun` 镜像的重新构建。\n7. 自行编译或静态链接 brotli 的 C/C++、Rust、Go 项目同样可能受影响，需检查是否已带上 0ed4268a 补丁（根据上游修复情况推断，本期材料未覆盖其他语言生态）。\n\n---\n\n## 6. GitLab CVE-2026-110264\n\n**可信度：已确认**（The Hacker News）\n\n**概况**：CVSS 10.0，影响自 7.0（2014 年）以来的所有自建版本。漏洞来自同一位研究者一个月内报告的第四个正则引擎问题。\n\n**关键事实**\n\n- 这是近期第二个 CVSS 10.0 漏洞。第一个是 10-12 修复的 CVE-2026-97229（仅影响 19.2 及以上）；9-23 修复的两个为 9.9，且需要认证。“六周内第三个 10.0”的说法不准确。\n- **10-12 已升级的实例仍在本次漏洞影响范围内。**\n- 修复版本：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 包含数据库迁移，单节点部署升级时会停机。\n\n**处置**：无论 10-12 是否已升级，都需升级到本次版本；涉及迁移的版本需安排维护窗口。\n\n---\n\n## 7. OpenCode Console 第三方 API Key 可能暴露\n\n**可信度：已确认事件，影响程度未确认**（OpenCode 官方通知、The Hacker News）\n\n**概况**：OpenCode Console 中存储的 OpenAI、Anthropic、Google API Key 可能暴露。官方表述为“可能暴露”，尚未确认被复制或使用。\n\n**影响范围**：约 1.4% 的 Console 用户，且仅限在 Console 中保存过第三方 Key 的用户。CLI 和桌面端将 Key 存在本地，不受影响。用户自报的盗刷金额（如 $281、$1,700）未经核实。\n\n**处置**\n\n1. 收到通知的用户应在 OpenAI、Anthropic、Google 控制台中吊销旧 Key。在 Console 中删除 Key 不会使其失效。\n2. 从 10-16 起核查账单，设置消费上限。\n3. 为每个工具单独签发 Key，便于隔离和追溯。\n\n---\n\n## 8. Linux 内核 PwnEscape（CVE-2026-99999）\n\n**可信度：已确认**（Linux 内核 CNA 的 CVE 记录；NVD 收录状态为 “Received”，尚未完成分析）\n\n**概况**：内核 IPv4 栈中 `skb_checksum_help` 未校验 `checksum_start`。恶意客户机可以通过 virtio-net 提交伪造的校验和元数据，经宿主机 TAP 设备进入 IPv4 分片路径，篡改已校验过的 IPv4 头，进而读取宿主机内存、使宿主机崩溃，或以管理员权限执行命令。\n\n**关键事实**\n\n- 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 接口发包，不需要宿主机凭据，也没有竞态条件；信息泄露、宿主机崩溃和代码执行三种变种都已复现。\n- 攻击面是客户机到宿主机的虚拟设备路径，**不是从互联网接收数据包的路径**。\n- 上游修复提交为 `6785011f8b16`，已回合到多个 stable 分支（CVE 记录列出 8 个 stable 提交）。第三方报道列出的修复版本包括 6.18.57、6.12.113、6.6.159、6.1.190、5.15.223、5.10.272。\n- 修复提交说明称这是“纵深防御”措施，**更完整的入口校验仍在开发中**，后续可能还有补丁。\n- 发现者为 Paulos，CVE 记录引用了 pwn.ai 的技术文章和 Vercel 的 Sandbox 挑战赛报告。\n\n**影响范围**：AWS 称其托管服务不受影响；日本 Sakura Internet 于 10-16 暂停了新 VPS 开通。各发行版进度不一：Debian 12/13 和 Amazon Linux 2023 已发布公告，Proxmox VE 部分内核系列尚未说明。“波及各家主流虚拟机厂商”的说法夸大了实际范围，风险集中在运行不可信客户机的自管 KVM / Firecracker 宿主机。\n\n**处置**\n\n1. 运行不可信客户机的宿主机（多租户 VPS、沙箱、CI runner、Agent 沙箱）优先升级到包含 `6785011f8b16` 的内核，并重启宿主机。\n2. 以发行版安全公告为准确认修复版本，不要只看上游版本号。\n3. 关注后续更完整的入口校验补丁。\n\n---\n\n## 9. IDCF Cloud 勒索攻击\n\n**可信度：已确认**（IDCF 官方公告）\n\n**概况**：日本 IDCF Cloud 自 10-07 起遭勒索攻击，官方确认 495 家企业和地方政府受影响。受影响区域的数据在服务商侧大概率无法恢复，客户需依赖自有备份。\n\n**启示**：托管云平台的备份不能替代客户自己掌握、离线或跨供应商的备份。\n\n---\n\n## 10. PingCAP / TiDB Cloud 数据泄露\n\n**可信度：事件已确认（PingCAP 官方报告）；攻击方宣称的规模未证实**\n\n**概况**：PingCAP 于 10-19 发布[安全事件报告](https://www.pingcap.com/trust-hub/security/security-update-october-2026/)，确认攻击者使用**被盗的服务账号凭据**访问了部分内部系统，复制了数据并取得了源代码。凭据如何被盗，报告没有说明。\n\n**时间线（据 PingCAP）**\n\n| 日期 | 事件 |\n|---|---|\n| 9-09 至 10-07 | 未授权访问期间 |\n| 10-07 | 发现事件，开始停用受影响凭据 |\n| 10-10 | 删除更多被盗凭据，移除跨项目的过度权限，开启额外的云存储访问日志 |\n| 10-12 至 10-13 | 外部机构报告 4 个漏洞 |\n| 10-14 | 已识别的被盗凭据全部作废，未授权访问路径全部封堵，4 个漏洞修复并复测 |\n| 10-19 | 发布报告 |\n\n**已确认被访问的数据**\n\n- TiDB Cloud 账号与产品使用：用户名、邮箱、组织/项目关联、SQL 编辑器中的文本和报错、部分组织/项目/集群标识。\n- 商务与账单：客户联系人、合同条款、订单、价格、付款条款和账单配置。\n- 源代码。\n- 一张导出的表中包含**加密的** TiDB Cloud API Key。外部机构测试了一个调查方自有的值，无法直接当作 API Key 使用；其他可用凭据是否暴露仍未确定。\n\n**未受影响或未发现证据**：PingCAP 称没有证据表明存储在 TiDB 中的数据受到影响；在已审查的生产系统中，未发现攻击者执行命令或维持持久访问。生产日志中修补前是否有漏洞被利用仍在核查。\n\n**与攻击方说法的差异**：FulcrumSec 声称窃取 10.6TB、约 490 万个文件，已公开约 200GB 首批数据，访问持续近两个月，涉及日本、中国大陆、香港、印度的机构，并称拿到了明文 API Key。PingCAP 报告没有回应 10.6TB 的说法，并把 API Key 描述为加密存储，至今没有证据表明被解密或使用。Bitget 确认其存放在 TiDB Cloud 的数据被访问，但称仅涉及公开交易日志。微信文章中“从代码仓库拿到云凭据”的说法在官方报告中没有出现。\n\n**处置**\n\n1. TiDB Cloud 用户轮换管理 API Key，审查组织成员和访问日志。\n2. 假设 SQL 编辑器中输入过的内容（包括其中可能出现的连接串、密钥）已泄露，相应轮换。\n3. 等待 PingCAP 按客户逐一发送的影响通知；有疑问可联系 security@pingcap.com。\n\n---\n\n## 11. 漏洞发现侧：Anthropic OSS Scanner\n\n**可信度：已确认**（Anthropic 官方说明与发布文章、OSS Scanner 团队成员 Punit Shah 的公开线程）\n\n**概况**：Anthropic 于 10-08 推出 OSS Scanner，为关键开源项目免费提供定期漏洞扫描。截至 10-20（上线 11 天），据团队公布的数字：约 **650** 个项目申请，**114** 个被接收，向维护者报告了 77 个 Critical、803 个 High 发现。这些等级**都由模型评定**，不等于人工确认的漏洞数，且被接收的项目尚未全部扫描完。\n\n**典型案例：curl CVE-2026-92392**\n\n- HTTP/2 上传中断后残留悬空指针，导致 UAF。9-15 提交，curl 团队数小时内确认，curl 8.23.0 修复（为此将发布周期从 8 周缩短到 6 周）。\n- Daniel Stenberg 在博客中描述了一条 RCE 路径，但条件苛刻：受害者需向攻击者控制、持有有效证书的服务器上传约 135KB 数据，可用载荷空间仅约 23 字节。他认为最可能的结果只是崩溃，成功利用的机会很小；同时对报告和复现材料的质量评价很高。\n\n**项目机制**（官方说明）\n\n- 需由核心维护者向 `anthropics/oss-scanner` 提交 PR 申请，参照 OSS-Fuzz 标准逐个审核。\n- 常规 CVD 流程有人工复核，截至 10 月已复核 6,000 余份报告。\n- 可选的快速通道直接发送未经人工审查的报告，可能存在误报；未经验证的发现不适用 90 天披露期。\n\n**准确率数据**\n\n- Anthropic 发布文章给出的早期验证：负责 CVD 复核的渗透测试人员抽查了扫描器在 48 个项目中的 97 个 Critical/High 发现，其中 85 个（**88%**）达到 CVD 披露标准，11 个真实但与已知问题或其他扫描结果重复，**只有 1 个是误报**。这是早期版本的小样本结果，没有独立审计。\n- 第三方报道中的“真阳性率 92.7%”来自更早的内部项目 Project Glasswing，不是 OSS Scanner 的数据，不应混用。\n- 维护者反馈：wolfSSL 称其 74 份早期报告中只有 2 份无效；也有维护者反映严重性评级偏高，或扫描器误解了项目自身的威胁模型。\n\n**投递问题**：团队称首批报告大多被退信，推测是邮件过滤器把 PoC 当作恶意软件；维护者提供了密钥的，已改发加密报告。目前正在试点通过 GitHub Security Advisories 投递（维护者呼声最高的需求），并修订了 FAQ 中的接收标准，最常见的拒绝原因是项目许可证不属于开源许可证。\n\n**来源说明**：申请数、接收数和投递问题来自 Punit Shah 在 X 上的线程（他是 OSS Scanner 团队成员）。官方说明页（10-13 最后更新）未收录这些数字。\n\n**评估**：报告供给增加后，维护者的复现、去重和修复能力成为瓶颈。团队需要同步准备分诊流程，否则大量报告只会积压。\n\n---\n\n## 趋势判断\n\n- **凭据是主要攻击面。** 长期有效、明文存储、权限过宽的凭据，一旦泄露就会被横向放大。Zeabur 的攻击活动持续 16 小时没有触发告警，说明管理凭据的异常使用检测普遍不足。\n- **补丁到利用的窗口在缩短，甚至倒置。** PHP 细节在禁运期结束前一天流出，据转引的 AWS 观测，利用尝试早于补丁四天开始，补丁发布当天出现大面积扫描和数百个 PoC 仓库；mitmproxy 在 eMudhra 事件公开后 4 天内内置了利用选项。\n- **停止维护的组件风险上升。** Node.js 20.x / 25.x、PHP 8.1 及更早版本、不再更新信任库的 IoT 设备，都在本期事件中处于无补丁或补丁滞后状态。\n- **AI 同时加快了找洞和利用。** OSS Scanner 上线 11 天报出 880 个模型评级的高危以上发现，早期抽样误报率约 1%；GitLab 本次的 10.0 漏洞来自同一研究者一个月内报告的第四个同类问题；有人公开称借助大模型把只做验证的 PHP2Shell PoC 补全成了可执行命令的版本。利用侧的加速目前只有个案，没有量化数据。\n- **AI 工具本身成为凭据泄露的新渠道。** LiteLLM 事件中，AI 编码工具把 GitHub 令牌写进响应体，被网关日志记录下来，再从暴露在公网的部署中泄露（官方推测）。Agent、网关、日志系统之间的令牌流转需要纳入凭据治理。\n\n## 处置优先级\n\n| 优先级 | 事项 | 原因 | 详见 |\n|---|---|---|---|\n| P0（今天） | LiteLLM 1.107.0 排查与凭据重建 | 已确认投毒，窃取凭据 | §2 |\n| P0（今天） | PHP 升级或缓解 | 已有在野利用 | §1 |\n| P0（今天） | Zeabur 用户凭据轮换与追溯 | 已确认数据读取 | §3 |\n| P1（本周） | GitLab 自建实例升级 | CVSS 10.0，10-12 补丁不覆盖 | §6 |\n| P1（本周） | Node.js 升级、Bun 升到 1.4.4，优先外部抓取类服务 | Brotli RCE | §5 |\n| P1（本周） | 运行不可信客户机的 KVM / Firecracker 宿主机升级内核 | CVSS 9.3 客户机逃逸 | §8 |\n| P1（本周） | TiDB Cloud 管理 API Key 轮换 | 已确认数据被复制 | §10 |\n| P1（本周） | 非浏览器 TLS 客户端信任库核查 | 公开工具已支持利用 | §4 |\n| P2 | OpenCode Console Key 吊销 | 可能暴露 | §7 |\n| 长期 | 组件清单与凭据治理 | 见下 | — |\n\n**长期措施**\n\n1. 维护一份组件清单，记录实际运行版本、维护状态、升级路径和能否隔离。\n2. 将明文长期凭据替换为短期、可轮换、最小权限的凭据，并为管理凭据的异常使用配置告警。\n3. 保留客户自主掌握的离线或跨供应商备份，并定期验证恢复。\n4. 对外部漏洞报告建立复现、去重、定级的分诊流程。\n\n## 待确认事项\n\n10-22 逐项核查后的状态：\n\n| 事项 | 状态 | 结论 | 详见 |\n|---|---|---|---|\n| PHP 公开 PoC 是否已流出 | **已解决** | 已流出。数百个仓库中只有少数有效，公开版本尚不能在开启 ASLR 的 x86-64 上 RCE | §1 |\n| PHP“补丁不完整”的来源 | **已解决** | 没有机构称补丁失效；来源应是 Datadog 对残留代码模式的风险提示 | §1 |\n| Zeabur 初始入侵途径 | 仍未确认 | 报告称没有直接证据，正等待 GitHub Support 的记录 | §3 |\n| Zeabur 数据库实际外传量 | 无法确认 | 审计日志不含命令输出；已知上限为每表 5 万行 | §3 |\n| LiteLLM 被盗令牌的来源 | 部分解决 | 官方推测来自公网暴露的内部部署日志，入口疑为近期修补的漏洞；只解释了一个令牌 | §2 |\n| TiDB Cloud 事件真实性与范围 | 部分解决 | PingCAP 已确认事件和数据类别；10.6TB 规模和明文 API Key 的说法仍未证实 | §10 |\n| OSS Scanner 申请数、接收数、误报率 | **已解决** | 650 / 114 来自团队成员；早期抽样 97 个中 1 个误报 | §11 |\n| CVE-2026-99999 一手公告 | **已解决** | Linux 内核 CNA 记录已发布，CVSS 9.3；NVD 尚未完成分析 | §8 |\n| Bun Brotli 修复版本 | **已解决** | Bun v1.4.4 | §5 |\n\n仍需跟进：\n\n- Zeabur 报告的后续更新，以及 GitHub Support 的回复。\n- LiteLLM 另外两个令牌的泄露途径，以及内部部署被入侵所用的漏洞。\n- PingCAP 按客户发送的影响通知，以及对 FulcrumSec 已公开数据的核实。\n- AWS 关于 PHP 漏洞在 10-17 即遭利用的原始通报（目前只见 Datadog 转引）。\n- 公开 PHP PoC 何时能在开启 ASLR 的 x86-64 上稳定 RCE。到那时，未打补丁的主机将面临大规模自动化利用。\n- 内核 IPv4 入口校验的后续补丁。\n\n## 来源\n\n**官方与一手材料**：[Node.js 安全公告](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)、[php.net 发布说明](https://www.php.net/archive/2026.php)、[Cisco Talos：PHP](https://blog.talosintelligence.com/two-critical-rces-in-php-core/)、[Cisco Talos：eMudhra](https://blog.talosintelligence.com/compromised-intermediate-certificates/)、[eMudhra 自查站](https://emudhra.we-have-a-problem.com/)、[Zeabur 初步调查报告](https://zeabur.com/blogs/october-2026-security-incident)、[Zeabur 停运公告](https://zeabur.com/zh-CN/blogs/zeabur-is-shutting-down)、[curl 作者博客](https://daniel.haxx.se/blog/2026/10/14/a-uaf-turned-rce/)、[OSS Scanner 说明](https://red.anthropic.com/oss-scanner/)、[mitmproxy PR #8500](https://github.com/mitmproxy/mitmproxy/pull/8500)、[mitmproxy issue #8497](https://github.com/mitmproxy/mitmproxy/issues/8497)、[Bun issue #46352](https://github.com/oven-sh/bun/issues/46352)、[Bun PR #46392](https://github.com/oven-sh/bun/pull/46392)、[Bun v1.4.4 release](https://github.com/oven-sh/bun/releases/tag/bun-v1.4.4)、[IDCF 公告](https://www.idcf.jp/news/topics/20261008001)、[LiteLLM 事件页](https://docs.litellm.ai/blog/security-incident-oct-21-2026)、[PingCAP 安全事件报告](https://www.pingcap.com/trust-hub/security/security-update-october-2026/)、[CVE-2026-99999（CVE.org）](https://www.cve.org/CVERecord?id=CVE-2026-99999)、[NVD：CVE-2026-99999](https://nvd.nist.gov/vuln/detail/CVE-2026-99999)、[上游内核修复 6785011f8b16](https://git.kernel.org/stable/c/6785011f8b16abf40b1e9d8b2e332232b3e68822)、[Anthropic：OSS Scanner 发布文章](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source)、[Zeabur status](https://status.zeabur.com/incidents)。\n\n**安全研究与媒体报道**：[watchTowr：PHP FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)、[JFrog：LiteLLM](https://research.jfrog.com/post/litellm-hijacked-again/)、[Chainguard：LiteLLM](https://www.chainguard.dev/unchained/litellm-attacked-again-malicious-1-107-0-wheels-on-pypi-and-docker-hub-october-2026)、[The Hacker News：LiteLLM](https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html)、[The Hacker News：GitLab](https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html)、[The Hacker News：OpenCode](https://thehackernews.com/2026/10/opencode-console-breach-may-have.html)、[abmedia：高市早苗推文](https://abmedia.io/php-critical-rce-takaichi-warning)、[VulnCheck：PHP2Shell](https://vulncheck.com/blog/php2shell-vulnerabilities)、[Datadog Security Labs：PHP2Shell](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/)、[SecureLayer7：PHP 披露时间线](https://blog.securelayer7.net/php-rce-cve-2026-109618-109619/)、[TechFlow：TiDB Cloud](https://www.techflowpost.com/article/34741)、[RuntimeWire：PingCAP](https://runtimewire.com/article/pingcap-tidb-cloud-data-exposure-stolen-credentials)、[The Hacker News：PwnEscape](https://thehackernews.com/2026/10/critical-pwnescape-linux-kernel.html)、[SmartScope：CVE-2026-99999](https://smartscope.blog/en/blog/cve-2026-99999-pwnescape-linux-kernel-vulnerability-affected-2026/)。\n\n**社交媒体与综述**：[Yachen Liu：eMudhra](https://x.com/Blankwonder/status/2113085304508956722)、[宝玉：Node.js](https://x.com/dotey/status/2113067412979433847)、[Zeabur 官方推文](https://x.com/zeaburapp/status/2112383969509724567)、[Karuboniru：mitmproxy](https://x.com/Karuboniru/status/2113136843869057119)、[Karuboniru：证书验证实测](https://x.com/Karuboniru/status/2112794758431314049)、[ClaudeDevs：OSS Scanner](https://x.com/ClaudeDevs/status/2112299602510749992)、[Punit Shah：OSS Scanner 数据与投递更新](https://x.com/thepunit/status/2112267290096111896)、[@iCleanAI 转述](https://x.com/iCleanAI/status/2112303425946079728)、[冯若航《当互联网真被打成筛子》](https://mp.weixin.qq.com/s/EnzaFf4EF_6Rsh-U2DX90Q)。\n","html":"","default_view":"markdown","version":2,"updated_by":"4e3fvwoonbfzbvqtdwehr2fzdp","updated_at":"2026-10-22T15:01:56Z","assets":[],"base_url":"/pub/2dwk5xq4o655/p/"},"sources":[],"topic":{"id":"2dwk5xq4o655","title":"2026 年 10 月中下旬安全事件梳理","question":"2026-10-08 至 10-22 公开的安全事件：影响、核实状态与处置优先级","visibility":"public","slug":"2026-10-security-incidents","hue":47,"emoji":"🛡️","owner_id":"4e3fvwoonbfzbvqtdwehr2fzdp","created_at":"2026-10-22T15:01:46Z","updated_at":"2026-10-22T15:18:59Z","published_at":"2026-10-22T15:01:58Z","item_count":0,"report_words":3643,"formats":["markdown"],"url":"https://research.sorrycc.dev/@sorrycc/2026-10-security-incidents"}}