LLM 加速漏洞利用是否成为网络安全新常态

过去一周，针对数千个大型站点的严重和危急软件漏洞密集出现，令人们陷入恐慌。究竟发生了什么，我们又能采取什么措施？

这些漏洞

要了解当前软件安全领域的情况，我们就需要弄清这些漏洞究竟是怎么回事。我不是网络安全专家，所以不会深入讲述那些血腥的技术细节，而是会链接到外部解释文章；在这方面，那些专业人士总能做到比我更好。

PHP2Shell – CVE-2026-109618 和 CVE-2026-109619（又称“新闻中那个大漏洞”）

两个不同的安全团队——一个来自加州安全公司 Calif（属于 OpenAI 的“Patch the Planet”计划），另一个来自美以云计算安全公司 Wiz（据说已并入 Google Cloud）——都发现了 PHP 中的这两个远程代码执行（RCE）漏洞。两个团队都使用前沿 AI 模型（又称 LLM，具体来说是 GPT-5.6 Sol/Gemini 4 Argon）来寻找这些漏洞并构建利用程序。

有趣的是，其中一个漏洞（CVE-2026-109618）其实是由 PHP Foundation 在 2024 年进行的安全审计发现的。该审计由 Sovereign Tech Agency 资助，而后者恰好是当下开源领域最值得关注的事情之一。但 PHP Foundation 基本无视了这个漏洞，因为他们还有更紧迫的问题，而且无法就修复方案达成一致。其理由是，没有人能真正弄清楚如何根据这个理论问题构建出实际可用的利用程序。

LLM 非常擅长的一件事，就是把一个理论上的安全漏洞——即使漏洞本身只是对该问题可能存在何种情况的一个含糊描述——变成一个完整的利用程序。近几个月来，这已成为一个重大问题，因为任何安全补丁的通知一发布，人们就会立即让 LLM 指向相应的代码库；随后，这些智能体可以很快浏览代码差异，找到看起来像是安全补丁的内容，再追溯它所涵盖的漏洞，并一路追到一个利用程序。

事实上，这一过程发生得如此之快，以至于现在我认为，将安全补丁的公布时间视为完整利用程序不会在公开或私下渠道传播的最后可能期限，是合理的选择。

这个 PHP2Shell（其营销名称如此；现在，漏洞似乎都自带营销部门了）据估计会影响互联网中超过 70% 的系统，受影响的网站和机构数以千计，从 Wikimedia Foundation 到 DeviantArt，再到英国政府的大部分系统和日本银行系统，以及 BBC 节目《The Traitors》的官方网站。漏洞确实会被发现，但通常不会导致半个互联网都关闭服务器，那么究竟发生了什么？

要理解这一点，让我们看看 PHP Group 的原始文章：

Screenshot of the PHP announcement "Upcoming Critical PHP Security Release", dated 20 Oct 2026. It says the release is scheduled for Wednesday 21 October 2026 at 14:00 UTC, that it fixes two critical vulnerabilities rated CVSS v4.0 9.2, and that full details will be published with the release.

一位名为 petecooper 的人在 Hacker News 上发布了关于这些 CVE 的帖子，显然甚至不知道当时还处于禁发期。这件事（以及其他疑似泄露）促使 PHP Group 仓促发布这项声明，并将补丁发布时间从 Thursday 22nd 提前至 Wednesday 21st。不过，补丁仍要等到第二天才会提供。这次无意泄露的内容包括 10.0 的 CVSS 评分（即严重，不过奇怪的是，实际评分却是 9.2）。

几乎立刻，这条消息便像野火一样传开，人们也开始恐慌。尽管这是由“负责任的安全研究人员”在“ reputable 公司”发现的，但安全补丁真正发布时，它已经在真实环境中遭到利用¹。PHP Foundation 将责任归咎于 Calif 和一家名为 Chainguard 的公司，称 Calif 泄露了一段漏洞利用程序实际运行的视频（配着奇怪的背景音乐，还有一个跳舞的动漫女孩），而 Chainguard 在禁发期原定结束前 6 小时发布了修复方案；这两件事都让攻击者得以抢在系统管理员之前行动。时间线令人困惑，但似乎有多个相互关联的问题在约 17 小时内接连出错。

关于 AI 是否真的是一场能够彻底革新计算机安全的划时代变革，已经有大量讨论。大型 AI 公司（而且它们确实很大）显然希望你认为答案是肯定的。有些人认为 PHP2Shell 的危害被夸大了，因为 LLM 往往对漏洞过度警觉，会编造出一些基于错误假设（比如认为服务器会通过某个已有的文件包含漏洞运行你亲自上传的 PHP 代码）或以某种方式作弊的“漏洞利用程序”。正如 LiveOverflow 指出的，LLM 让人们很容易制造出既不能证明任何问题、也无法奏效的漏洞利用垃圾，但这并不意味着该漏洞不是真实存在，也不意味着它不能借助 AI 被轻易利用。你可能有 10,000 个无法奏效的垃圾级漏洞利用程序，但只要有一个能奏效，这就够了。也许现在我们只需要习惯趟过这些垃圾，找出真正重要的内容。

还有其他人指出，许多政府（英国²、欧盟、日本、美国）表现得过于激动，发布紧急公告，要求所有人立即拔掉电脑电源，于是人们陷入了恐慌。我认为大家之所以恐慌，是因为多少都知道 PHP 极不安全，却仍在使用它，因此早已预设会有坏消息，也容易反应过度。而且实际情况确实相当糟糕，所以恐慌或许也算是一种正确反应？

我认为从中得到的最大启示是——由于 LLM 的存在——从“嘿，我听说这个项目里存在严重的 RCE”到“已经出现了利用针对该漏洞的漏洞利用程序发动的复杂、自动化且协同的攻击”，所需时间已从数周/数月缩短至数小时/数分钟。存在大量无法奏效的漏洞利用垃圾，恰恰说明要真正开发出这些东西仍然需要专业能力——如果你不知道自己在看什么，就无法判断 AI 是作弊了还是作出了错误假设。

链接：

Hacker News：“请向 HN 介绍：2x PHP RCE CVE，CVSS 10.0 即将来袭”（petecooper, 20 Oct 2026）
PHP2Shell – 官方网站 – 为什么现在每个漏洞都需要名字、口号和网站？
Wiz Research：“PHP2Shell：AI 发现影响 70% 互联网的关键 RCE 漏洞” – 这是发现这些漏洞的公司之一。
PHP News Archive：“即将发布的关键 PHP 安全版本”（20 Oct 2026） – The PHP Group 是如何宣布该漏洞的。注意时间线。
Wikipedia：PHP2Shell – 内容不算太详细，但至少他们没想向你推销任何东西。
AWS Security Blog：“Amazon Threat Intelligence 在 MadPot 公开披露前发现 PHP2Shell 遭利用” – 他们确实想向你推销点什么，但仍做了一些有趣的分析。

eMudhra（CVE-2026-111943，关于 Golang 响应的）

就在同一天（20th October 2026），Mozilla 宣布屏蔽由印度证书颁发机构 eMudhra 签发的 8 张中间证书。此前，一位仅以“Wayne”为人所知的使用假名的安全研究员向 Mozilla、Apple、Google、Microsoft 等多家大型科技公司报告称，该证书颁发机构为其中间证书使用了质量差得可笑的私钥。安全密钥可能是 100 位数，而 eMudhra 使用的密钥却只有“115”、“56”和“4”之类。他们一定是遵循了 RFC 1149.5：

xkcd comic "Random Number": a code listing with the function int getRandomNumber() that simply returns 4, with the comment "chosen by fair dice roll. guaranteed to be random." — *替代文本：*RFC 1149.5 将 4 指定为经 IEEE 审核认可的标准随机数。出自 xkcd #221，采用 CC BY-NC 2.5 许可。

没有迹象表明此次事件是利用 AI 或 LLM 发现或利用的，不过研究员 Scott Helme 指出，只需一个提示，Claude 就能够恢复这些中间证书的私钥。

截至撰稿时（23rd Oct），eMudhra 已宣布将退出证书颁发机构领域。与此无关的消息是，在有关一匹马逃脱的报道后，一名农夫宣布自己已经关好了马厩的门。

链接：

Railway 漏洞

第二天，云服务商 Railway 宣布，他们发现证据表明黑客曾访问其平台上的环境变量，甚至对其进行了解密；这些环境变量通常包含数据库凭据、API 密钥等秘密。在声明中，他们表示，这被认为是旨在入侵提供 AI 推理服务的公司的一项协同行动的一部分。

这样做的最终目标会是什么？截至撰稿时（23rd Oct），我们掌握的信息非常有限。这个“未经授权的第三方”（官方关于“某些随机的人侵入了我们的电脑”的公告总会设法把它说得像一份服务条款协议，也许他们以为这样人们就不会注意了）是否在监视使用 AI 推理的人，以查看他们在做什么，甚至窃取新模型或研究成果？又或者，他们试图为由遭入侵的推理服务商组成的网络，用于其自身不可告人的生成式 AI 目的（比如寻找更多 PHP 漏洞）。

链接：

GitLab（CVE-2026-97229 和 CVE-2026-110264）

2026 年 10 月 12 日，GitLab 发出警告，称 GitLab CI/CD 的正则表达式解析中存在一个严重程度最高的漏洞，攻击者可能利用精心构造的正则表达式执行任意代码（又一个 RCE）。该漏洞的 CVSS 评分为 10.0，已是可能达到的最高值，意思是“这几乎就是最糟糕的情况了”³。2026 年 10 月 21 日，随后又出现了又一个正则表达式整数溢出 RCE，评分同样为 10.0。

紧随其后的，是上个月另一个 CVSS 评分为 10.0 的 CVE（CVE-2026-85706），那次与路径遍历有关。这三个漏洞都是通过 GitLab 的 HackerOne 漏洞赏金计划报告的。随着人们意识到 LLM 可以研究漏洞并编写利用程序，曾有很多讨论主张关闭漏洞赏金项目，因为它们已经不再有意义。我敢肯定，GitLab 现在很庆幸没有这么做。

尽管 GitLab 在学术界、政府和私营公司中使用得非常广泛，但这似乎没有受到太多关注。GitLab 中的 CVE 显然非常严重，对私营公司尤其如此，因为它们大量至关重要的知识产权都存储在那里，一旦泄露，后果可能不堪设想。公司通常会把自己的 GitLab 实例置于 VPN/防火墙之后，使其无法从公网访问，这会大幅降低相关风险。此外，目前也不完全清楚这些 CVE 是否需要某些特定条件，例如项目可公开访问、允许用户自行注册等。CVE-2026-110264 似乎至少需要一个公开项目，但我找不到有关更早那个 CVE 触发条件的任何信息。

没有迹象表明这些漏洞是利用 AI 或 LLM 发现的。它们可能是，但目前没有理由认为是这样。

链接：

musl libc 漏洞

10 月 21 日，有人公布了一个与正则表达式有关的 musl libc 漏洞（libc 有正则表达式？看来还真有……），该漏洞至少会导致拒绝服务，甚至可能导致代码执行。据我所知，这完全只是时间上的巧合，与 GitLab 漏洞无关；GitLab 的两个漏洞似乎也都是解析不受信任的正则表达式时发生的整数溢出，其中一个还是在同一天报告的。谁能想到正则表达式引擎会成为如此严重的安全问题——正则表达式是不是成了新的字体渲染？GitLab 的两个漏洞均由一位名叫 Johan Carlsson (joaxcar) 的瑞典人发现，而 musl 漏洞则由Julien Voisin 报告，他是一名自称“开源术士”的法国人。

链接：

LiteLLM

啊，我的老朋友 LiteLLM，你好。事实证明，当你浑身由金属打造、足有 200 英尺高时，闪电确实可以劈中你两次。有人问你是否听说过 2026 年 LiteLLM 那次重大被攻陷事件时，你却不得不反问“哪一次？”，这可不是什么好兆头。幸运的是，PHP2Shell 以及其他所有事件抢走了大量注意力，这意味着尽管这次事件的严重程度与 3 月那次不相上下，却没有获得那么高的关注度。

这次出问题的是 Python Package Index (PyPI) 上的一个恶意版本以及 Docker 镜像。那些不记得的人，LiteLLM 在 3 月也发生过非常相似的事情：有人将恶意包上传到 PyPI 上的 litellm 软件包，并利用.pth 文件自动加载恶意代码（是的，情况很糟糕）。

这次入侵再次利用了 .pth 文件，这次还利用了 sitecutomize.py 文件来自动加载恶意载荷；Python 解释器一启动，载荷就会在预加载步骤中运行。根据Wiz 的分析，该载荷“有强烈迹象表明是在借助 LLM 开发的”——比如过于冗长的变量名、过度防御性的错误处理、脆弱的边缘情况，以及所有写着“真正吃亏的地方就在这里”“这一点值得停下来细想”“顺着这一点深挖”“那就归你了”的注释反复出现⁴。

据 LiteLLM 称，该事件之所以发生，是因为攻击者获得了 GitHub CLI 凭据，借此可以运行 CI 作业。LiteLLM 指出，Claude Code 似乎有时会将用户的 GitHub CLI OAuth 令牌嵌入响应正文，可能导致这些令牌出现在 LiteLLM 日志中。

链接：

PingCAP

2026 年 10 月 19 日，一家名为“PingCAP”、开发名为“TiDB”的数据库的企业软件公司披露了“未经授权访问 PingCAP”一事，并称“没有证据表明存储在 TiDB 中的数据受到影响”。与此同时，一个名为“FulcrumSec”（又称“Threatspians”⁵）的网络勒索团伙表示，他们已从 PingCAP 外传了 10.6 TB 数据，并公开发布了一个包含 200 GB 数据的种子文件，作为“第一阶段发布”（总得先让人们对续集产生兴趣）。

他们还公布了自己所窃取内容的完整细节，以及 PingCAP 一些堪称优秀的安全实践，包括把客户的 AWS 私密访问密钥放进 Jira 工单，以及把包含 OpenAI、Anthropic、Gemini、xAI API 密钥的庞大且未经脱敏的日志附到 Jira 工单上。真糟糕。如果你愿意访问这个网络勒索团伙的网站，他们会就此写一份相当有意思的说明。那种粗糙且不通顺的英语日子已经一去不复返了——想当年，俄罗斯人不得不亲手撰写这些东西，既没有 LLM 帮他们代写，也没有 LLM 提醒他们注意定冠词和不定冠词的使用。⁶

对 PingCAP 来说，好消息是，没找到数据被提取的证据实际上极其容易。事实上，我现在正免费为数千家公司这么做。我敢肯定，这里面总有个商业提案。你只要不去看就行了（另见：U+1F648）。公平地说，我认为他们的论点是，TiDB 实例内部没有任何数据遭到破坏。如果真是这样，10.6 TB 似乎仍是大量数据。显然，仍有大量客户数据。

链接：

Hacker News 讨论：“PingCap TiDB 泄漏事件”
PingCAP：“2026 年 10 月安全事件报告：对 PingCAP 云资源的未授权访问”——PingCAP 对该事件详尽且高度可靠的分析。
FulcrumSec：“PingCAP TiDB 云数据泄漏”——提前提醒一下，这是个已知网络勒索团伙的网站。别说我没警告过你。不过内容还是相当有意思。

Linux 漏洞被意外发布到错误的群聊中

Linux 内核开发的一切都是通过邮件列表进行的。其中自然有些涉及安全敏感事项，因此这些邮件列表是私密的。在 2026 年 10 月 21 日至 22 日夜间，Trend Micro 旗下的软件漏洞计划 Zero Day Initiative（ZDI）把一批高危（CVSS 最高达 9.0）的 CVE 报告发到了公开邮件列表，而不是私有邮件列表。人们自然假定，任何拥有 LLM 和一颗充满梦想的心的人，接下来都能在短短几分钟内把这些报告变成可用于实际攻击的漏洞利用程序。这倒没有那次那么糟糕：Pete Hegseth 误把即将对也门发动的军事打击细节发短信给 The Atlantic⁷；但现在人们对这类事情如此重视，仍然颇有意思。

链接：

Phoronix：“多个 Linux 内核漏洞被意外发布到公开的内核邮件列表”

这就是新常态吗？

我认为可以公正地说，就所有这些网络安全事件和安全披露而言，过去几天的活动异常频繁。在 Hacker News 上这些事件的讨论中，许多评论者说这不算什么，而且只会越来越糟。老实说，我也还没想好。说真的，如果 4 年前你问我 LLM 会发展到什么程度，我绝不会猜到它们现在会这么出色。即便如此，人们确实容易因这些公告而过度兴奋，并认为我们将生活在一个没有任何软件是安全的、人人都容易受到攻击的世界里。

值得注意的是，尽管围绕这些事件的许多网上讨论都聚焦于 AI 和 LLM，但只有部分披露是借助 LLM 研究或创建的。对于其中一些事件，比如 PingCAP 那次，我们并不知情。但有明确证据表明，许多犯罪团伙和国家支持的组织正在利用 AI 实施更多黑客攻击，而且速度更快。它们有什么理由不这么做？AI 在这方面似乎做得相当不错。这些漏洞中的许多都是老派软件漏洞，靠人类的肉手指发现并编写出来，但网上的讨论却聚焦于那个令人兴奋又可怕的新东西。它有什么理由不聚焦于此呢？

你可以理解，为什么 NHS England 这样的机构决定将所有开源代码转为私有（尽管这是个愚蠢的决定）。当这些 LLM 如此强大，任何人都可以让自己的智能体指向某段开源代码，找出大量漏洞，再为这些漏洞编写完整的漏洞利用程序时，这会令许多人感到担忧。那么，解决方案是什么？

我们能对此做些什么？

NHS 的做法：让一切都闭源。（又称马达加斯加做法）

优点：

你的代码不再公开上线，因此人们无法让 LLM 指向它，做诸如分析每一次提交以进行安全修复、找出大量此前未知的严重漏洞之类的事。

缺点：

每有一个开源代码库被下线，开源社区和计算技术的未来都会稍微糟糕一点。
你无法将世界上的每个代码库都闭源——有些东西（比如编程语言，它们往往是严重漏洞的源头）依赖开源才能运作。把 Python 变成闭源项目会给计算世界带来灾难。
它只是在有人泄露之前处于闭源状态。而他们最终很可能会泄露。到那时，你的代码库将缺少多年来使其从一开始就保持整洁、安全的公开审查。
有时你使用的编程语言让这件事其实无关紧要，比如 Python 和 Java，因为你可以从字节码中还原源代码。
LLM 甚至可以相当有效地对编译后的二进制文件进行逆向工程。
如果代码曾经公开上线，旧版本仍然公开。你必须假定某处会有人保留着它。Shellshock 从 1989 年起一直存在于 GNU Bash 中，直到 2014 年才被修复，而它也是全球使用最广泛的程序之一。
这让我很难过 :(

拥抱 AI 的做法：如果打不赢他们，就加入他们。换句话说，如果我们已经在自己的代码上运行了更好的 LLM，而且速度更快、资金更多、模型更好，他们就无法再使用 LLM 来寻找漏洞。

优点：

会让少数非常富有的科技 CEO 非常开心。
会发现大量漏洞。

缺点：

会让少数非常富有的科技 CEO 非常开心。
会发现大量漏洞。（总得有人来修复这些漏洞。）
需要花费大量资金。
尽管 AI 让这件事变得更容易，但要正确完成这些工作，仍然需要专业知识和深厚的技术能力（目前而言）。

乐观主义者的做法：采用普遍更优、标准化的方法来报告、处理和缓解安全漏洞，随后让所有公司都具备一流的安全态势、对风险有充分理解、拥有记录完善的流程等等。

优点：

好主意。
为什么其他人没想到这一点？
哎，我们真是聪明。我们是不是刚刚解决了这个问题？

缺点：

我们并不是生活在这样的世界里。我们永远也不会生活在这样的世界里。
我提过这其实相当困难吗？甚至可能根本做不到？
成本高昂。

对此，我们现在就能采取一些简单易行且见效的措施，例如“在补丁准备好安装之前，绝不公布严重漏洞的详细信息”，但这次由于意外泄露，所有人在官方公告发布前就知道了这些漏洞。也许连这一点要求都太高了。这次是多人、多家公司接连犯错，导致或加速了漏洞利用在补丁可用前数小时便已投入实际使用，因此所有人都将服务器下线。此后，AWS 表示，他们从 17th October 起就看到有人尝试利用这一漏洞，而这早于上述任何一次泄露。

即便像“最短发布等待期”这样的机制——它是在 shalk/debug、Shai-Hulud、& March LiteLLM 事件之后才开始流行——也会带来这样的后果，因为用于修复遭到广泛利用的漏洞的大型更新要过几天才能完成修补，从而给攻击者充足的时间把你攻得支离破碎。至少在客户端管理方面，我们或许可以做得更好，避免所有人惊慌失措并让所有服务器下线。

也许我们只需要接受：一旦把某样东西暴露在更广泛的互联网上，它就会遭到入侵，而我们应当据此制定预案。也许问题出在我们的预期上。

结论

这里无疑涉及一个关于 AI 与安全的故事。它正在改变软件世界，而目前尚不清楚这究竟是好是坏。正如物质会扭曲时空，金钱也会扭曲真相；而 AI 领域的资金之巨，足以让真相扭曲到成为某个中型黑洞的等价物。AI 领域正在投入难以想象的大量资金，而这一切都希望你相信，它将改变你生活的方方面面，包括软件和安全。当然，这不意味着上述说法不是真的。

有些人说，早在 ’10s 年代，自动化分析工具促成了大量新漏洞被发现，如今同样的事情再次发生。在我看来，这有着本质上的不同，但或许会先经历一段漏洞报告不断增加的时期，然后一切平息下来，恢复原状。我怀疑不会。有些人说，这一切之所以发生，只是因为那些不靠谱的代码一开始都是由人类编写的——如果从一开始所有代码都由 AI 编写，就不会再有漏洞，因为 LLM 编写安全代码的能力强于人类。这个论点并未说服我。

虽然我并不太愿对未来作出预测（因为我不想在 12 个月后最终被证明错误时看起来像个傻瓜），但我要说，软件行业将会改变，开源也将会改变。作为软件社区成员，我们肩负着共同责任，要确保这种变化惠及我们所有人，而不是让特殊利益方和私营公司获益。

更新

这是一个仍在发展的事件——我会在这里注明任何更新。我写这篇文章时有些匆忙，因此之后也可能对部分内容的措辞和论据作一些逐步完善。

脚注

关于在补丁发布前是否确有人真正尝试并成功利用该漏洞，存在一些讨论和分歧。↩
免责声明：我算是为英国政府工作。 ↩
GitLab 在这里使用 CVSS 3.1，而 PHP 使用 CVSS 4.0，这意味着两者计算 CVSS 分数时采用的指标略有不同，因此不能直接比较。↩
好吧，也许最后这一点不算。↩
如果这些令人不齿的罪犯有朝一日被绳之以法，我建议判他们最长的刑期，罪名就是危害文字游戏。真是恶劣至极。↩
需要澄清的是，没有证据表明这个团伙是俄罗斯黑客。他们似乎主要受经济利益驱动，因此可能来自世界各地。你懂我的意思——过去，人们还能从语法上的特殊之处认出俄罗斯的网络钓鱼活动。如今这种辨别方式已经完全没意思了，全都是因为 AI。↩
幸好，他确实是个正直而值得信赖的公民，做行政任命决定时以国家利益为重，而不是出于个人忠诚或对总统个人牟利议程的效忠；总统确保所有那些负有责任的人都被迅速撤职，离开他的政府，此后再也没有在华盛顿露面。↩