19 个告警，
0 个能睡觉。
2026-10-21，@Manjusaka_Lee 发了一个段子：一家公司的技术栈里，每个组件都刚好撞上一个真实事故。本站逐条调查了这些事故，加上用户补充的 Zeabur、Railway、GitLab 和 Chrome，共 19 个条目、16 个独立事件。每一条都写清发生了什么、影响多大、段子里的公司要做什么。
架构告警图
按段子原文把这家公司的技术栈分成 6 层。指示灯颜色取该组件关联事故的最高严重度，闪烁表示需要立即处置。点击任意组件，右侧会显示事故摘要和对这家公司的影响。
- L1 · 边缘与入口
- L2 · 应用与中间件
- L3 · 数据与合约
- L4 · 运行时与内核
- L5 · 信任链
- L6 · 托管平台段子未提及，由用户补充
- L7 · 开发与办公段子未提及，由用户补充
先处理这 4 条
这 4 条要么已经确认是恶意代码，要么可以远程利用，而且这家公司的版本都在受影响范围内。INC-01 和 INC-11 是同一个内核漏洞，可以一起处理。
CVE-2026-99999：PwnEscape 虚拟机逃逸
第一步：安装发行版的修复内核并重启，用 uname -r 核对运行版本
PHP 双 RCE：CVE-2026-109618 与 CVE-2026-109619
第一步：升级到受支持分支的修复版（7.3 没有修复版）
LiteLLM 1.107.0 发布流水线被劫持
第一步：不要先运行 pip；先在 Shell 中删除 cook.pth、cook.py、sitecustomize.py
Linux 内核 c6e50df8：引入 PwnEscape 的那次提交
第一步：不要按 c6e50df8 判断补丁状态，核对 uname -r 和发行版公告
段子说的，和查到的
段子里的大多数梗都能对上真实事故，但有几处说法和事实不同。最意外的一处：按字面理解，“c6e50df8 之前”的内核反而没有这个漏洞。
段子说“CI 昨晚刚从 PyPI 拉了新包”
实际段子发于北京时间 10-22 00:42。LiteLLM 1.107.0 恶意包在北京时间 10-21 19:39 至 21:23 挂在 PyPI 上，时间正好对上。
段子说“CVE 99999”
实际这是真实编号 CVE-2026-99999，不是占位符。它是 Linux IPv4 校验和漏洞 PwnEscape，CVSS 9.3。
段子说“Linux 内核 c6e50df8 之前”
实际c6e50df8 是 2008 年引入漏洞的提交 f43798c 的末尾 8 位。字面上早于它的内核反而不含这个漏洞。修复提交是 6785011f8b16。
段子说“PHP-FPM 7.3，刚从 5.6 升级上来”
实际5.6 和 7.3 都在 PHP 双 RCE 的受影响范围内，而且都没有上游修复。几周的升级没有改变风险。
段子说“大价钱采购来的 TiDB NewDB”
实际PingCAP 没有叫 NewDB 的产品。真实事故是 PingCAP 内部系统被入侵，影响 TiDB Cloud 的账户和业务资料。日本官网确认，日本国内最多约 5 万件个人信息泄漏。
段子说“Node TLS 三个版本都有高风险”
实际“三个版本”指 22.x、24.x、26.x 三条发布线。高危项是两项 TLS 主机名绕过和一项 Brotli 越界写。
段子说“无保险低价 Sectigo DV 证书”
实际Sectigo 没有误签 DV 证书。它卷入事故，是因为给 eMudhra 的弱中间 CA 做过交叉签名。DV 证书也有面向依赖方的 warranty。
段子说“Traefik Ingress 开着 mTLS fail-open”
实际Traefik v3.7.0 至 v3.7.10 确实会在 TLS 选项冲突时静默放弃客户端证书校验，v3.7.11 修复。
段子说“emSign 代码签名”
实际eMudhra 的 8 个弱中间 CA 里有 2 个是代码签名 CA。拿到私钥的人可以伪造签名。