PHP2Shell：与时间赛跑——PHP 漏洞对网站、设备和您的数据意味着什么

两个严重的 PHP 缺陷、提前破裂的信息披露禁运期，以及正式公开前就已出现的攻击尝试：PHP2Shell 影响的不只是传统网站。存在漏洞的运行时还可能嵌入防火墙、主机管理面板和其他设备中。本文将用易懂的方式说明发生了什么、哪些人必须采取行动，以及个人用户真正应该做什么。

10 月 20 日，两个起初并不起眼的编号出现在互联网上：CVE-2026-109618 和 CVE-2026-109619。它们背后是两个尚未完全披露的 PHP 漏洞。PHP 是无数 Web 服务器用于处理表单、查询数据库并生成页面的技术。

披露原本应按既定顺序进行：先发布更新和准备好的防护规则，再公布技术细节。然而，漏洞编号提前公开，错误的最高评分 10.0 开始流传，当晚还意外发布了一段展示可用攻击的视频。PHP 因此将发布日提前了一天。

但平静起步已经来不及了：Amazon 后来发现了一次发生在 10 月 17 日的漏洞利用尝试，比补丁早四天。漏洞公开后，各方记录到迅速扩大的攻击浪潮；路透社援引 Cloudflare 的数据称，数小时内就出现了数百万次尝试。这并不意味着发生了数百万次成功入侵，但它说明如今自动化系统测试严重漏洞的速度有多快。

漏洞本身并不位于您的智能手机上，但它仍可能通过服务商保存的数据、被篡改的网站、更具迷惑性的钓鱼活动，或出于预防而被关闭的服务影响您。您的设备可能完全干净，而您的数据却在他人的服务器上面临风险。

首先需要了解的重点

PHP2Shell 是对 PHP 核心中两个内存安全缺陷的统称。在特定条件下，攻击者无需登录即可在服务器上执行代码；其中一个漏洞还可能泄露内存中的会话令牌、密码、API 密钥或数据库凭据。两个 CVE 的 CVSS 4.0 评分均为 9.2。

上游分支从 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 起已修复。较旧分支可能由发行版、主机服务商或 LTS 服务商提供回移植修复。仅更新 CMS 或插件并不够：关键在于实际处理 Web 请求的 PHP 运行时。

个人用户无需在手机上安装任何东西。运营方必须盘点并修补运行 PHP 的网站、容器、管理界面和设备，同时调查是否曾遭受更早的攻击。

1. 一个旧的内存问题如何演变成全球性的时间竞赛

2024 年：尚无已证实攻击的预警信号

事情始于 2024 年。在一次外部 PHP 安全审计中，研究人员发现了后来演变为内存耗尽问题的早期迹象。但当时尚没有从 Web 请求可靠走向代码执行的路径，而潜在修复又可能破坏兼容性或稳定性。规模不大的安全团队未能迅速达成共识。PHP Foundation 后来公开将这次延迟称为结构性失败：决策流程过于迟缓，资源也过于匮乏。

2026 年夏：AI 辅助研究将理论变为现实

2026 年 7 月和 8 月，Calif、OpenAI 和 Wiz 使用传统方法与强大的 AI 模型研究 PHP 核心。8 月 11 日，研究人员报告了一条具体的远程代码执行路径；Wiz 还独立发现了更多变体，并针对真实 PHP 应用演示了攻击链。人类仍需复现结果、排除误报并审查补丁。但 AI 确实缩短了搜索时间，也随之压缩了漏洞公开后留给防守方的时间。

10 月 17 日：目前已知最早的尝试

Amazon Threat Intelligence 后来在 MadPot 遥测数据中发现了一次发生于 10 月 17 日的漏洞利用尝试。蜜罐命中并不能证明真实系统已被成功入侵，但它将取证回溯窗口向前推移。攻击者为何能如此早地获得足够信息仍不清楚，也没有可靠的归因结论。

10 月 20 日和 21 日：禁运期破裂，补丁发布

10 月 20 日，CVE 编号开始公开流传，同时出现了错误的 CVSS 10.0 评分和一段误发的攻击视频。PHP 将发布提前到 10 月 21 日 14:00 UTC。主机服务商、发行版和安全厂商同步准备软件包与过滤规则。Cloudflare 在正式发布前就启用了防护规则，并综合分析请求和响应信号。即便如此，WAF 仍只是额外屏障：它无法修复存在漏洞的 PHP 代码。

修复版本于 10 月 21 日发布，随后很快出现公开利用工具和大规模扫描。政府机构、医院、高校和企业出于预防下线了部分服务，柏林和勃兰登堡的警方服务也曾一度下线。这并不是入侵证据，反而可能表明应急流程有效：与其在失陷状态下继续在线，不如有控制地离线。PHP2Shell 也清楚表明，面向互联网的系统遇到严重 RCE 漏洞时，必须以小时而不是以天为单位响应。

已经确认存在两个严重的 PHP 漏洞、活跃的利用尝试，以及极其广泛的潜在攻击面。仍不清楚究竟有多少系统已被入侵，或有多少数据已经丢失。

2. 技术上究竟出了什么问题——不堆砌不必要的术语

PHP 工作在网站的“机舱”里：它执行 WordPress、网上商店或门户的代码，处理输入，并与数据库通信。缺陷位于 CMS 层之下。因此，即使应用本身已完全更新，也仍可能运行在存在漏洞的 PHP 运行时之上。

CVE-2026-109618：使用不完整数据进行清理

如果 PHP 在不恰当的时刻达到 memory_limit，处理可能会在内部数据结构仅完成部分初始化时中断。随后在清理过程中，PHP 可能把这些区域当作有效数据。攻击者会尝试有意触发这种状态，并塑造内存布局，使其最终导致代码执行。

在 Apache 配合 mod_php 的环境中，研究人员已演示无需身份验证的攻击，而且它可能在应用自身代码运行前就生效。在这种情况下，登录、双因素认证或 WordPress 安全插件都无法提供保护。其他 PHP 部署模式也可能受影响；前置条件和可靠性取决于 SAPI、应用及配置。

CVE-2026-109619：失效引用延续到下一次请求

在第二个漏洞中，严重错误发生后，指向已释放内存的引用仍然存在。当同一个 PHP 工作进程处理后续请求时，会再次使用这一陈旧状态——也就是释放后使用（use-after-free）或陈旧的全局状态。

后果可能包括代码执行、崩溃或内存信息泄露。最后一种尤其隐蔽：攻击者无需留下可见的 Web Shell，也可能获得会话令牌、数据库密码、API 密钥或证书。因此，打补丁后仅检查是否有文件被修改远远不够。

远程代码执行首先意味着代码以 PHP 或 Web 服务器账户的权限运行，并不自动等同于获得 root 权限。但该账户仍可能读取配置、访问数据库或连接内部服务。因此，文件权限、网络分段和最小权限原则决定了入侵能够扩散多远。

3. 互联网真的有近 70% 受到影响吗？

W3Techs 的数据显示，截至 2026 年 10 月 23 日，在其能够识别服务器端编程语言的网站中，69.3% 使用 PHP。在这些 PHP 网站中，65.3% 使用 PHP 8，26.9% 使用 PHP 7，7.7% 使用 PHP 5。

这些数字描述的是普及率，而不是补丁状态或成功攻击的数量。许多系统在数小时内完成更新，发行版会在较旧版本号下回移植修复，而某些设备上的漏洞路径可能并未对公网开放。因此，更准确的表述是：在服务器端语言可识别的网站中，大约每十个就有七个使用 PHP，并需要检查其防护状况。如今仍有多少系统存在漏洞或已经失陷，无法可靠量化。

4. PHP2Shell 对个人用户意味着什么

PHP 不会直接感染您的设备

PHP2Shell 运行在服务器上。您无需重置智能手机，也无需安装专用应用。只有当被篡改的网站诱导您下载恶意内容时，您的设备才会面临风险。请保持操作系统、浏览器和应用为最新版本，并只使用可信来源。所谓面向设备的“PHP2Shell 更新”几乎肯定是诱饵。

您的数据仍可能受到影响

当您在网上商店下单时，姓名、地址和订单记录可能会被长期保存。如果服务器遭到入侵，即使您数月未访问该网站，这些数据也可能受到影响。内存信息泄露还可能暴露并非以文件形式存放在服务器上的令牌和访问密钥。

即使是熟悉的网站也可能被篡改：域名和锁形图标保持不变，而注入的脚本却在窃取登录或支付数据。HTTPS 保护的是到服务器的传输路径，而不是服务器自身的完整性。遇到异常的支付窗口、跳转或下载时，应立即停止操作，并通过已知的官方渠道联系服务商。

技术攻击之后往往还会出现诈骗

被盗信息会让钓鱼内容更可信。即使消息中包含您的真实姓名和正确订单号，也可能是伪造的。重要服务应通过官方应用、书签或您自行输入的地址打开。账户被接管的迹象包括意外的登录或密码重置通知、陌生会话、恢复信息被更改，以及您未发起的推送确认、TAN 或双因素认证请求。不要因为“以防万一”而批准任何请求；应直接进入账户检查并移除未知设备。

对于网上银行，由于强客户身份验证，通常仅凭密码或 PIN 无法完成操作。但钓鱼仍可能诱使您为他人的登录或支付批准一次真实的授权。请核对收款人、IBAN 和金额；如发现陌生操作，应通过银行官方应用或已知电话号码联系银行。

现在可以采取的合理措施

如果服务商仅报告维护或预防性停机，您无需无差别更改密码或冻结银行卡。请使用官方替代渠道，并关注服务商的后续通知。

如果服务商报告登录凭据可能泄露，请更改该服务的密码，以及所有重复使用该密码的地方。结束活动会话，启用双因素认证或通行密钥，并优先保护您的电子邮件账户。

如果您曾在可疑网站输入信息，或安装了所谓的安全应用，请从另一台设备保护账户；如涉及支付数据，请联系银行，并对受影响设备进行检查。

任何安全应用或 VPN 都无法修复他人网上商店的 PHP 运行时。安全软件可以帮助抵御第二波攻击，例如恶意下载、假冒应用和已知恶意网站，但它并不能证明他人服务器上的数据是安全的。

5. PHP 也运行在防火墙、NAS 和其他设备中

PHP 不只存在于网站中，也会用于防火墙、路由器、NAS、主机管理面板、VoIP 设备、摄像机录像设备或工业设备的管理界面和附加服务。只有当产品使用存在漏洞的 PHP 版本处理可达的 Web 请求时，才会受到影响。暴露程度以及厂商补丁是否可用也同样重要。

pfSense：Netgate 已确认，基于 PHP 的 GUI 和强制门户（Captive Portal）受到影响。默认 GUI 通常只能从局域网访问；强制门户则会有意面向不受信任的客户端。同一个缺陷会因暴露方式不同而具有不同风险。

Palo Alto Networks：部分 PAN-OS 和 Panorama 版本受到影响。根据厂商说明，问题影响包括 XML API 在内的管理 Web 界面，并非笼统影响数据平面或 GlobalProtect。在安装修复之前，管理访问应只允许来自可信网络，或通过受控跳板机进行。

Plesk：客户网站使用各自的 PHP 处理程序，而 Plesk 界面使用独立引擎。只更新其中一层可能会遗漏另一层。因此，Plesk 为两个组件都发布了更新。

Cisco 和 Sophos 的情况说明了为什么必须分别评估产品、云服务和客户环境中的安装。Cisco 确认部分产品系列受到影响，将另一些列为不受影响，并继续调查其他产品。Sophos 表示其产品不受影响，但由于单独托管的旧版 MyUTM 门户使用了存在漏洞的 PHP 版本，仍将该门户暂时下线。

荷兰 NCSC 维护着持续更新的状态列表。它是很有价值的资产清单，但不能替代厂商最新的安全公告：存在 PHP 依赖并不能证明漏洞可被利用，没有公告也不代表已经安全。

家庭或组织中的设备应检查什么

记录厂商、型号、固件版本和附加软件包。在官方支持网站搜索两个 CVE 以及“PHP2Shell”，并只通过规定的固件或软件包机制安装更新。切勿自行替换嵌入式 PHP；设备通常包含厂商定制和签名组件。

关闭来自 WAN 的远程管理、不必要的端口转发和 UPnP 映射，并检查云端远程访问。确需外部访问时，应尽可能先连接 VPN，再打开本地管理界面。

隔离访客网络、IoT 网络和管理网络，避免已被入侵的设备访问本地管理服务。如果防火墙、NAS 或摄像机录像设备已经无法获得安全更新，更换设备往往是唯一可持续的方案。

6. 运营方现在必须采取的具体措施

步骤 1：明确责任并完成资产盘点

在托管主机环境中，通常由服务商执行更新；对于 VPS、专用服务器、容器和设备，则由您或您的服务商负责。应要求对两个 CVE、软件包或固件版本，以及所有 PHP 进程是否已重启给出可验证的答复。同时盘点域名、子域名、预发布环境、旧项目、Web 邮件、容器和内置 PHP 的设备。

步骤 2：核实正确的补丁级别

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35。PHP 7.4、8.0 和 8.1 可获得源代码回移植修复；应以发行版或 LTS 服务商的安全公告为准。

发行版可能把修复回移植到较旧的软件包版本中。例如，Ubuntu 24.04 LTS 将 8.3.6-0ubuntu0.24.04.13 列为已修复版本；cPanel 也发布了回移植修复。因此，应将完整的软件包版本与发行版或平台服务商的安全公告进行比对，而不是只看上游版本号。

步骤 3：验证实际处理请求的运行时

php -v 通常只显示命令行版本。Web 服务器可能通过 PHP-FPM、mod_php 或容器使用另一套安装。因此，应检查 FPM 池、Web 服务器模块、虚拟主机和镜像：

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

更新后必须替换旧的工作进程：对于 mod_php，通常需要重启 Web 服务器；对于 PHP-FPM，则需要重启各个池。用同一镜像重启容器并不能解决问题；必须更新镜像并重新部署。

步骤 4：无法立即打补丁时，应在请求到达 PHP 前将其阻断

如果无法立即修补，请将访问限制在可信网络或 VPN 内，或者将服务下线。如果攻击在应用代码运行前生效，WordPress 维护插件无法提供保护。应使用静态维护页面，或在反向代理、负载均衡器或 Web 服务器处阻断访问。

WAF 和 CDN 规则可以争取时间，但并不是补丁。Cloudflare 观察到攻击模式不断变化，因此必须同时评估请求和响应。还应确保源站无法通过第二个 IP 地址或备用主机名被直接访问。

关闭会话上传进度、收紧内存和上传限制等 PHP 配置措施，只能减少部分攻击路径，而且可能带来副作用。

步骤 5：至少回溯检查到 10 月 17 日

在日志轮转前保存 Web 服务器、PHP、代理、WAF、系统和容器日志。搜索异常表单请求、PHP_SESSION_UPLOAD_PROGRESS、内存错误、意外的 Shell 进程、新文件、新账户、cron 任务和出站连接。成功攻击并不一定会让工作进程崩溃；反过来，单个错误也不能证明发生了入侵。关键是整体情况。

步骤 6：轮换 PHP 可访问的密钥和凭据

由于内存内容可能泄露，对于面向互联网且曾未修补的系统，应轮换 PHP 进程能够读取的所有机密信息，例如数据库密码、API、云和部署令牌、SMTP 或 OAuth 凭据以及会话密钥。应先修补或隔离漏洞，再从可信环境生成新的凭据。

步骤 7：出现入侵迹象时，不要只做“清理”

如有入侵迹象，应以受控方式隔离系统，保存日志，并在适当情况下保全易失性数据；关键主机应从可信制品重建，而不是仅删除可见文件。还应检查管理员和数据库账户、部署流水线及相连系统。如果个人数据可能受到影响，应尽早让隐私或数据保护负责人介入；依据 GDPR，达到通知条件的数据泄露原则上必须在 72 小时内报告。

7. 更深层的教训：发现速度正在加快，修复必须跟上

PHP2Shell 展示了 AI 如何改变“理论上可能”与“实际可利用”之间的边界。模型能够大规模分析源代码、崩溃轨迹和补丁差异；因此，从漏洞披露到出现可用攻击代码之间的时间也在缩短。

答案并不只是使用更多 AI。维护者需要资源和清晰的决策流程；运营方需要完整的资产清单、快速的补丁路径、隔离能力和经过演练的恢复流程。在 Protectstar，我们将 AI 用作代码审查和人工验证的补充。它可以加快发现速度，但不能替代责任。

结论

PHP2Shell 直接影响服务器，但个人用户感受到的可能是数据风险、诈骗尝试或服务中断。应保持警惕而不是恐慌：使用官方联系渠道，不批准意外的确认请求，并根据受影响服务商的通知采取有针对性的措施。

对运营方而言，关键是实际运行的 PHP 运行时、每一个被遗忘的实例、嵌入式组件、旧进程的重启，以及至少回溯到 10 月 17 日的调查。如果没有补丁，隔离比继续运行更负责任。网站能够访问，并不能证明它是安全的。