【TechWeb】10月22日消息，从21日晚间至22日，不到 24 小时里，四起彼此独立的互联网安全事件在四个不同层面接连爆发：承载全球约 70% 网站的 PHP 语言、大量微服务与 AI 工具依赖的 Node.js 运行时、浏览器 HTTPS 小锁所依赖的证书信任链，以及开发者存放 API 密钥的云部署平台 Railway。
PHP：最高危险级漏洞在 AI 手中现形，遭泄露提前引爆
最先震动业界的是 PHP 核心引擎中的两个漏洞，被统称为“PHP2Shell”，编号 CVE-2026-109618 与 CVE-2026-109619。两者在 CVSS v4.0 下均获 9.2 分，属于最高危级别，攻击者无需任何认证即可在受影响服务器上远程执行代码或读取进程内存。受影响范围覆盖 PHP 8.2.34、8.3.35、8.4.26、8.5.11及更早版本。这些漏洞的代码根源可追溯至2012年的 PHP 5.4.0，而受影响版本链条则延伸至 2004 年的 PHP 5.x。
据悉，安全公司 Calif 在 OpenAI 的“Patch the Planet”计划框架下，使用 GPT-5.6 Sol 于 8月1日识别出第一个漏洞，8月11日报告给 PHP 安全团队，8月21日报告第二个。几乎同一时间，Google 旗下 Wiz 的研究团队也借助自研 AI 工具与 Gemini 4 Argon、GPT-5.6 Sol 独立发现了问题。OpenAI 在事后声明中称，这是“近年来影响最严重的安全问题之一”，并强调“前沿 AI 在攻击者之前发现了这些漏洞”。Wiz 研究人员的评价更为直白：“这些发现是 PHP 中最严重的漏洞之一，也可以说是软件史上最严重的漏洞之一”。
要命的是，当地时间10月20日，一则匿名帖子提前泄露了漏洞即将公布的消息，截图在社交媒体扩散。PHP 安全团队被迫将补丁发布时间提前至21日。
截至目前，PHP维护者发布了 8.5.12、8.4.27、8.3.36 和 8.2.35 四个修复版本，但 8.1 及更早版本的用户只能自行编译源码补丁，或选择升级到受支持分支。根据 Mallory 的分析，在约 150 万台报告 PHP 版本的面向互联网主机中，59%（约 88.4 万台）运行的是不会获得官方修复的分支，中国、韩国和中国香港的未修补占比尤为突出。
美国国家安全局（NSA）在补丁发布当天发出警告，建议无法立即修补的网站“直接从网上撤下”。
Node.js： Brotli 解码器与 decompress 包的双重 RCE 风险
同一时间，Node.js 发布了最高严重级别的安全更新，针对 6.x、24.x 和 22.x 系列修复了 10 余个漏洞，其中包含 4 个高危漏洞。
最受关注的是 CVE-2026-111497：Brotli 解码器中的越界写入缺陷，攻击者可通过构造恶意请求触发内存损坏，进而实现远程代码执行，影响 Node.js 26.x、24.x 和 22.x。
用户原文中提到的“解压模块”风险，指向的是另一条并行的漏洞路径：Node.js 的 decompress 包存在路径遍历问题（CVE-2026-101894，CVSS 9.1），攻击者通过植入符号链接链，可以在解压过程中读写输出目录之外的文件，进而覆盖启动脚本或配置文件，同样导向远程代码执行。维护中的 `@xhmikosr/decompress` 包已在 10.2.2 和 11.1.4 中修复，但已停止维护的 `decompress` 包直到 4.2.1 仍未修补。这意味着大量依赖旧版 `decompress` 的 Node.js 项目和工具链，即使升级了 Node.js 运行时本身，也可能仍然暴露在风险之中。
OpenAI 总裁 Greg Brockman 在评论 PHP 事件时，特意提到了 Node.js 同日披露的远程代码执行漏洞，将其作为“AI 驱动漏洞发现正在加速”的旁证。Node.js 生态中大量运行的微服务、命令行工具以及 AI agent 基础设施，使得这一层漏洞的传播面并不亚于 PHP，只是其触发条件通常需要应用处理来自不可信来源的压缩包或 Brotli 编码数据。
eMudhra：HTTPS 小锁的根基被“算出来”
第三起事件发生在互联网信任链的最底层。
印度证书颁发机构 eMudhra 旗下的 8 张中间 CA 证书被发现在私钥生成环节存在严重缺陷：私钥的随机性严重不足，部分私钥所对应的整数仅为 4、56、66、115、155、156、230、237 这样的个位数或两位数。正常 P-384 椭圆曲线私钥应具备 384 位伪随机安全性，而上述缺陷使得研究人员可以从公开的证书数据中直接计算出私钥。
私钥可被计算意味着什么？中间 CA 证书的私钥持有者，可以为任意网站签发浏览器会信任的 TLS 证书。攻击者一旦掌握这些私钥，就可以伪造银行、邮箱、社交平台甚至软件更新服务器的 HTTPS 证书，而用户浏览器地址栏中的“小锁”不会发出任何警告。受影响证书涵盖域名验证、组织验证、扩展验证以及代码签名等多种类型。
浏览器与操作系统厂商的反应速度罕见地一致。Mozilla 在10月17日收到报告后，据称在两小时内恢复了私钥。Chrome 和 Firefox 自 10 月 17 日起封锁全部 8 张证书，Apple 于19日跟进，Microsoft 于 20 日封锁，eMudhra 则在自身端撤销了整批证书。Go、NSS、certifi、Rust webpki-roots、Homebrew、Composer 等信任存储也相继移除或不再信任受影响的证书链。eMudhra 事后确认，问题源于 2025 年 4 月 30 日一次密钥生成仪式中的流程缺陷，在生成 24 张从属 CA 的密钥时，一个 wrap/unwrap 步骤错误地生成并使用了第二套弱密钥。
HTTPS 信任模型的安全性，长期被理解为“私钥不会被偷”，但 eMudhra 的案例表明，弱密钥生成可以使私钥在数学上被“算出来” ，而且问题可以在证书投入生产一年半之后才被外部研究者发现。浏览器厂商的紧急吊销阻止了最坏情况，但吊销本身也意味着依赖这些中间证书的合法站点和服务需要经历一次被迫的证书迁移。
Railway：密钥存储系统被闯入，暂停部署让“换钥匙”本身成为难题
第四起事件落在开发者云平台 Railway。
10月21日晚间，Railway 检测到存储客户环境变量的系统出现异常活动。初步调查显示，未经授权的第三方可能访问了加密的环境变量，并获取了部分变量的解密后明文内容。这些变量通常存放 API 密钥、数据库密码和私有镜像仓库凭证，对于许多使用 Railway 部署 AI 应用的开发者而言，这意味着 Stripe、OpenAI、Anthropic 等服务的密钥可能已经外泄。
Railway 在事件披露：这起入侵“属于近期针对平台类公司的系列攻击之一，目的是入侵 AI 推理服务商”。这一归因如果成立，意味着攻击者的目标并非 Railway 本身的数据，而是通过云平台获取下游 AI 服务商的密钥，进而盗用推理算力或访问敏感数据。
平台采取的紧急措施包括：暂停所有构建与部署，主动重置平台上保存的全部存储桶密钥和 GitHub 凭据，并通知上游服务商吊销相关密钥。
然而，暂停部署本身制造了一个操作性困境：用户被要求立即轮换密钥，但在部署管道冻结的情况下，即使更换了密钥，也无法将更新后的配置重新部署上线，导致部分应用处于“有钥匙但无法开门”的状态。Railway 后续恢复了构建功能，但用户仍需重新部署才能使轮换后的密钥生效。平台声明受影响的是“部分客户”，而非全部用户，但鉴于环境变量在 Railway 部署模型中的核心地位，这一事件的辐射范围难以在短期内精确界定。
值得注意的是，这四者并非同一攻击活动的组成部分，但它们在极短时间窗口内的叠加，加深了“互联网正在变得更不安全”的直觉判断。
事实上，互联网一直承载着这些风险，只是 AI 让一部分长期隐藏的风险变得可见。这也暴露出一个值得追问的问题：当AI加速漏洞发现、开源基础设施老化与集中化信任风险三者交汇时，现有的互联网防御体系还能否完美承受这种集中压力测试？
“掌”握科技鲜闻 （微信搜索techsina或扫描左侧二维码关注）
