ONCALL://19

处置顺序

假如你是这家公司的 on-call,按什么顺序处理这 19 个告警。清单可以勾选,进度保存在浏览器本地。

排序依据

排序先看利用证据,再看段子里的公司是否直接命中,最后看严重度。所以 LiteLLM 排在最前:它没有 CVE 编号,但恶意代码已经确认,而且段子明确说公司已经装上。

PHP 和 Linux 内核排在第二梯队。它们都是可远程利用或可逃逸的严重漏洞,段子里的版本都在受影响范围内,而且 PHP 7.3 没有上游修复版。Zeabur、Railway、GitLab 和 Chrome 不在段子里,所以只在“如果你用了它”的前提下才需要处理。GitLab 是例外中的例外:如果公司的 CI 跑在自管 GitLab 上,而且实例暴露在公网,就应直接升到 P0。Chrome 没有在野利用,本周内强制更新即可。

级别时限条件
P0立即已确认恶意或可远程利用,且公司直接命中
P1今天严重或高危,公司直接命中或大概率命中
P2本周需要特定配置才能利用,或只影响部分部署
P3排期风险有限,或主要是运营改进

处置清单

每张卡片的操作来自对应报告的“修复与缓解”部分。勾选后进度会保存在这个浏览器里。如果你只想看段子公司确定受影响的条目,打开“只看直接命中”。

总进度
0/63 · 0%

勾选状态只保存在这个浏览器的本地存储中,不会上传。

P0立即

已确认恶意或可远程利用,且公司直接命中

0/14 · 0%
严重直接命中

内核从 2.6.27 起受影响。段子里的服务器如果没装 10 月的修复内核,就在范围内。

PwnEscape:同组条目的处置可以合并执行。

严重直接命中

PHP 5.4 至 8.5.11 都受影响。7.3 和 5.6 都在范围内,而且上游不给这两个分支修复。花几周做完的升级没有解决问题。

严重直接命中

CI 如果在 10-21 19:39 至 21:23(北京时间)拉取未固定版本,拿到的就是恶意包。生产环境和全员电脑都要按失陷处理。

严重直接命中

c6e50df8 是 2008 年引入漏洞的提交 f43798c 的末尾 8 位,不是修复提交。按字面,“c6e50df8 之前”的内核早于 2.6.27,反而没有这个漏洞,但缺少 18 年的其他修复。段子的本意更可能是“没打补丁”。

PwnEscape:同组条目的处置可以合并执行。

P1今天

严重或高危,公司直接命中或大概率命中

0/20 · 0%
严重直接命中

受影响的 8 张中间 CA 里有 2 张用于代码签名,属于 emSign 体系。段子里的三个根证书库在修复前都信任这条链。

eMudhra 私钥事件:同组条目的处置可以合并执行。

高危直接命中

Node.js 24 同时受两项 TLS 绕过和 Brotli 越界写影响。Brotli 漏洞能否触发,取决于服务是否解码不可信的 Brotli 数据。

高危段子外

段子里的公司没有提到 Railway。只有把密钥存在 Railway 的团队受影响。

严重看配置

面板如果跑在 8.0.31、9.0.20、10.0.12 或更低版本,就受 Kestrel 请求走私影响。QUIC RCE 只影响 Windows 上显式引用的特定 QUIC 包。

严重直接命中

段子列出的三个根证书库都需要更新。旧版 pip 会额外加载内置的旧 certifi,所以只更新系统证书不够。

eMudhra 私钥事件:同组条目的处置可以合并执行。

严重段子外

段子没提 GitLab。如果公司的 CI 跑在自管 GitLab 上,这条应升为 P0;GitLab.com 已由官方修复。

P2本周

需要特定配置才能利用,或只影响部分部署

0/23 · 0%
高危看配置

只影响 TiDB Cloud 客户的账户、联系人和账单资料。官方称未发现存入 TiDB 的数据受影响。自管 TiDB 不在范围内。“NewDB”不是 PingCAP 的产品名。

高危段子外

段子里的公司没有提到 Zeabur。只有部署在 Zeabur 上的服务受影响。

高危看配置

1.23.0 在受影响版本范围内,但利用需要特定配置:正则捕获组复用、AIO 加 SSI,或 HTTP/3。

高危看配置

漏洞是拒绝服务、响应走私和 CONNECT 连接串线,不是 SSRF 绕过。只有用到受影响的客户端和代理代码时才相关。

高危看配置

29.5.1 之前的 29.x 都受 3 项归档处理漏洞影响。AuthZ 绕过只影响依赖请求体做授权判断的插件。

高危看配置

同一主机由多个 Ingress 承载且 TLS 选项冲突时,Traefik 会回退到不要求客户端证书的默认配置,也就是段子说的 fail-open。只影响 v3.7.0 至 v3.7.10。

严重段子外

段子没提浏览器。但公司有一批员工电脑,上面几乎一定装了 Chrome 或其他 Chromium 浏览器。

P3排期

风险有限,或主要是运营改进

0/6 · 0%
中危间接相关

直签的 Sectigo DV 证书不受这次私钥问题影响。真实风险有两个:200 天有效期下手动续期容易漏;mTLS 的 CA 包里可能含交叉签名链。

eMudhra 私钥事件:同组条目的处置可以合并执行。

中危看配置

只有用受影响版本、并满足触发条件编译部署的合约才相关。

跨事故的共同动作

有些动作能同时覆盖多个事故,值得先做:

  1. 轮换凭据。LiteLLM 恶意包会读取所有进程的环境变量。所以除了 LiteLLM 自己的密钥,还要轮换同一主机上 PHP、Node.js、.NET 服务用到的数据库密码和 API 密钥。
  2. 升级 Go 到 1.26.10 或 1.27.3。一次升级同时覆盖 INC-10 的 net/http 修复和 INC-17 的 eMudhra 坏链修复。
  3. 升级 Node.js 到 24.22.1。它同时修复 TLS 和 Brotli 漏洞,并内置 eMudhra 受影响 CA 的拒绝表。
  4. 重建容器镜像。certifi、pip、webpki-roots、Go 二进制和 LiteLLM 都需要重新构建镜像才会生效。
  5. 内核升级和 Docker 升级都要重启节点,可以放在同一个维护窗口里执行。
  6. 清理员工电脑。清除 LiteLLM 恶意包时,顺带用组策略或 MDM 把 Chrome 强制升级到 156。LiteLLM 的窃密程序本来就会读取浏览器保存的密码和 Cookie。
  7. 如果 CI 跑在自管 GitLab 上,先升级 GitLab,再轮换 CI/CD 变量和 Runner 令牌。LiteLLM 投毒本来就要求轮换 CI 密钥,两件事应一起做,避免轮换两次。

调研截止 2026-10-22 UTC+8 · 未验证的内容已在正文中标注 · 数字以原始来源为准

本页目录