There isn't an easy exploit for this PHP vulnerability
TL;DR · AI 摘要
该PHP漏洞的利用难度远高于Log4Shell等著名漏洞，且目前没有实际可行的利用方法。
核心要点
- 当前PHP漏洞的利用难度远高于Log4Shell，需谨慎对待。
- GitHub上的多数PoC代码无法在标准PHP实例上运行。
- LLMs生成的利用代码可能误导用户，实际测试至关重要。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- PHP漏洞利用难度分析
- 与其他漏洞对比
- Log4Shell/Heartbleed利用难度更低
- LLMs影响
- 生成虚假PoC代码
- 实际测试
- 需手动验证代码有效性
金句 / Highlights
值得收藏与分享的关键句。
This is not easy to exploit. It is certainly nowhere near as easy as Log4Shell/Heartbleed/RoRYaml etc.
The exploits don't work.
LLMs are generating fake exploits that only work in labs.
这个PHP漏洞并没有简单的利用方式 · Elias Taylor
返回
这个PHP漏洞并没有简单的利用方式
#### 2026-10-21
我知道，我知道。你听到的全是这些内容，还有那个数字4。
别误会我，这里确实存在一个漏洞，而且确实很严重。但这个漏洞并不容易被利用。它与Log4Shell/Heartbleed/RoRYaml等漏洞相比，远没有那么容易利用。
编辑：我在这里强调这一点是为了让更多人看到。无论如何，你应该修补你的服务器。这里确实存在一个真实漏洞，但利用它比人们想象的要困难得多——它绝不像log4shell那样简单。
你这个疯子，为自己辩解一下！
我认为这个PHP漏洞并不容易被利用。我认为五年前人们会理解这一点，但现在人们被他们的LLM（大语言模型）误导了，这些模型告诉他们他们拥有一个漏洞利用方式，而实际上他们并没有。
如果你现在查看GitHub，你会发现成千上万，真的成千上万，针对这个漏洞的“PoC”（概念验证）利用方式。但你会发现所有这些利用方式都无法在标准PHP实例上运行。
去吧，用Docker搭建一个你认为易受攻击的PHP服务器，然后亲自运行PoC。不要让LLM来执行。不，你自己运行脚本。这些漏洞利用方式根本不起作用。
利用方式在哪里，Lebowski？
我认为很多人假设LLM能够通过阅读代码差异（diff）立即构建出漏洞利用链，即使这个漏洞比其他漏洞更难利用，LLM也会让攻防差距消失。但事实是，目前还没有可用的漏洞利用方式。现在怎么办？
当我想到互联网上那些被标记为“我们完蛋了”的CVE-10漏洞时，我会想到以下漏洞：
- RoR YAML 解码（发送包含恶意YAML的POST请求体）
- Log4shell（将用户代理设置为${jdni:ldap:}）
- Shellshock（复制环境变量x='() { :;}; echo vulnerable'并根据需要修改）
- Heartbleed（请求Content-Length为10000000）
这些漏洞刚被曝光时，就有僵尸网络四处传播并造成破坏。这还是在LLM出现之前！人们必须用双手编写这些僵尸网络。
这个漏洞被公开已经过去了10个小时，半个软件世界都在关注它，上帝知道已经有10万人声称他们的“超级智能”已经介入调查。然而，目前还没有可用的漏洞利用方式。流传的那些都是假的，或者只在实验室中有效，因为...
该死的LLM，伙计。
脚本小子（以及同样关闭了大脑的脚本成年人）现在都以为，虽然他们不懂UAF（使用后释放）链的利用方式，但像Claude这样的LLM无所不知，完全可以制造出漏洞利用方式。
可笑的是，这导致LLM给它的“弟弟”一个断开连接的控制器。屏幕上满是“漏洞利用”的字样...还有一些“决定性证据”的转录文本...但它修改了你测试的服务器，使其存在严重漏洞。作弊！！
- https://github.com/david-alvarez-rosa/php-rce
- https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC
- https://github.com/ikow/php2shell-poc
我随便选了这三个，因为它们是星标最多的，但这样的项目还有很多很多。
这些“PoC”中大多数有一个共同的有趣之处：它们都依赖于“LFI”（本地文件包含）来制造漏洞。用非PHP术语来说，它们的漏洞利用链要求服务器本身已经存在严重的代码级漏洞。
PHP 应用在某些方面存在缺陷并不罕见，但要求服务器必须存在用户可以执行 cat /etc/password 的漏洞，这显然是一个荒谬的前提条件。如果你真的需要这种前提条件，这并不能说明这是一个严重漏洞。
最奇怪的是，这么多人独立地做出了这种极其离奇的判断失误。原因在于他们并没有真正独立做出这个决定——Claude/Etc. 已经替他们完成了所有判断，因此才会出现逻辑错误分布如此怪异的现象。
这里有一个重要的问题值得探讨：如今有大量人让 Claude/GPT 为他们做设计决策，而 AI 已经成为当今世界的主要决策者。你正面临一种奇特的“决策谢林点”现象——解决某个问题的方法被极端地过度使用，仅仅因为这是 Claude 默认的处理方式。
在当前案例中尤其荒谬的是，AI 在服务器上植入了漏洞……只是为了证明服务器确实容易受到你“攻击任意 PHP 实例”的攻击！
为什么所有人都如此恐慌？
原因如下：
- 一位 PHP 核心团队成员表示这是一场灾难（“补丁发布后 15 分钟内就会出现利用漏洞的攻击”）
- 我们内心深处都清楚 PHP 本身存在安全隐患
- 利用演示视频中出现了动漫少女
- 我们都清楚大型语言模型（LLMs）正像 100 吨的契诃夫大锤一样悬在互联网上方，而且我们都清楚代码本身并不安全
我们以前也经历过类似事件，但那还处于大语言模型时代之前。幸运的是，这似乎并不是那个时代。这个漏洞难以被轻易利用，它并不是 Log4J 那种级别的重大漏洞。
联系方式
编辑：我已在此帖子中添加了我的联系方式并修复了一个损坏的链接。我在顶部添加了免责声明，提醒你仍然需要打补丁。
Signal：zk7.27
Email：[email protected]