事件时间：2026 年 10 月 20 日 — 21 日
涉及主机：船长高配主机 / Cloudways / SiteGround
阅读时长：约 6 分钟
🌊 航海情报
先说结论。PHP 官方安全团队在 10 月 20 日发了一条公告，宣布将在 10 月 21 日 14:00 UTC（北京时间今晚 22:00） 发布一个紧急安全版本，修复 2 个 CVSS v4.0 评分 9.2 的严重漏洞。
漏洞编号是 CVE-2026-109618 和 CVE-2026-109619。
9.2 是什么概念？CVSS v4.0 里 9.0 以上属于 Critical 顶级区间。满分 10 分。也就是说这俩洞，官方自己评级是"几乎不可能被利用"——但前提是你已经打上补丁。
这不是插件漏洞，不是主题漏洞，是 PHP 解释器核心本身。WordPress、Drupal、Magento、Joomla、Laravel 全都跑在它上面。你在后台点一万次"更新插件"，这个洞依然在那儿。
我把几个关键信息先摆出来：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
补充一句版本号的来源：官方公告到发布前故意不写修哪个版本，写了等于给攻击者划重点。目前流传的 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 这几个数字来自安全研究者的推算，等今晚官方公告发布才算最终确认。
🔎 攻击已经开始了
这是这次事件最需要重视的部分。
10 月 20 日白天，有人在 Hacker News 发帖，说 PHP 马上要曝两个 RCE。原定 10 月 22 日解除禁运。帖子很快被删了，但截图已经在 X 和 Mastodon 上传开。
10 月 20 日当天，watchTowr 出来确认：漏洞是真的，确实是 RCE，并且他们复现了其中一个。他们被要求闭嘴等发布。
10 月 20 日晚上，PHP 官方发预告公告，并且把补丁从 22 日提前到 21 日。
10 月 21 日 07:34 UTC，Patchstack 收到多家托管商上报的真实入侵事件。不是理论推演，是客户报案。
10 月 21 日 07:43 UTC，Cloudflare CTO Dane Knecht 公开表示"我们看到早期攻击正在出现"，同时上线了 4 条针对已知利用向量的 WAF 规则，免费版用户也能吃到。
10 月 21 日 09:18 UTC，Aikido 报告称已在野外发现利用。
另一边，荷兰的 DigiD、MijnOverheid、荷兰国会官网、NCSC 官网直接下线，日本一批平台进入紧急维护。Sansec 的判断是：补丁公开后 15 分钟内就可能出现大规模扫描。
禁运期被打破的那一刻，攻守关系就变了。
原本的理想剧本是：漏洞细节封着 → 托管商和发行版悄悄把补丁推给用户 → 用户升完 → 公开细节 → 安全研究者开始研究。攻防双方信息对等。
这次不是。细节先泄，补丁后到，中间还夹着"漏洞真实存在且可复现"的确认。
等于说：攻击者先看到了门在哪，防守方还堵着门。
🔖 各个主机商的解决方案
1. 船长高配主机
方案：开启网站的 Cloudflare proxy，并完成 PHP 版本升级，双管齐下防御此次漏洞。
具体动作分两步走：
第一步，开启 Cloudflare proxy（灰云改橙云）。
这一步的价值在于——Cloudflare 已经在 07:43 上线了 4 条针对本漏洞的 WAF 规则，免费版同样生效。开启 proxy 之后，你站点的所有流量都会先经过 Cloudflare 的清洗层，攻击请求在到达你的源站之前就被拦掉了。
要注意一个前提：WAF 规则只对走 Cloudflare 回源的流量有效。如果你的源站 IP 是公开的，攻击者可以绕过 Cloudflare 直接打源站。所以如果你的主机商给的是独立 IP，建议确认一下源站是否做了限制——只允许 Cloudflare 回源 IP 段访问。
第二步，升级 PHP 版本。
这是根治手段。临时缓解只是把窗口拉长，升级才是真正把门焊死。
第二步不能省。 原因前面讲过：漏洞在解释器核心，session.upload_progress 这个特性默认开启，未认证就能构造请求触发。WAF 能挡掉已知特征，但挡不住变形。
两步的顺序有讲究。 先开 Cloudflare proxy（分钟级生效，立刻拿到 WAF 保护），再排期升级 PHP（可能需要主机商配合、有重启窗口）。先有伞再修腿，别反过来。
2. Cloudways 主机
官方在状态页发的原文大意是：
Cloudways 安全团队正在密切关注事态发展，并实施临时缓解措施，以加固受影响 PHP 环境的防护，同时等待 PHP 集团发布官方补丁。PHP 集团已宣布补丁版本预计将于 2026 年 10 月 21 日 14:00 UTC 起开始发布，不同 PHP 版本的可用时间会有所不同。对于已弃用的 PHP 版本，Cloudways 正在利用其扩展长期支持（ELTS）合作伙伴关系，以在官方补丁可能无法提供的情况下继续维持安全覆盖。
拆成三层看：
监控 — 安全团队主动跟，不是等客户来问。 临时缓解 — 补丁没到之前先加固环境，不干等。 ELTS 兜底 — 这是最关键的一层。Cloudways 支持 PHP 7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4，而官方这次只修 8.2 以上。老版本怎么办？他们通过扩展长期支持（ELTS）合作伙伴（业界这块主要玩家是 Zend）来回移植安全补丁。
翻译成人话：PHP 官方说"8.1 以下我不管了"，Cloudways 转头自己掏钱把这条线接住。2025 年 Zend 光回移植就做了 10 多个 CVE。
这一层是花钱买来的续命，不是免费方案。 而且它只覆盖已弃用的那几个老版本——如果你跑的是 8.2 以上，Cloudways 走的是官方补丁那条路。
3. SiteGround 主机
官方 X 账号（回复用户提问时发的）大意是：
由于这条通知，你不需要切换到 Managed PHP。我们的工程师已经在服务器上实施了安全缓解措施，覆盖了通过 Site Tools 提供的所有受支持的 PHP 版本，包括 PHP 8.4.26。我们会密切监控局势，并在需要时实施任何额外的安全更新。
三句话，三个动作：
先否定一个动作。 社交媒体上当时肯定在传"赶紧切到 Managed PHP"，官方第一条就否掉——因为切换 PHP 版本可能把老主题、老插件搞崩，那叫制造新问题。
服务器层统一加固。 措辞是 across our servers，不是给单个站点打补丁。覆盖范围明确写了"所有受支持的 PHP 版本，包括 PHP 8.4.26"——8.4.26 是当前最新版，说明这是批量铺开的动作。
保留追加权。 "as needed"，补丁真落地之后还得再动一次。
这里有个必须点出来的细节。 SiteGround 说"覆盖所有受支持版本"——7.4 不在"受支持"里。SiteGround 的可选版本是 8.6 / 8.5 / 8.4 / 8.3 / 7.4，7.4 摆在那儿让你选，但官方已不维护，这次也不会有补丁。
翻译："已处理"这三个字，往往不覆盖你。
📋 三家横向对比
📌 参考来源
-
PHP 官方公告：https://www.php.net/archive/2026.php#2026-10-20-1 -
Cloudways 状态页：https://status.cloudways.com/incidents/xxjt802wwhpk -
CERT-EU 公告 2026-018：https://cert.europa.eu/publications/security-advisories/2026-018/ -
UK NCSC 警报：https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php -
Patchstack 实时追踪：https://www.patchstack.com/articles/php-major-vulnerability-alert-10-2026 -
Tenable RSO FAQ：https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
本文信息截至 2026 年 10 月 21 日 20:00（GMT+8）。官方完整技术细节与受影响版本清单将于今晚 22:00 补丁发布后公布，届时以 php.net 官方公告为准。