[TechWeb]10月22日消息，从21日晚间至22日，不到24小时里，四起彼此独立的互联网安全事件在四个不同层面接连爆发：承载全球约70%网站的PHP语言、大量微服务与AI工具依赖的Node.js运行时、浏览器HTTPS小锁所依赖的证书信任链，以及开发者存放API密钥的云部署平台Railway。
PHP：最高危险级漏洞在AI手中现形，遭泄露提前引爆
最先震动业界的是PHP核心引擎中的两个漏洞，被统称为“PHP2Shell”，编号CVE-2026-109618与CVE-2026-109619。两者在CVSSv4.0下均获9.2分，属于最高危级别，攻击者无需任何认证即可在受影响服务器上远程执行代码或读取进程内存。受影响范围覆盖PHP8.2.34、8.3.35、8.4.26、8.5.11及更早版本。这些漏洞的代码根源可追溯至2012年的PHP5.4.0，而受影响版本链条则延伸至2004年的PHP5.x。（详细信息请见：AI一小时挖穿十年老雷？PHP惊天漏洞吓醒全球网站运维）
据悉，安全公司Calif在OpenAI的“PatchthePlanet”计划框架下，使用GPT-5.6Sol于8月1日识别出第一个漏洞，8月11日报告给PHP安全团队，8月21日报告第二个。几乎同一时间，Google旗下Wiz的研究团队也借助自研AI工具与Gemini4Argon、GPT-5.6Sol独立发现了问题。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.js26.x、24.x和22.x。
用户原文中提到的“解压模块”风险，指向的是另一条并行的漏洞路径：Node.js的decompress包存在路径遍历问题（CVE-2026-101894，CVSS9.1），攻击者通过植入符号链接链，可以在解压过程中读写输出目录之外的文件，进而覆盖启动脚本或配置文件，同样导向远程代码执行。维护中的`@xhmikosr/decompress`包已在10.2.2和11.1.4中修复，但已停止维护的`decompress`包直到4.2.1仍未修补。这意味着大量依赖旧版`decompress`的Node.js项目和工具链，即使升级了Node.js运行时本身，也可能仍然暴露在风险之中。
OpenAI总裁GregBrockman在评论PHP事件时，特意提到了Node.js同日披露的远程代码执行漏洞，将其作为“AI驱动漏洞发现正在加速”的旁证。Node.js生态中大量运行的微服务、命令行工具以及AIagent基础设施，使得这一层漏洞的传播面并不亚于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、Rustwebpki-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加速漏洞发现、开源基础设施老化与集中化信任风险三者交汇时，现有的互联网防御体系还能否完美承受这种集中压力测试？