作者称 PHP 漏洞难以利用，数千个公开 PoC 无法攻击标准实例

我知道，我知道。这是你听到的全部内容。还有那个数字 4。

别误会我，这里面显然有一个 bug，而且确实很重要。但这并不容易被利用。它肯定远没有 Log4Shell/Heartbleed/RoRYaml 之类那么容易。

给自己找点理由吧，你这个疯子！

我认为这个 PHP 漏洞并没有那么好利用。我觉得放在 5 年前大家都能理解这件事，但如今人们被他们的大语言模型误导了，模型告诉他们自己有漏洞利用代码，其实并没有。

你现在去看看 GitHub，上面有成千上万、毫不夸张地说成千上万的这个漏洞的"PoC"利用代码。不过你会注意到它们都有一个共同点，那就是它们对一个原生 PHP 实例并不奏效。

来吧，在 Docker 里搭一个你认为有漏洞的 PHP 服务器，然后自己运行这个 PoC。别让你的大语言模型去做。不行。自己去跑这个脚本。这些利用代码根本不起作用。

我觉得很多人曾以为大语言模型能够通过阅读 diff 立刻构建出一条利用链，即便这个漏洞比其他漏洞更难利用，大语言模型也能拉平差距。可是，根本没有能用的漏洞利用代码。现在怎么办？

当我想到互联网上那些"我们要完蛋了"的 CVE10 级漏洞时，我想到的是下面这些：

RoR YAML 解码（发送一个带有错误 yaml 的 POST 请求体）
Log4shell（把你的 User-Agent 设为 ${jdni:ldap:}）
Shellshock（"复制 env x='() { :;}; echo vulnerable' bash -c "echo this is a test"" 然后随意修改）
Heartbleed（请求 Content-Length 10000000）

这些漏洞一上新闻，僵尸网络就已经四处出击造成破坏了。那可还是在大语言模型出现之前！人们得亲手去写僵尸网络。

这个漏洞发布已经 10 个小时了，半个软件圈都在盯着它，天知道有 10 万人已经把他们那套"超级智能"派上了用场。然而，依然没有能用的漏洞利用代码。流传的那些要么是假的，要么只能在实验环境里跑，因为……

脚本小子（还有那些脑子也关掉的脚本大人）现在都这么想，好吧，他们自己不懂 UAF 链式调用，但这个 Claude 老兄什么都知道，完全能搞出利用代码。

搞笑的是，这导致大语言模型给了它的"小老弟"一个没插上的手柄。屏幕上到处都写着"exploit"，还配有一些所谓的铁证对话记录……但它其实把你正在测试的服务器改成了一个有严重漏洞的版本。开挂！

这些"PoC"有一个非常有趣的共同点：它们都依赖"LFI"，也就是本地文件包含，来制造这个漏洞。用非 PHP 的话说，它们的利用链要求服务器实际上做 eval(read(filename_provided_by_user))。

PHP 应用在某些方面出问题并不罕见，但要求服务器本身已存在漏洞，让人能够 cat /etc/password，这简直是一个疯狂的前提。如果你需要这样的条件，那这并不算一个严重的 bug。

最奇怪的是，竟然有这么多人不约而同地犯下这个匪夷所思的判断错误。那是因为他们其实并没有各自独立地做出这个决定。Claude/等等已经替他们完成了所有判断，所以才出现了这种逻辑错误分布的怪异现象。

这里有一点很重要：有多少人让 Claude/GPT 替自己做设计决策，以及 AI 如何成为当今世界的主要决策者。现在出现了一个奇怪的“决策谢林点”现象：某种解决问题的方法占比过高，因为 Claude 默认就会采用这种方法。

这对于“如今大多数网站看起来都大同小异”来说确实很烦人；但由于 LLM 能够同时毁掉所有领域，因此也出现了“如今大多数决策都出奇地雷同”的情况。尤其是这个案例，AI 正在服务器上插入漏洞，以证明该服务器容易受到你的“利用任意 PHP 实例”攻击！

因为：

以前也发生过类似的事情，但那时还不是 LLM 时代。幸运的是，对我们来说，这一天似乎还没有到来。它太难被轻易利用了。这不是 Log4J 时刻。