10月21日，荷兰国家网络安全中心将其自己的网站离线。不是因为WordPress被黑客入侵，而是因为它下面的PHP解释器可能被黑客入侵。
那天PHP项目发布了解决解释器本身中两个未经身份验证的远程代码执行错误的修复，CVE-2026-109618和CVE-2026-109619。任何PHP处理公开请求的网站都必须打补丁或离线。从CDN提供静态HTML的网站在请求路径中没有PHP进程，所以在边缘没有什么需要打补丁的。Headless WordPress仍需要更新其后端，但公共网站保持运行。以下是时间表、架构论证、按堆栈的决策表、30/60/90天计划以及如果你现在坚持使用PHP的检查清单。
如果你运行PHP，今天就做这个。
- 确认运行版本是8.5.12、8.4.27、8.3.36或8.2.35，或你已阅读通知的供应商反向移植版本，并重新启动每个worker。
- 检查你的主机控制面板实际发布的内容，而不是仪表板显示的内容。
- 将PHP的ini缓解措施和任何WAF规则视为通往补丁的桥梁，而不是替代品。
- 在7.4到8.1上，询问你的主机是否构建了安全团队的源代码反向移植，并无论如何预订升级。
2026 年 10 月 21 日发生了什么
时间表很重要，因为它解释了恐慌的根源。根据 Tenable 的报告，CVE 标识符在 10 月 20 日出现在 Hacker News 和社交媒体上。当天晚些时候，PHP 安全团队发布了 10 月 21 日 14:00 UTC 发布版本的提前通知，表示如果详情公开，可能提前发布。Tenable 还报告，引用 watchTowr 的说法，原定披露日期是 10 月 22 日（在禁令下）。
PHP 安全团队于 10 月 21 日发布了其公告，标题为"安全公告：严重远程代码执行漏洞，立即更新"（php.net 新闻存档）。ENISA 联合声明将更新时间定为 13:40 UTC。修复版本为 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。
根据 GitHub 公告，这两个漏洞是：
- CVE-2026-109618：通过内存溢出损坏实现的远程代码执行。
- CVE-2026-109619：通过陈旧的全局状态实现的远程代码执行，这是同一个工作进程处理的请求之间的使用后释放。
PHP 安全团队将两个漏洞的 CVSS v4.0 评分为 9.2。Tenable 注意到一些早期报告，包括 watchTowr 和一篇 Hacker News 文章，称评分为 10.0。所有网络服务 SAPI 都在范围内：PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。OOM 公告特别指出 mod_php 暴露风险最大，因为故障完全发生在任何应用程序代码运行之前。Calif 表示，最早受影响的代码路径可追溯到 PHP 5.4.0。该漏洞由 Wiz、Calif 和 OpenAI 发现，采用了 AI 辅助研究。
然后是大规模停机。路透社和爱尔兰电视台报道了荷兰、芬兰、法国和澳大利亚政府服务下线的情况，包括荷兰国家网络安全中心自己的网站。CERT-EU 建议隔离面向互联网的应用程序直到修复，CISA 敦促立即打补丁。Krebs 报道 Cloudflare 在 UTC 时间 3:02 am 部署了 WAF 规则。Amazon 威胁情报表示它在 10 月 17 日看到了一次尝试，随后将利用描述为广泛。
关于利用情况，各方信息不一致，您应该了解这一点。PHP 基金会表示，在发布时尚未识别功能性漏洞利用。Krebs 报道专家表示存在有效的漏洞利用。Tenable 表示，声称利用这些漏洞的代码在流传，但尚未验证任何代码。
为什么建议是立即补丁或下线
请求路径中的未认证远程代码执行意味着网络服务器是目标。前面没有登录，也没有可以禁用的插件。请求到达，PHP 进行解析，漏洞已经开始起作用。OOM 公告确认影响为未认证代码执行，以网络工作进程账户身份运行，在具有默认输入和内存限制的 mod_php 上通过 HTTP 进行验证。
PHP 列出的缓解措施是真实的，它们是临时解决方案。公告说明：
- 以管理方式设置
memory_limit=-1（通过php_admin_value），保持post_max_size保守，如果不使用multipart请求则在前端阻止它们。 - 设置
session.upload_progress.enabled=0。 - 在 PHP 8.5 上，设置
fatal_error_backtraces=0。 - 在执行任何这些操作之后重新启动每个 worker。
同样的安全公告措辞明确，更新是唯一的完整修复。对于状态陈旧漏洞，根本不存在完整的通用配置缓解方案。PHP 核心开发者 Gina Peter Banyard 在 Tenable 的引用中表示，唯一的缓解措施是修补或升级 PHP，而 PHP 8.6 发布经理 Joe Ferguson 表示 ini 设置救不了你。所以把这份清单当作度过一个下午的桥梁，而不是一种态度。
两个实际问题让这一天比简单版本升级更加困难。共享主机和控制面板按照各自的时间表发布 PHP 包，所以你认为运行的版本可能不是实际运行的版本。Plesk 为其附带的 PHP 发布了自己的通知，这是你需要去读而不是假设的那种页面。
然后是更老的分支。php.net 公告指出 PHP 8.1 及更早版本不再从项目获得更新，并建议向发行版和 LTS 供应商寻求反向移植。安全团队确实在 GitHub 上为 7.4、8.0 和 8.1 发布了最小源代码反向移植分支，但源代码补丁不等于发布版本：仍然需要有人构建并将其交付给你的主机。PHP 5.4 到 7.3 什么都没有。如果你从未升级过，那就是你的 21 号截止日期。
一些规模数据。根据 10 月 22 日，W3Techs 显示 PHP 在 69.3% 的网站上运行（已知服务器端语言），其中 65.3% 运行版本 8，26.9% 运行版本 7，7.7% 运行版本 5。Censys 统计了 258 万个面向互联网的主机和 5490 万个运行 PHP 的网络资产。这是大量需要重新启动的 worker。
10 月 21 日那些无所事事的人
以请求路径术语来看这种暴露。问任何网站一个问题：当访问者加载一个页面时，什么代码运行来为他们提供服务？
CDN 上的静态 HTML
如果答案是"什么都没有，CDN 返回一个文件"，PHP2Shell 不会触及公共网站。没有 PHP 进程回答请求，所以在边缘没有什么要修补的，也没有理由让任何东西离线。我在 Astro 上运行 gautamkhorana.com，输出是静态的。我用 Next.js 和 Supabase 构建的 HostList，有大约 28,000 个程序化页面，没有 PHP 进程要修补。Deluxe Astrology 也没有，它在 30 种语言中运行 91,000+ 页面。没有人在 10 月 21 日接到电话。
Headless WordPress
Headless 是另一回事，我宁愿精确而不是奉承。那天 PHP 后端仍然需要 8.5.12、8.4.27、8.3.36 或 8.2.35，因为 WordPress 仍然在 PHP 上运行。区别在于它的位置。在防火墙或 IP 允许列表后面，公共网站由 Astro 或 Next.js 提供服务，后端不在访问者请求的路径中。补丁是一个维护任务，不是公共中断。
直言不讳地说：这不是"headless 是不可黑客攻击的"。能够到达后端的攻击者仍然可以到达漏洞，这就是允许列表很重要的原因。SSR 框架有自己的服务器运行时风险，在 Next.js、Astro 和 Nuxt 安全文章中有所涵盖，更广泛的比较在 headless vs WordPress security 中。我不会在这里重复任何一个。
一种模式，而不是一次性事件
这不是 PHP 的请求路径第一次登上头条。PHP-CGI 参数注入 CVE-2024-4577 出现在 2024 年。2012 年有一个较旧的 PHP-CGI 漏洞。现在是 PHP2Shell。不同的漏洞，相同的形状：坐在每个公共请求前面的代码被击中，下游的每个人都匆忙应对。
现在教训从另一个方向切割。Next.js 上的 React2Shell 表明 SSR 运行时有自己的请求路径暴露。如果 JavaScript 服务器回答每个页面请求，它就是修补目的的新 PHP。从 WordPress 移动到 Next.js 服务器渲染网站会改变攻击面。它不会删除它。静态输出是强有力的声明；SSR 是一种权衡。
所以问题从未是"哪种语言"。而是"什么代码回答公共请求"。把那份清单缩小，无论下一个 CVE 用什么语言编写，你的事件日子都会更短。
还有一个前瞻性的观点。Wiz 研究人员写道，这些漏洞已经存在了几十年，利用它们需要一系列步骤"在人类研究人员实际能够达到的边缘"，而且"前沿 AI 模型大大降低了那个障碍"（Krebs）。这意味着，这是我的而不是他们的：如果旧漏洞变得更便宜地转变为漏洞利用，每个运行时的披露节奏都会上升。计划更多这样的日子，而不是更少。
21 日 10 月按堆栈花费了你什么
| Stack | PHP 在公共请求路径中？ | 你在 10 月 21 日不得不做什么 | 下一个 PHP CVE 会让你付出什么代价 | 合理的迁移路径 |
|---|---|---|---|---|
| 经典 WordPress 或其他 PHP CMS | 是的，每一个页面 | 将 PHP 更新到修复版本、重启每个工作进程，或隔离站点直到你能处理 | 公共网站上同样的混乱 | 按页面类型逐步转向 Headless |
| Headless WordPress（防火墙后的 PHP 后端，Next.js 或 Astro 前端） | 不是，仅限后端 | 修补后端 PHP；公共网站继续服务 | 在锁定的主机上有个补丁窗口，不会公开中断 | 保留；将后端列入白名单 |
| Laravel 或自定义 PHP 应用 | 是 | 更新运行时、重启工作进程、检查你的主机发布了什么 | 同样的混乱 | 在前面放置静态或 SSR 前端，逐步移出页面类型 |
| 静态 Jamstack（Astro、Next.js 静态导出、Nuxt generate、Eleventy） | 否 | 边缘没有任何东西；检查构建工具和任何源站 | 边缘没有任何东西 | 保留 |
| Next.js 或 Nuxt 搭配 SSR | 没有 PHP，但 JavaScript 服务器处理请求 | PHP 没有任何东西；其自身的运行时公告适用 | 形状相同但不同的运行时 CVE | 将不需要每请求渲染的页面移至静态输出 |
经典 WordPress 或其他 PHP CMS。Drupal、Magento、Joomla 和 WordPress 都运行在 PHP 上，Calif 报告确认了这四者特定版本的身份验证前远程代码执行漏洞，详见 Tenable 的常见问题解答。这一行包含了当天的全部成本。
Headless WordPress。你进行了修补，但按照自己的时间表并在防火墙后进行。编辑人员继续编辑。访问者看不到任何东西。
Laravel或自定义PHP。与传统CMS相同的暴露程度，有一个转折：没有人为你的自定义应用发布产品公告，所以你拥有清单。NCSC-NL的php2shell存储库说明自定义PHP应用程序未在其概览中注册。
静态Jamstack。边缘没有什么要做的。如果你的构建在CI框上运行，可以在方便时进行修补，因为它不提供访问者服务。
使用Next.js或Nuxt的SSR。无PHP，无PHP2Shell。但服务器进程仍然处理请求，React2Shell提醒我们这个进程有其自身的不好的日子。
30/60/90天计划
目标是在不重建编辑体验的情况下将公开表面从PHP移除。
- 到第30天：列出你的页面类型（文章、登陆页面、产品页面、存档）并标记哪些真正需要按请求逻辑。确认每个主机上的PHP版本。在来源前面放置一个CDN并将管理限制在允许列表。
- 到第60天：为一个或两个流量最高的静态页面类型建立Astro或Next.js前端，从WordPress内容API构建。在发布时触发重建。为你移动的每个URL添加301重定向。
- 到第90天：迁移其余可以是静态的页面类型。关闭PHP来源对公开流量的访问，以便只有构建过程和你的允许列表编辑器能够到达它。任何真正需要服务器的东西（搜索、表单、账户）都转到一个小的、命名的服务，你可以自行修补。
在不失去CMS的情况下将公开表面从PHP移除
你不必放弃WordPress来将PHP从请求路径中移除。Headless WordPress保留编辑、内容和用于写作和批准的插件工作流，而Astro或Next.js提供网站服务。编辑保留他们熟悉的屏幕。访问者从CDN获取文件。
逐步迁移。选择一个页面类型，在新前端上重建它，301旧URL，然后继续。管理界面保留在PHP中，位于允许列表后面。托管模式很简单：来源被锁定，CDN在前面，在发布时构建。
关于框架选择：Astro用于内容网站，当网站需要应用层时使用Next.js，Vue团队使用Nuxt。更深层次的权衡在静态网站生成器比较和Headless WordPress指南中。
关于工作量，仅使用起价：WordPress到Astro迁移从$7k开始，Headless WordPress开发从$10k开始，传统CMS迁移从$5k开始。如果网站需要应用层，从$10k开始的WordPress到Next.js迁移是合适的路线。这些是起点，实际数字取决于页面类型、集成和你想保留多少编辑工作流。如果你正在考虑完全离开PHP，离开WordPress页面涵盖了这条路。
开始这项工作最便宜的日子不是公告发布后的第一天。但公告发布后的第一天是预算获得批准的时候，所以要利用它。
如果你暂时保留在PHP上
有些网站会保持原样一两年，没问题。同时请做以下事项：
- 确认运行的PHP版本是8.5.12、8.4.27、8.3.36或8.2.35（或你已阅读通知的供应商反向移植版本），并且每个工作进程都已重启。留下旧工作进程运行的软件包升级等于什么都没修复。
- 检查你的虚拟主机控制面板实际装了什么，而不是仪表板显示的内容。
- 仅将 PHP 列出的缓解措施作为过渡方案。公告指出这些措施不能使安装环境完全安全，OOM 公告警告不要使用
RLIMIT_AS和RLIMIT_DATA，这会触发易受攻击的代码路径。 - 现在就规划从7.4迁移到8.1。PHP项目不再更新8.1及更早版本，你依赖的是他人的反向移植。
- 在修补期间将网站放在WAF后面。Cloudflare首席技术官Dane Knecht称其规则"仅为临时方案"，Tenable指出它们只覆盖通过Cloudflare路由的流量。
- 注意web shell和不应该存在的PHP文件。Wiz预期会出现大规模利用来安装它们，所以要检查上传目录和最近修改过的文件。
对于将继续使用WordPress的网站，每月150美元起的WordPress安全维护覆盖持续的修补和监控。
10月21日最尖锐的事实是漏洞位于每个PHP访问者都会触及的地方，所以唯一不用做任何事的网站是那些PHP从不向公众请求回复的网站。静态输出是这一主张的强版本；headless WordPress的后端仍需修补，SSR只是把一个运行时换成另一个。
FAQ
WordPress受PHP2Shell影响吗？
WordPress 本身不是漏洞。漏洞在 PHP 中，WordPress 运行在 PHP 上，所以任何运行在未打补丁 PHP 上的 WordPress 网站都是暴露的。Tenable 的常见问题解答引用 Calif 的报告，称已确认针对特定 WordPress 版本的身份验证前远程代码执行漏洞，这解决了这个问题。
Headless WordPress还需要修补吗？
需要。后端运行PHP，如果攻击者能够到达它就能触发漏洞。Headless改变的是暴露程度：后端可以隐藏在防火墙或允许列表后面，同时由单独的前端向公众提供服务。
Next.js或Astro网站比PHP更安全吗？
来自任一框架的静态输出对于这类漏洞来说更安全，因为没有服务器端运行时来处理请求。SSR是一种权衡：你用PHP换成JavaScript服务器运行时，而它有自己的安全公告，React2Shell就是例证。
WAF能保护我吗？
部分能保护，而且只能保护一段时间。Cloudflare称其规则为临时方案，它们只覆盖通过Cloudflare的流量。WAF给你时间来修补。但它不是修补。
我应该让网站离线吗？
CERT-EU建议考虑隔离面向互联网的应用直到补丁可用，ENISA联合声明对于无法立即修复的情况说法相同。如果你能快速修补，就立即修补。如果不能，隔离是合理的选择。
哪些PHP版本已修复？
根据PHP安全公告，PHP 8.5.12、8.4.27、8.3.36和8.2.35已修复。
PHP 7.4、8.0和8.1被修补了吗？
不是通过发布版本。php.net 公告指出 8.1 及更早版本不再从 PHP 项目获得更新，安全团队改为为 7.4、8.0 和 8.1 发布了最小源代码反向移植分支。询问你的主机商或发行版是否已构建它们；无论如何，计划升级。