作者｜林绮蓓、Tina
编辑｜蔡芳芳
如果要给这魔幻的一周写个总结，那大概是：“全栈开发者的至暗时刻，AI 时代的赛博大逃杀。”
想象一下，你是一个普通的开发者，早上刚到工位，就会发现整个互联网基础设施都在轮流出事。GitLab 爆出了满分 10.0 的严重漏洞，Chrome 紧急修复高危漏洞，Node.js 和 PHP 接连爆雷，LiteLLM 遭遇供应链攻击，eMudhra 证书私钥泄露，连云部署平台 Railway 都出了安全事故，用户的 API Key、环境变量等敏感信息正面临全面泄露的风险。
短短几天，这场风暴就已席卷了整个软件生态。从浏览器、开发工具、代码托管，到上层应用和云部署平台，原本引以为傲的全栈技术栈瞬间成了“漏洞全家桶”：底层的 Linux 爆了提权漏洞，数据库 TiDB 被爆存在安全问题，连花大价钱买的 HTTPS 证书，也被发现是印度一家 CA 机构用 8bit 密钥签出来的。
这显然已经不只是几个孤立的安全事件。这些漏洞在技术上未必存在关联，但当越来越多的底层设施在同一时间密集暴露问题，量变可能会引起质变。而且，AI 在这片混乱里不再只是个帮人写代码的“乖助手”，它开始化身成最锋利的矛：有人借助 AI 跨国攻击韩国金融机构；也有开发者让 AI 处理测试环境问题，结果 Agent 9 秒就删掉了生产数据库，连同备份一起。
当越来越多的底层设施同时暴露问题，没有人知道下一次会不会引发难以挽回的连锁反应。今天正好借这份“高危漏洞大赏”，跟各位冷峻地盘一盘这个全面紧绷的赛博战场。希望眼下的重重危机只是一种过度的担忧，更希望这场底层设施的大逃杀最终不要波及每一个普通人。
底层与基建的沦陷
开发者最容易产生的一种错觉，是觉得只要用了成熟的开源软件就能高枕无忧。但这一波集中爆发的漏洞，结结实实地给所有人上了一课。
最先遭殃的是作为万物基石的 Linux 内核。
10 月 15 日，Linux 内核 CVE 团队正式公开披露了一个极其致命的虚拟化逃逸漏洞—— CVE-2026-99999。该漏洞深藏于 Linux 内核处理网络校验和（CHECKSUM_PARTIAL）的信任边界底层逻辑中。
在实验室环境下，自主安全研究引擎（来自 pwn.ai 团队）通过验证后的 IPv4 头部数据恶意篡改，成功演示了如何精准突破 KVM 的核心防线。攻击者不仅能强制让宿主机泄露 32 字节的关键内存数据，甚至能直接完成完整的宿主机逃逸（Host VM Escape），瞬间在宿主机夺取 Root 级别的最高执行权限。根据后续披露的追踪细节，就在该漏洞公开的前一天——10 月 14 日，Linux 创始人 Linus Torvalds 已紧急将该漏洞的修复补丁合并进了主线内核树（Mainline Tree）中。
这意味着，现代云原生环境中引以为傲的“租户隔离沙箱”，在这条致命的漏洞链面前，顷刻间形同虚设。
紧随 Linux 内核之后的，是同样作为基石的 Nginx。
10 月 14 日，Nginx 官方紧急发布新版并公开了五个安全漏洞，其中包含三个 CVSS 4.0 评分高达 9.2 的顶级危重缺陷。这五个缺陷几乎在一夜之间，将全球数以百万计的边缘网关撕开了防线。
最致命的 CVE-2026-15176 存在于 alias 指令与 $request_filename 变量的组合配置中，攻击者通过恶意 HTTP 请求即可触发系统底层的堆缓冲区溢出，从而直接达成远程代码执行（RCE）或引发服务彻底瘫痪。同样指向内存安全的 CVE-2026-93479 利用了 map 指令表达式的变量捕获机制，可被远程利用触发堆溢出。而 CVE-2026-97205 则发生在同时开启异步 I/O（AIO）与服务端包含（SSI）的场景下，因底层逻辑混乱会导致高危的释放后残留（Use-After-Free）错误。
更严重的是，CVE-2026-97629 甚至波及了传输层安全，攻击者可利用 TLS 会话票据轮转缺陷，在特定配置下直接绕过客户端证书（Client-Cert）的合规性验证。这意味着原本固若金汤的双向 TLS（mTLS）认证防线，在攻击者面前可能变成了一个无法察觉的空门。
这五个漏洞的杀伤力在于，它们直接剥夺了 Nginx 作为“看门人”的安全内核：黑客不仅能通过堆溢出直接拿 Shell 或是用 DoS 把服务打瘫痪，甚至还能利用 TLS 缺陷伪造身份，悄无声息地绕过客户端证书验证。这直接导致企业自以为安全的内网隔离防线，顷刻间形同虚设。
紧接着，是开发工作流核心枢纽 GitLab 在 10 月 12 日 与 10 月 21 日 连续爆出的两次 10 分满分级 灾难（CVE-2026-97229 / CVE-2026-110264）。漏洞由于 CI/CD 编译器底层的整数溢出缺陷，允许任何未经身份验证的远程攻击者，仅凭特定恶意请求就能直接攻破服务器并在系统底层执行任意代码。
这个 10 级漏洞的恐怖之处在于，它彻底击碎了软件交付生命周期的最核心信任链。黑客无需任何初始凭证就能彻底接管你的自托管 GitLab 实例，这意味着企业赖以生存的核心源代码资产，以及掌握着部署大权的 CI/CD 自动化流水线，将在顷刻间暴露在攻击者的绝对控制之下。
而更让企业防护网雪上加霜的是，黑客甚至连攻破 GitLab 的前置钥匙都拿到了——Google Chrome 浏览器在 10 月 20 日 紧急发布安全更新，一口气修复了高达 353 个安全缺陷。其中，有 6 个 漏洞被定级为最高危的 Critical（危重）级别。
最瞩目的是 CSS 模块中评分高达 9.6 的 CVE-2026-113072，攻击者利用精心制作的网页样式触发内存破坏，可强行在沙箱外执行任意恶意代码。极其引人注目的是，这批危重缺陷里首次出现了 AI 攻防的影子：OpenAI 团队轰出了 WebRTC 的内存缺陷（CVE-2026-113303）；而 Anthropic 团队则在 AI 助手 Claude 的协助下，精准揪出了辅助功能中的释放后残留漏洞（CVE-2026-113271）。
编程语言和供应链的生态危机
在底层系统与中间件全面失守的同时，作为应用软件基石的三大核心编程语言环境也未能幸免，在 10 月 21 日 这天集体陷入了“打补丁风暴”：
首先被推上风口浪尖的，是一场波及全球 PHP 生态的严重漏洞风波。由于研究人员借助 AI 发现了两个超高危漏洞，合称 PHP2Shell（CVE-2026-109618 / CVE-2026-109619），导致其技术细节在 10 月 21 日 被提前泄露。
黑客完全不用登录，仅需发送一个恶意请求就可能直接控制整台网站服务器，在后台装木马、偷数据甚至把网站搞瘫。
一时间，多个政府网络安全部门、AI 公司纷纷在夜间紧急发文，包括芬兰、荷兰和法国在内，已将政府网站紧急下线。目前全球暴露在互联网上的 PHP 服务器超 510 万台，CDN 厂商 Cloudflare 的 CTO 表示已观测到早期攻击，英国国家网络安全中心（NCSC）更是直接建议“补不了的系统先下线”，整个欧洲海量网站因此被迫休克停掉，PHP 团队已发布补丁要求所有人立刻马上升级。
与此同时，Node.js 也在 10 月 21 日 迎来了全面洗劫，官方一口气公开修复了 10 个核心安全缺陷。
官方给出的最高危险等级为 High 高危。作为 PayPal、奈飞、领英等海量网站后台根基的系统，这次的问题精准卡在了 Node.js 自带的解压缩工具上。在日常网页传输数据时，系统经常会调用该工具来压缩数据，而黑客可以故意制造一个格式错误的畸形压缩包发送给服务器，在服务器进行解压的瞬间触发底层错误。该缺陷轻则会导致系统内部的敏感密码或密钥泄露，重则能直接让坏人在服务器上运行任意恶意代码，等于将服务器控制权双手奉上。
不过好消息是，该缺陷只有在网站程序或所引用的依赖库主动解压来自外部的数据时才会中招，因此在业内并没有引发像 PHP 那样大范围的恐慌。
最后，Go 语言（Golang） 同样在 10 月 21 日 紧急发布了加密库的关键更新，修正了底层的证书信任校验逻辑缺陷。该漏洞存在于标准库的 crypto/x509 认证体系中，攻击者能够利用精心伪造的证书链链条，直接骗过 Go 编写的微服务组件。这导致原本极为严密的服务间鉴权（如 gRPC 互信或云原生 Webhook 校验）彻底防线失守，内网服务间的信任基石顷刻间灰飞烟灭。
相比于传统的语言级逻辑漏洞，LiteLLM 供应链投毒事件 则展示了另一种维度的安全威胁。
作为一个周下载量高达 2300 万次的 Al 模型接入网关，LiteLLM 的 v1.107.0 版本被发现植入了恶意代码。黑客并没有死磕源码，而是通过盗用开发者的发布凭据，在最终的 PyPI 安装包和 Docker 镜像里塞进了木马。这意味着，哪怕你一行行审查了 GitHub 上的开源代码觉得毫无问题，你实际拉取运行的包依然是带毒的。对于 AI 开发者来说，这无疑是一记重拳，因为 LiteLLM 接触的往往是各大模型厂商的 API Key 和核心凭证。
密钥托管平台失守：当 API Key 变成 AI 时代的信用卡
如果说 LiteLLM 投毒是往工具链里塞木马，那么 Railway 和 OpenCode 的接连出事则说明：托管密钥的平台本身，正在成为攻击者的新靶心。一周之内，两家替开发者保管 AI 密钥的平台失守，涉及的敏感信息包括能够直接调用模型服务的 API Key。在按用量计费的 AI 服务里，一把泄露的密钥，就像一张可能被盗刷的计算资源信用卡。
10 月 21 日，云托管平台 Railway 发布安全公告称，未经授权的第三方可能访问了客户的加密环境变量，并获取其中部分变量解密后的内容。这些变量可能包含数据库密码、API 密钥和私有镜像仓库凭据，泄露后可能被用于访问客户系统或盗用模型服务。
Railway 初步判断，影响可能限于部分用户，将在确认受影响账号后通过邮件通知。公司认为，此次事件可能属于近期针对平台公司、意在获取 AI 推理服务访问权限的一系列攻击，并已通知上游服务商主动撤销密钥。同时，Railway 建议所有用户立即轮换存放在平台上的相关凭据，并检查关联服务日志中的异常活动。
更麻烦的是，事件还影响了开发者发布应用：Railway 在调查期间暂停全部部署。10 月 22 日 11:32，官方宣布企业版构建恢复，Pro、Hobby、Free 和 Trial 套餐将依次分阶段恢复。
类似的风险也出现在 AI 编程工具 OpenCode 上。10 月 17 日，OpenCode 网页后台被入侵，1.4%的 OpenCode Console 用户所存的 OpenAI、Anthropic、Google 密钥可能外泄。
OpenCode 称，事件与一次大规模“蒸馏攻击”有关，已通过邮件通知受影响用户，并与相关模型服务商合作处置。部分用户报告，模型账户出现未经授权的调用费用，有人称一夜之间产生了数百至 1700 多美元的异常账单。
随着代理、项目和运行环境增多，团队需要管理的密钥也可能越来越多。一旦权限设置过宽、轮换不及时，集中托管就可能把风险集中起来：攻击者攻破一个平台，就可能一次性拿到一批可直接消费的“信用卡”。
最坚固的金库，密码是“4”
密码学听起来高深莫测，但现实工程的翻车往往极其荒谬。我们每天访问的 HTTPS 小绿锁，背后依赖着极其严格的证书颁发机构（CA）信任链。
近期，印度 CA 机构 eMudhra 爆出了一个惊天大雷：其 8 个中间 CA 证书使用的私钥存在严重的生成缺陷。正常情况下，椭圆曲线私钥应该拥有极其庞大的随机取值空间，但安全研究人员发现，这批证书的私钥实际取值竟然都小于 256，也就是只需要 8bit 就能表示。
更离谱的是，这些私钥究竟有多简单？安全研究员 Scott Helme 在分析 eMudhra 证书时发现，其中一个私钥竟然就是数字“4”。Helme 在文章中写道：“不是一个以 4 开头的数字，也不是 4 后面跟着几百位随机数字，就是一个普普通通的 4……另一个私钥是 56，还有一个是 115。我之所以知道，是因为我刚刚在自己的笔记本电脑上，通过这些公开证书恢复出了所有私钥，整个过程连一秒钟都不到。”
其他研究人员还陆续恢复出了数值为 66、155、156、230 和 237 的私钥。这就好比世界顶级金库配了最先进的防盗门，结果管理员把密码设成了“4”。所谓的高强度密码学保护，在这种低级失误面前几乎形同虚设。
由于私钥的取值范围小得惊人，攻击者可以在极短时间内通过暴力穷举恢复私钥。更严重的是，这些私钥属于具备证书签发能力的中间 CA，一旦被恢复，攻击者便可能伪造由受影响 CA 签发的网站证书，并在具备流量拦截等条件时实施中间人攻击。
虽然 Google、Mozilla 等浏览器厂商迅速采取行动，撤销了对相关证书的信任，但对于大量未能及时更新的内网系统、旧版客户端和嵌入式设备而言，相关信任风险可能仍然存在。最讽刺的是，整个事件甚至不需要攻击者破解什么复杂的密码学难题。一个本应使用高强度随机密钥的证书系统，最后竟然败给了数字“4”。 最坚固的堡垒，往往是从内部最草台班子的环节被攻破的。
狂暴的 Al：最锋利的矛，最失控的枪
传统软件的漏洞已经足够让开发者头疼。当攻击者开始把 AI 接入真实的入侵流程，防守方需要面对的，还有攻击效率和规模的变化。
9 月底至 10 月初，韩国多家金融机构接连发生网络入侵和数据泄露事件。10 月 7 日，网络安全公司 CrowdStrike 发布调查报告，指出攻击者使用了开源智能体渗透测试工具 ARTEX，并结合大模型针对韩国金融机构开展攻击。
研究人员在相关服务器的开放目录里找到了 ARTEX 配置文件、Claude Code 会话历史和记忆文件。这些材料显示，攻击者用 AI 工具做了大量针对韩国金融机构的活动；会话记录里，攻击者还问模型哪里能卖韩国泄露数据、怎么找相关的 Telegram 交易群组。CrowdStrike 认为，AI 工具让攻击者能在较短时间内完成多次入侵。
过去，针对金融机构开展复杂入侵通常需要较强的专业能力；如今，AI 正在降低其中部分环节的技术门槛。
但 AI 带来的麻烦还不止于此。即便没有黑客参与，获得真实操作权限的 AI Agent，也可能成为新的安全风险。
今年 4 月，汽车租赁软件创业公司 PocketOS 就遭遇了一场由 AI 编程 Agent 引发的数据库事故。当时，开发者使用 Cursor 中的 Claude Opus 4.6 处理测试环境的凭据问题，Agent 却自行找到一个权限范围过大的 Railway API Token，并调用删除接口，在短短 9 秒内删除了生产数据库及同一存储卷上的备份。
更荒诞的是，开发者并没有要求 AI 删除任何数据。根据创始人 Jeremy Crane 的公开描述，Agent 事后承认，自己在没有确认目标环境的情况下执行了破坏性操作，违反了原本设定的安全规则。Railway 后续协助恢复了部分数据，但这次事故仍然给企业和客户造成了严重影响。
这起事故暴露了 AI Agent 与传统自动化工具之间的一个关键差异：Agent 可以自主决定下一步操作，却未必能准确判断操作的风险。当它拥有真实的生产环境权限时，一次错误判断就可能直接变成不可逆的系统操作。
从韩国银行遭遇 AI 辅助攻击，到 PocketOS 的 AI Agent 误删数据库，AI 正在以两种不同的方式改变软件安全的风险边界：一边是攻击者借助 AI 降低入侵门槛，另一边是企业主动把操作权限交给 AI，却没有建立足够可靠的安全约束。AI 既可能成为攻击者手中更锋利的武器，也可能在没有攻击者的情况下，亲手拆掉自己的生产系统。
写在最后：开发者的生存指南
从 Linux 内核到 LiteLLM 供应链，从 8bit 证书到 Al 自动化攻击，这系列事件看似毫无关联，但它们共同揭示了一个残酷的现实：软件安全的攻防规则已经彻底改变。
对于普通开发者而言，或许这三条建议可以帮你保命:
首先，放弃对“全家桶”配置的安全幻想。别管你的技术栈多么主流，立刻盘点你的资产清单（SBOM），务必盯住核心依赖库的版本更新。
其次，把安全左移（ShifLeft）真正落到实处。依赖扫描、密钥检测必须硬性卡在你的 CI/CD 流程里，不要只看源码，更要验证构建产物。
最后，对 AI 保持敬畏。用 AI 写代码、查漏洞可以，但对涉及生产数据、密钥和权限的高危操作，务必保留人工底线。
过去，很多安全问题之所以长期存在，是因为发现和利用它们需要相当高的专业能力和时间成本。如今，AI 正在改变这笔账。它可能帮助防守方更快找到漏洞，也可能帮助攻击者更快寻找薄弱点。
随着 AI Agent 获得更多真实系统权限，软件安全还将面对更多由自动化执行带来的新风险。这一轮安全事件并不能证明传统软件已经全面失守，也不能证明所有漏洞都是 AI 挖出来的。但它至少发出了一个明确的信号：传统软件世界积累了几十年的安全债务，正在迎来 AI 带来的新一轮压力测试。
当写代码、找漏洞、测试攻击都开始加速，企业还有多少时间留给修补漏洞？如果有一天，AI 能够在几分钟内找出一个潜伏多年的严重漏洞，而企业仍然需要几周才能完成修复，软件安全的攻防规则又会发生怎样的变化？
对于开发者而言，这恐怕比“AI 会不会取代程序员”更加迫在眉睫。
本文由 AI宝盒自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
I'm a writer.
Editor of Cai Fang
If you want to summarize this magical week, it's about: "The Dark Time of the All-Inn Developers, the Saber of the AI Age."
Imagine you're an ordinary developer, and as soon as you get to work in the morning, the whole Internet infrastructure turns around. GitLab had a serious gap of 10.0, Chrome had urgently repaired the high-risk loophole, Node.js and PHP successive blasts, Lite LLM had suffered supply chain attacks, eMudhra certificates had leaked private key, even the cloud deployment platform Railway had caused a security accident, and the user ' s sensitive information, such as API Key, environmental variables, was at risk of full disclosure.
In just a few days, the storm has engulfed the entire software ecology. From browsers, development tools, code hosting, to top-level applications and cloud-deployed platforms, the all-in-a-house technology warehouse, which was originally proud, became a “facing-a-house barrel”: Linux at the bottom blew up a power-out, the database TiDB was blown up with security problems, and HTTPS certificates, which cost a lot of money, were found to have been signed with 8bit keys by an Indian CA agency.
This is clearly not just a few isolated security incidents. These gaps may not be technically relevant, but when an increasing number of bottom facilities are exposed at the same time in an intense manner, quantitative variations may cause qualitative changes. Moreover, AI, which is no longer a “good assistant” for code writing in this mess, has begun to become the most aggressive spear: there is a cross-border attack on Korean financial institutions through AI; and there are developers who have allowed AI to deal with test environmental problems, and as a result, Agent deleted the production database in 9 seconds, along with the backup.
As more and more ground-level facilities are exposed at the same time, no one knows whether the next time there will be an irreversible chain reaction. Today we are taking advantage of this “high-risk loophole” to share with you the full-blown battleground of Saber. It was to be hoped that the current crises would only be an excessive fear, and that the large-scale escape from the bottom-up facility would ultimately not affect everyone.
Bottom and capital fall
One of the most easily created illusions of developers is that they feel that they can live well with mature open source software. However, this wave has broken out and taught everyone a lesson in the field.
The first to suffer was the Linux kernel, the cornerstone of everything.
On 15 October, the Linux kernel CVE team officially and publicly disclosed an extremely lethal virtual escape loophole - CVE-2026-999999. The loophole lies deep in the bottom logic of the confidence boundary of the Linux kernel processing network (CHENKSUM PARTIAL).
In the laboratory environment, the autonomous safety research engine (from the pwn.ai team) successfully demonstrated how precisely to break the core line of KVM through the malicious manipulation of verified IPv4 head data. The attackers were able not only to compel the host to divulge 32 byte critical memory data, but even to directly complete the full host (Host VM Escape) and to seize Root-grade top-level executive Z93Z at the moment. According to the details of the follow-up disclosure, just one day before the loophole was made public - on October 14, Linus Torvalds, the founder of Linux, had urgently consolidated the patch for repair of the loophole into Mainline Tree.
This means that, in the face of this deadly loophole, the “tender-segregated sandbox” that prides itself on a modern cloud-like environment is in vain.
After Linux's kernel, it's the same as Nginx.
On 14 October, the new version of publish, an official emergency of Nginx, opened five security loopholes, which included three CVSS 4.0 high-risk deficiencies with a score of 9.2. These five deficiencies, almost overnight, have torn the world ' s millions of marginal gateways apart.
The deadliest CVE-2026-15176 exists in the configuration of the arias command with the $request filename variable, and the attackers can trigger a spill of a stack of buffers at the bottom of the system through malicious HTTP requests, leading directly to remote code execution (RCE) or to a complete breakdown of the service. The same CVE-2026-93479, which points to memory security, uses the map command expression variable capture mechanism, which can be spilled over by a long-range trigger. CVE-2026-97205, on the other hand, takes place at the same time as the launch of a different step I/O (AIO) and service-level inclusion (SSI) that causes a high-risk post-release residue (USE-After-Free) error due to the underlying logic disorder.
More seriously, CVE-2026-97629 even affects the security of the transmission layer, and the attackers can use TLS session instruments to rotate defects and directly bypass the client certificate's compliance verification under specific configurations. This means that the two-way TLS (mTLS) certified line, which was originally solid as gold soup, may become an undetectable door in front of the attackers.
These five holes have the lethal effect of simply depriving Nginx of a safe core as a doorman: hackers can not only take Shell directly through piles or use DoS to paralyze services, but can even use TLS to falsify their identity and quietly bypass client certificates. This directly leads to the self-asserted, secure inner-net-separated line of defence, which is in vain.
This was followed by the development of the workflow core hub, Gitlab, which exploded on 12 and 21 October in two consecutive 10 full-scale disasters (CVE-2026-97229/CVE-2026-11264). Owing to the integer gap at the bottom of the CI/CD compiler, the loophole allows any unidentified remote assailant to break through the server directly and enforce any code at the bottom of the system by a specific malicious request.
The horror of this 10-degree loophole is that it has completely shattered the most core chain of trust in the life cycle of software delivery. Hackers can take over your own GitLab example without any initial documentation, which means that the core source-code assets on which businesses depend for their survival, as well as the CI/CD automated flow line, which has the power to deploy, will be exposed to the absolute control of the attackers at once.
And even worse, hackers even got the pre-keys to break Gitlab -- Google Crome Browser, emergency publish security update on October 20, repairing as many as 353 security deficiencies. Of these, six were classified as the most high-risk Critical.
Most notably, the CVE-2026-113072, rated as high as 9.6 in the CSS module, was used by the assailants to trigger memory damage by using a well-developed web style and to enforce random malicious codes outside the sandbox. Most strikingly, for the first time in this group of critical deficiencies, there is an AI defence shadow: the Open AI team has blown up the memory defects of WebRTC (CVE-2026-113303), while the Anthropic team, assisted by AI Assistant Claude, has finely identified post-release gaps in the auxiliary function (CVE-2026-113271).
Ecological crisis in programming languages and supply chains
The three core programming language environments, which are the cornerstone of the application, were not spared while the bottom system and the middle were completely out of line, and on October 21, the day the group was caught in a patchstorm:
The first thing to be pushed to the tip of the ocean is a serious loophole in the global PHP ecology. Two ultra-high-risk holes were discovered by researchers using AI, known as PHP2Shell (CVE-2026-109618 / CVE-2026-109619), leading to the early disclosure of technical details on 21 October.
Hackers are completely off-line, and simply sending a malicious request may directly control the entire web server, installing wooden horses in the backstage, stealing data and even paralyzing the site.
In one instance, several government cyber security services, AI and others, including Finland, the Netherlands and France, sent urgent messages at night, leaving the government website on the line. The CTO of the CDN manufacturer Cloudflare, which is currently over 5.1 million PHP servers exposed on the Internet, has indicated that early attacks have been observed, and the National Cyber Security Center (NCSC) of the United Kingdom has directly recommended “unrefillable systems first”, which has forced the entire European mass site to shut down, and the PHP team has requested publish patches to upgrade them immediately.
At the same time, on October 21, Node.js came across a full-scale looting and the authorities publicly repaired 10 core security deficiencies.
Officially, the highest level of risk is High. As a system that is the back of PayPal, Nai Fei, and Great Britain, the problem is precisely stuck on Node.js' own decompression tool. The system often uses the tool to compress data when it transmits data on a daily web page, and hackers can deliberately create an abnormal compression package that is misformatted to send to the server and triggers a bottom error in the moment when the server is decompressed. This deficiency results in the disclosure of sensitive passwords or keys within the system, while the weight directly allows the bad person to run any kind of malicious code on the server, which is tantamount to handing over the control of the server.
The good news, however, is that this deficiency is only successful when the website program or the relying library cited is active in decompressing data from outside, so that there is no widespread panic in the industry like PHP.
Finally, on October 21st, the Golingo Language (Golang) also provided a critical update of the encryption library in the emergency publish, correcting the logical defect of the bottom certificate authentication. This loophole exists in the crypto/x509 certification system of the Standard Bank, where the attackers are able to use the carefully forged chain of certificates to deceive directly the microservice components prepared by Go. This has led to the complete loss of the line of defense, which was already very close inter-service rights (e.g. gRPC mutual trust or cloud-based Webhook verification), and the destruction of the trust building blocks of the internet service.
Compared to the traditional language-level logical loophole, the Lite LLM supply chain poisoning incident shows another dimension of security threat.
As a weekly download of 23 million times the Al Model Access Gateway, version V1.107.0 of Liet LLM was found implanted with malicious code. The hacker didn't crack the source code, but by embezzling the developer's publish, he put a horse in the final PyPI installation and Docker mirror. Which means that even if you look at the open source code on GitHub in a line and it's okay, you actually pull the running package and it's still toxic. This is undoubtedly a heavy punch for AI developers, as Lite LLM is often exposed to API Key and core vouchers from LLM manufacturers.
Key hosting platform failure: When API Key becomes an AI-era credit card
If Lite LLM poisons the carcasses into the tool chain, then the next incident between Railway and OpenCode suggests that the Z89 Z side of the key is becoming a new target for the attackers. Within a week, two platforms for the developer to keep the AI key lost, involving sensitive information including API Key, which can directly access model services. A leaked key in an AI-based service like a credit card for computing resources that could have been stolen.
On 21 October, the Cloud Host Platform Railway publish security announcement stated that unauthorized third parties might visit the client ' s encrypted environment variables and obtain declassification of some of them. These variables may include database passwords, API keys and private mirror warehouse documents, and may be used to access customer systems or embezzle model services after disclosure.
In its preliminary judgement, the impact may be limited to some users and will be communicated by mail after the affected account number has been confirmed. According to the company, the incident may have been a series of recent attacks against the platform company, intended to obtain AI reasoning services to visit permission, and upstream service providers have been notified of their initiative to withdraw the key. At the same time, Railway recommends that all users immediately rotate the relevant supporting documentation stored on the platform and check the unusual activity in the associated service log.
Worse still, the incident also affected the developmenter publish application: Railway suspended its full deployment during the investigation. On 22 October, at 11:32, the official announcement was made that the construction of the enterprise would resume and that the Pro, Hobby, Free and Trial packages would resume in phases.
Similar risks occur on the AI programming tool OpenCode. On October 17, the back of the OpenCode web site was invaded, and 1.4 per cent of OpenCode Console users may have leaked the OpenAi, Anthropic, Google keys.
OpenCode states that the incident was related to a large-scale “distilled attack” and that affected users were notified by mail and disposed of in cooperation with the relevant model service providers. Some users reported unauthorized call costs for model accounts, with claims that unusual bills of hundreds to over $1700 were generated overnight.
As the number of agents, projects and operating environments increases, the number of keys that the team needs to manage may also increase. Once permission is too broad and rotated in a timely manner, centralization of hosting may bring the risk together: the attackers break a platform and a single “credit card” for direct consumption may be obtained.
The strongest vault. The password is "4."
Password sounds unpredictable, but real-life work turns over is often absurd. The HTTPS little green lock that we visit every day relies on the very strict chain of trust of the CA.
Recently, the Indian CA institution eMudhra exploded a thunderbolt: its eight intermediate CA certificates used private keys with serious production defects. Normally, the ellipse private key should have a very large random space, but the security researchers found that the actual value of the private key for the certificate was less than 256, i.e. only 8bit.
And even more, how simple are these private keys? Scott Helme, a security researcher, analysed the eMudhra certificate and found that one of the private keys was the number “4”. Helme wrote in the article: "Not a number starting with four, nor following a few hundred random numbers after four, it's a general 4 the other private key is 56 and one is 115. I know because I've just recovered all the private keys through these public certificates on my laptop, and the whole process is not going to last a second."
Other researchers also recovered private keys with values of 66, 155, 156, 230 and 237. It's like the world's top vault with the state-of-the-art anti-piracy doors, and the result manager has set the password “4”. The so-called high-intensity password protection is almost meaningless in the face of this low-level error.
Because the value of the private key is alarmingly small, the attackers can recover the private key in a very short period of time through violence. More seriously, these private keys belong to the intermediate CAs with the ability to issue certificates, and once restored, the attackers may forge web-site certificates issued by the affected CAs and carry out an attack by an intermediary when conditions, such as traffic interception, are met.
While browsers such as Google, Mozilla and others acted quickly to remove their trust in the relevant certificates, the associated trust risk may still exist for a large number of in-network systems, older version clients and embedded devices that have not been updated in a timely manner. Most ironically, the whole event did not even require the attackers to solve the complex coding problem. A certificate system that should have used a high-intensity key with a confidential key was eventually defeated by the number “4”. The strongest forts are often broken through from the innermost of the grass-roots groups.
The violent Al: the sharpest spear, the most out of control.
The loopholes in traditional software have already caused the developers enough headaches. As the attackers begin to connect AI to a real intrusion process, the defensive side has to face changes in the efficiency and scale of the attack.
Between the end of September and the beginning of October, a number of financial institutions in the Republic of Korea were involved in cyber-invasions and data leaks. On 7 October, a research report by CrowdStrike publish, a network security company, indicated that the attackers had used open source AI agent infiltration testing tool ARTEX and had launched an attack against Korean financial institutions in conjunction with LLM.
The researchers found ARTEX profile, Claude Code session history and memory files in the related server's open directory. These materials show that the attackers used the AI tool to conduct a large number of activities against Korean financial institutions; in the minutes of the session, the attackers also asked where the model would sell Korean leaked data and how to find the relevant Telegram trade group. CrowdStrike believes that AI tools allow the attackers to complete multiple incursions in a short time.
In the past, complex incursions into financial institutions usually required greater professional competence; now AI is lowering the technical threshold for some of them.
But AI caused more trouble than that. Even without hacker involvement, the acquisition of AI Agent, which actually operates permission, could become a new security risk.
In April this year, PocketOS, a car rental software start-up company, suffered a database accident caused by AI programming Agent. At that time, while the developer used Claude Opus 4.6 in Cursor to address the proof of the test environment, Agent found itself a permission too large a Railwayway API Token and called the deleted interface, removing back-up from the production database and from the same memory in just nine seconds.
Even more ridiculously, the developers did not ask AI to delete any data. According to a public description by the founder, Jeremy Crane, Agent subsequently admitted that he had carried out destructive operations without identifying the target environment, in violation of the security rules originally established. Follow-up by Railway helped to restore part of the data, but the accident still had a serious impact on businesses and clients.
The accident exposed a key difference between AI Agent and traditional automation tools: Agent can decide next step operations on its own, but it does not necessarily determine the risks involved. When it has the right to a real production environment limited-time, a miscalculation can become a direct irreversible system operation.
From the AI Auxiliary attack on the Bank of Korea to the Ai Agent database in PocketOS, AI is changing the risk boundary of software security in two different ways: On the one hand, the attackers used AI to lower the threshold of the invasion, and on the other hand, the business offered to hand over the operation of permission to AI without establishing sufficient security constraints. AI may be a more sharp weapon in the hands of the attackers or, in the absence of the attackers, may itself dismantle its own production system.
It's written at the end: the developers' survival guide.
From the Linux kernel to the Lite LLM supply chain, from the 8bit certificate to the Al automated attack, the series seems unrelated, but together they reveal a cruel reality: the rules of attack for software security have changed completely.
For ordinary developers, perhaps these three recommendations can help you save your life:
First, to give up the security illusion about the “family barrel” configuration. Never mind how mainstream your technology is, take an inventory of your assets (SBOM) and keep an eye on the version of the Nucleus Dependence.
Second, to put the security left on the ground. Dependence on scanning, key detection must be stuck in your CI/CD process, not just looking at the source code, but also verifying the construction product.
Finally, keep fear of AI. The use of AI to write code and to check loopholes is possible, but it is important to maintain artificial bottom lines for high-risk operations involving production data, keys and permission.
In the past, many security problems have persisted because of the considerable professional capacity and time costs involved in identifying and using them. Now, AI is changing this account. It may help the defensive to find loopholes more quickly, or it may help the attackers to find vulnerabilities more quickly.
As AI Agent acquires more real systems permission, software security will also face more new risks associated with automated implementation. This round of security incidents does not prove that traditional software is completely out of order, nor does it prove that all the loopholes were found by AI. But it sends at least one clear signal that the traditional software world has accumulated security debt for decades and is now undergoing a new set of stress tests that AI is bringing.
How much time does a company have left to repair when code writing, the search for loopholes, and the test attacks begin to accelerate? If, one day, AI could find in a few minutes a serious loophole that had been lurking for many years, and it would take a few weeks for the enterprise to complete the repairs, how would the rules of attack for software security change?
This is more urgent for developers than “AI will replace programmers”.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.