过去的48小时据说是网络安全历史上最严重的48小时

麦青儿

48小时内集中爆发网络安全事件，被称之为“黑色十月”。

最值得关注的三件事：
PHP2Shell漏洞 影响约70%的网站，多国政府将站点下线；
eMudhra证明网站真实性的主密钥被破解 ，网站身份验证的底层信任链出了问题；
加州公立学校学生数据全盗 ，从2023年起每个学生的全部数据包括残疾状态都被泄露。

安全风险也在扎堆：
Meta Muse暴露了用户个人和商业秘密——AI工具本身正在成为攻击载体，这个趋势值得警惕。
Railway：黑客从数百万开发者使用的托管平台窃取了客户的密钥
Zeabur：321,810个账户被入侵。公司正在关闭。
LiteLLM：一款每天下载340万次的AI工具被植入密码窃取器
GitLab：自2014年以来每个版本中有一个10分满分的严重漏洞
Cairn：犯罪分子使用AI黑客工具入侵了100多家公司
Ahold Delhaize：黑客使Food Lion和Stop & Shop的所有者下线
Onamae：恶意软件被植入日本多达26,739个客户服务器

普通用户能做的防护：
检查自己常用的网站是否用了PHP框架并及时更新补丁，警惕不明来源的AI工具下载、对涉及个人敏感信息的平台保持关注。

原文：
This is the most serious 48 hours in cybersecurity history.

"Black October" they're calling it

It seems every *hour* there's a new incident, that in a typical year, would be one of the biggest incidents of the *entire year*

SUMMARY OF THE LAST 48 HOURS:

YEAR-LEVEL INCIDENTS (In a typical year, these would be among the biggest incidents of the year):

1. PHP2Shell: a hole in the software behind ~70% of websites. Governments took sites offline.
2. eMudhra: the master keys that prove websites are real were cracked. One was the number 4.
3. California: data on every public school student since 2023 stolen, including disability status
4. Railway: hackers stole customers' secret keys from a hosting platform used by millions of developers
5. Zeabur: 321,810 accounts breached. The company is shutting down.
6. LiteLLM: an AI tool downloaded 3.4 million times a day was poisoned with a password stealer
7. GitLab: a 10-out-of-10 severity hole in every version since 2014
8. Cairn: criminals used an AI hacking tool to break into 100+ companies
9. Ahold Delhaize: hackers knocked the owner of Food Lion and Stop & Shop offline
10. Onamae: malware planted on up to 26,739 customer servers in Japan

MONTH-LEVEL INCIDENTS (In a typical month, these would be among the biggest incidents):

11. Signal: a bug could leave your mic and camera on after you hang up
12. NGINX: 3 critical holes in software running ~1/3 of websites
13. HTTP/3: a single connection can crash 7 of the 10 web server types tested
14. Plex: hackers breaking into home media servers
15. SafePay ransomware: FBI warns it has hit 600+ critical infrastructure organizations
16. Palo Alto: ransomware gangs breaking in through company firewalls
17. Bullhorn: platform used by 10,000+ companies knocked offline
18. Medi-Cal: 970,000 patients' data stolen
19. WordPress: hackers stole a plugin maker's keys and used them to plant backdoors on websites
20. AOMEI: backup software's update server handed out a backdoor
21. Meta Muse: Meta's AI agent exposed users' personal and business secrets
22. Tor: 333 relays hijacked to steal logins
23. TiDB Cloud: database company's cloud breached

Also serious:

24. State Bank of India: India's biggest bank confirms a data breach
25. OVHcloud: hackers slipped a password stealer into a cloud company's official tool
26. Siemens: a software hole being used to spread malware
27. North Korea: state hackers launch a new attack campaign on South Korea

麦青儿

一晚四个雷：PHP、Node.js、HTTPS证书、Railway同时被捅

【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 部署模型中的核心地位，这一事件的辐射范围难以在短期内精确界定。