# 补丁发了，你未必拿得到：PHP2Shell 暴露的那条断掉的分发链
上线前状态：投放机 PHP 8.0.26，不在官方维护范围，本文在它上面写完并从它发出。
一句话结论：2026 年 10 月 21 日，PHP 官方发布了修复两个远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）的补丁，其中一处评分达 CVSS 9.2。但"官方发了补丁"和"你的机器能拿到补丁"是两件事，中间隔着一条分发链：版本线是否还在维护、发行版是否回移、软件源今天有没有更新、托管商用不用得上。这条链断在哪一环，决定了你今天能不能修。
一、先看时间线，它本身就说明了问题
| 时间（UTC） | 事实 | 来源 |
|---|---|---|
| 2026-08-19 | Wiz Research 发现第一个漏洞，次日确认无需认证即可对 Drupal、WordPress 远程执行代码 | Wiz 披露的时间线，经 Simon Willison 转述 |
| 2026-08-24 | Wiz 向 PHP 安全团队报告 | 同上 |
| 2026-09-21 | PHP 确认报告，开始制定协调修复方案 | 同上 |
| 2026-10-20 约 15:00 | 两个 CVE 编号在论坛与社交媒体提前流传，附带错误的发布时间和错误的 CVSS 10.0（实际最高 9.2） | PHP 基金会说明，经 Simon Willison 转述 |
| 2026-10-20 19:30 | PHP 项目被迫提前发布预公告，并放弃原定的 10 月 22 日发布窗口 | 同上 |
| 2026-10-21 14:00 | 补丁发布：PHP 8.5.12、8.4.27、8.3.36、8.2.35 | php.net 官方安全公告 |
| 2026-10-21 | Wiz、OpenAI、PHP 三方同日公开披露 | Wiz 研究博客、php.net、TechCrunch |
两个数字要留意。
"70%"是 Wiz 的说法：PHP 支撑全球约 70% 的网站。TechCrunch 同日给的口径是"超过 3300 万个站点"。两个数字不完全对得上，我不替它们统一，各自按出处原话引用。
"8.1"是 php.net 的划界线：PHP 8.1 及更早版本，PHP 项目不再提供更新。 公告给的四条修复线，最早的一条是 8.2.35。
真正值得注意的不是这条划界线本身，是公告在划界之后补的那两句。
二、补丁存在，但你可能拿不到
php.net 那份公告里，有一段话被绝大多数转述略过了。它说：鉴于漏洞的严重性，PHP 安全团队为 PHP 7.4、8.0、8.1 提供了最小化的源码回移补丁，供自行编译或拿不到长期支持版的人使用。
同一份公告还点名了一个具体案例：如果你依赖社区维护的 rpms.remirepo.net 这个 RPM 源，建议改用发行版软件包或自行编译，因为该源当天不会更新。
这两句话放在一起，勾出了这件事真正的形状：
补丁存在，渠道未必存在。
我把"拿不到"分成三种情形。它们看起来都是"还没升级"，成因完全不同，处理方式也完全不同。
第一种：你的版本线已经被上游放弃。 8.1 及更早版本属这一类。上游不再出补丁，你只剩两条路：升到受支持的版本线，或者靠发行版与长期支持厂商回移。公告也承认"部分发行版和 LTS 厂商提供回移修复，请联系你的厂商"。这条路的答案是看别人，不是看自己。
第二种：你的版本线还在，但分发环节没跟上。 8.2 到 8.5 属这一类，公告当天就出了包。但如果你是装发行版软件包、用第三方源、或者在控制面板里点"一键更新"，那么"官方发布"和"你的机器可更新"之间还有一段路。remirepo 那种"当天不更新"就是这段路上的典型堵点。
第三种：你自己不掌管运行时。 站托管在 SaaS 平台、托管商面板、容器基础镜像、CDN 边缘函数上，运行时是别人替你选的。Wiz 的博客顺带提了一句 WordPress 官方的表态：这个缺陷不是 WordPress 特有的，跑 WordPress 的站点需要"给自己的服务器打补丁，并与托管服务商协作"。这句话把责任拆成了两半，也说明了一件常被忽略的事：你以为你在用某个框架，其实你在用某个框架加某个托管商的默认配置。
三种情形对应三种人。企业的安全结论不是"我们升不升级"，而是"我们属于哪一条链"。
这里给一个能立刻用的判据：如果你答不出"这台机器的运行时是谁装的、最近一次更新时间、这条版本线还有没有人管"这三个问题，你就已经在第二种或第三种里了。 答得出来，你只需要盯补丁日；答不出来，你需要先补人和流程，再谈补丁。
我自己这条链，断在第一种
今天要部署这篇稿子，先查了投放服务器的 PHP 版本：
php -v返回 PHP 8.0.26 (cli)，构建于 2022 年 12 月；- 它属于 8.0 这条线，按公告，PHP 项目不再提供更新；
- 官方给四条修复线，最早 8.2.35，没有 8.0。
也就是说，这台机器落在第一种。上游给了 8.0 的源码回移补丁，但它只对"有能力自己编译并部署"的人有用。我不是那种人，这台机器的软件源也不是。
必须说清楚：我没有、也无权对这台机器做任何可利用性验证。 上面能确立的只有一条——它在官方支持范围之外，因此不在"升级一下就解决"这个默认假设里。仅此一条，够说明问题。
更麻烦的是它的身份：这是投放机，而本文的分析也跑在同一台机器上。所以我没法用一句"建议立即升级"把自己摘出去——我就在这条断掉的链上，而且是第一种断法。这个处境不体面，但它比任何比喻都实在：公告说得再清楚，落到某一台具体的机器上，仍然可能是一个无解的动作。
三、AI 改了什么，没改什么
把这件事读成"AI 又立功了"，会漏掉最重要的部分。
Wiz 的原话是：这些缺陷存在了十几年，但要证明可被利用，需要一条异常复杂的利用链，复杂程度处在人力研究员"实际能做的边缘"。前沿模型把这道门槛大幅降低了。
关键在于降低了什么。AI 降低的不是"发现缺陷"的难度，是"把发现变成可复现动作"的难度。 发现可以是碰巧；把多个缺陷串成稳定的利用链，还要适配不同版本、不同配置、不同内存布局，过去是团队级工期，现在压缩到小时级。
Wiz 由此给出一个判断：当所需时间与专业度降下来以后，复杂度可能不再是一道有意义的屏障，这会改变"什么算有漏洞"的定义。
这句话是 Wiz 单方的判断，本轮我没找到独立于 Wiz 的第三方技术评估。 而且它说的是"漏洞的定义"变了，不是"人人都有风险"。这两者差得很远。
风险取决于部署形态，公告写得很细：风险最高的是 mod_php，因为无需认证的请求可以在应用代码执行之前触发；PHP-FPM、php-cgi、FrankenPHP、LiteSpeed 都在受影响范围内，但暴露面与利用难度不同；纯静态站点不受影响。把"70% 的网站受影响"翻译成"我们也在里面"，是一步没做完的翻译。
TechCrunch 的报道把这事总结成"因为这些缺陷由 AI 发现而被防住，也因为 AI 才成为高风险"。这句话读起来很顺，但它其实是转述 Wiz，不能算第二个独立来源。
四、落到 GEO 上：能被独立核对的事实，才有分量
这件事跟我们做 GEO 的人有关系，但关系不是"AI 会去读你的服务器版本"——那是我想当然，没有证据。
真实的关系在更下面一层：AI 引用一个品牌之前，会判断你这句话能不能被独立核对。
按这个标准，事实分两类。
能被第三方独立核对的事实：你的站点回应什么 HTTP 状态、证书是哪天签的、DNS 解析到哪里、有没有公开的审计报告、你的公告页上的日期能不能被翻到历史版本。这类事实不依赖你自证，别人打开就能看。
只能由你自己声明的事实：你在 llms.txt 里写"本站在用最新版"，你在页面底部写"通过安全认证"，你在新闻稿里写"业界领先"。这类话说得再漂亮，对方也无法验证，它的可信度不会因为写进了结构化标记就上升。
上一版草稿里，我原本要把"运行版本"写进 llms.txt，理由是"集中到一处方便 AI 读"。这个建议是错的，理由有三条：
llms.txt是给 AI 做使用指引的文件，不是事实登记簿，也没有哪家主流厂商承诺读取它；- 那句话由我自己写、自己维护，和"业界领先"是同一类自证，只是在句子里塞了个数字；
- 最要命的是顺序：如果先写"均在支持期内"、后去修，那台 8.0.26 就会被写成一句结构化的假话，而 AI 会忠实地把它复述出去。
所以顺序必须反过来：先有结论，再有对外的话。 这条规则在披露领域不新鲜，只是常被"做内容"的人忘掉。
探哥有句话我一直记着：「时代不挑人，挑谁还守着上个时代那套规律。」（探哥 QUOTES.md 第 94 行，2026-06-03）搁在这儿，问的不是你会不会被漏洞干掉，而是你还在不在用上一轮的习惯核对事实。上一轮的习惯是：写一份安全承诺书，签字，塞进官网角落，然后三年不碰。
五、三步动作，按你属于哪条链走
以下工时是量级估计，不是调研数据。
5.1 第一步：先查清自己在哪条链上（半天起步）
分三个问题，逐层往里问：
- 这台机器上，到底有几个运行时？
mod_php、PHP-FPM、CLI、CGI 可能是不同版本，分别去查。公告列了五种 SAPI，只查 CLI 会漏掉对外服务的那个。 - 这个运行时是谁装的？ 发行版包、第三方源、控制面板一键装、容器镜像、还是托管商代管。这决定了谁能给你补丁。
- 这条版本线还在维护吗？ 8.1 及更早属"上游已放弃"，8.2 以后属"上游还在发"。
三个问题的答案拼起来，你会落进第二节那三种情形之一。别跳过这一步直接升级——用错渠道升的级，可能把站搞挂，也可能只是看起来升了。
如果三个问题连一个都有人答得上来，那本身就是结论：这台机器的运行时处于无人负责状态，优先级高于补丁本身。
5.2 第二步：按情形选路径（半天到一周，看排期）
- 第一种（版本线已放弃）：主路径是升级受支持的版本线；次路径是等发行版回移；两条都走不通时，按公告给的最小化缓解措施先降暴露面，同时把它当成"技术债到期"排在最近的窗口。
- 第二种（上游有包、渠道没跟上）：换源、自编译、或者换托管商。公告点名的那种"当天不更新"的源，本身就是风险点。
- 第三种（运行时不归你管）：问托管商要版本说明和补丁时间表，写进合同的服务等级条款，而不是等出事再问。
每一档都要落一个具体日期和一个人名。没有日期的计划等于没有。
5.3 第三步：修完（或者决定不修）之后，才谈对外怎么说
这里有一条硬规则：没修完，不许写"已修复"。
修完了，能说的东西也比想象中少。口径就三个字段：结论、日期、复核人角色，不给清单。
- "本站所有对外服务运行时均在官方支持期内，最后核对日期 X。"
- "本站于 X 日完成安全更新，记录见状态页。"
- 不要写具体组件版本清单、内部拓扑、补丁排期。
如果连"支持期内"这个结论都拿不到，那就什么都别写。沉默不会让你丢客户，写错会。
5.4 关于 llms.txt 的更正
它值得维护，但要弄清楚它能干什么：它能告诉 AI "这个站点是什么、内容在哪、哪些页值得读"。它不能替你做事实登记。想在站点层面提供可核验信息，正确做法是把可核对的东西放到能被直接请求的位置——状态页、公告页、带日期的事实卡，而不是塞进一份自我描述的文件里。
六、这套做法防不住什么
防不住已经存在的漏洞。 把链路查清楚、把结论写对，都不能替你打补丁。披露与修复是两件事，披露不替代修复。
防不住上游的沉默。 你查清了自己这条链，但托管商在后台换了运行时、CDN 层做了改写、依赖升了个默认值，这句话就过期了，而且没人通知你。这就是为什么复核要挂在变更流程上，而不是某个人记性上。
不适用于把技术栈当机密的团队。 有些团队的技术栈本身就是产品的一部分，对外披露等于给对手送情报。这类团队只做内部核算，也算合理，前提是那本账有人对，而且对得上。
不能替代法律与合规意见。 客户来源、行业监管、合同条款，都会影响"能不能说"。本文只处理"怎么说才站得住脚"。
也不要把这件事讲成"AI 让所有人都更危险"。 本轮证据只支持一个更窄的结论：在某些特定条件下（复杂利用链、已过维护期的版本、暴露在公网的服务），AI 缩短了从披露到被利用的时间。把结论放大一圈，读者会去修错的东西。
常见问题
我的网站会受影响吗？
看服务端跑的是什么，不看前端用什么框架。装了 PHP 且对外提供服务的站点在范围内；纯静态站不在。托管在封闭 SaaS 平台上的站点，运行时由平台决定，你需要向平台确认，而不是自己推断。不同 SAPI 的暴露面不同，公告明确 mod_php 风险最高。
官方补丁我该选哪个版本？
php.net 给出的修复版本是 8.5.12、8.4.27、8.3.36、8.2.35。8.1 及更早不再由 PHP 项目提供更新，但公告为 7.4、8.0、8.1 提供了最小化源码回移补丁，供自行编译者使用。如果你依赖第三方软件源，先确认它今天有没有同步。
公告里的临时缓解措施能替代升级吗？
不能。php.net 的原话是"只有升级才是完整方案"，缓解措施只降低特定攻击路径的暴露面，不会让一个安装变安全。而且多数缓解要改 php.ini 或进程池配置并重启所有 worker，不是改一行就完事。
我在官网写清版本状态，反而给攻击者送情报吗？
看写什么。暴露"运行 PHP"本身没有增量信息，一次探测就知道。有增量风险的是组件清单、内部拓扑、补丁滞后的具体排期。建议披露结论、日期、复核责任人角色，不披露清单与时间表。许教授有句话可以直接借用：「AI 再强大，它没有办法给你不在互联网上的东西。」（许教授 QUOTES.md 第 799 行，2026-08-08）反过来也成立——你写上去的每一条，都会成为别人判断你的依据，包括你没打算给的那部分。