Kinsta 复盘 PHP2Shell 紧急补丁部署与平台级防护

2026年10月21日，攻击者已开始向网站发送旨在利用两个名为 PHP2Shell 的严重 PHP 漏洞的请求。官方安全补丁尚未发布，但我们的工程和安全团队已经着手保护 Kinsta 托管的网站。

此次响应涉及多个方面。我们的团队启用了 Cloudflare 紧急防火墙规则，调整了 PHP 配置，并准备在补丁发布后立即将其部署到数十万个容器中。与此同时，我们的支持团队正在回答大量客户关于网站安全的疑问。

截至10月23日，我们的 Cloudflare 防护措施已拦截超过550,000次针对这些漏洞的请求。我们还已在整个托管平台上部署了必要的 PHP 安全更新，未发现成功入侵的证据。

以下是此次响应从最初出现利用迹象，到补丁部署及后续工作的全过程。

在补丁可用前为 PHP2Shell 做好准备

10月20日，PHP 安全团队宣布即将发布一项关键安全更新，计划于次日发布。公告警告称存在两个 CVSS 4.0 严重性评分为 9.2 的漏洞，并敦促 PHP 用户为尽快更新安装做好准备。

这些漏洞后来被确认为 CVE-2026-109618 和 CVE-2026-109619，影响 PHP 的内部内存处理，在某些情况下可能允许攻击者在无需认证的情况下远程执行代码。

这项公告对于 WordPress 网站尤其重要，因为 PHP 是运行该应用程序的核心。更新 WordPress 插件或主题无法修复这些漏洞，必须对底层 PHP 运行时进行安全修复。

对于 Kinsta 等托管服务商而言，首要挑战是在官方补丁发布前保护网站。我们的团队开始为此次更新做准备，但利用尝试已经出现。

据 Kinsta 工程总监 Laszlo Farkas 表示，我们的团队从10月21日凌晨开始观察到针对这些漏洞的请求。工程师手动检查了受攻击的网站，并持续监测活动，以寻找成功入侵的迹象。

此时，我们已经采取措施保护平台上的网站。

我们如何启用 Cloudflare 紧急 WAF 规则

所有由 Kinsta 托管的网站都位于 Cloudflare 之后，包括生产和预发布环境。这使我们的工程团队无需客户为各个网站配置规则，就能在整个托管平台上应用防火墙防护。

在 PHP2Shell 公开披露之前，Cloudflare 推出了用于检测利用尝试的紧急 Web 应用防火墙（WAF）规则。随着新规则陆续推出，我们的工程团队密切监测 Cloudflare 的 WAF 变更日志，审查这些规则，并尽快将其操作设置为“阻止”。

由于每个 Kinsta 网站都已位于 Cloudflare 之后，我们得以在整个托管平台上应用这些防护措施，覆盖生产和预发布环境，而无需客户采取任何操作。

这种覆盖整个平台的防护之所以重要，是因为 PHP2Shell 并非典型的应用层漏洞。攻击针对的是 PHP 本身，因此 WordPress 安全更新或插件层防护无法解决根本问题。

WAF 规则让我们在准备 PHP 补丁期间，能够拦截已知的漏洞利用尝试。与此同时，Cloudflare 持续更新防护机制，以应对攻击者变换攻击手法。其关于 PHP2Shell 的技术报告详细说明了攻击者如何修改攻击载荷，以绕过现有检测机制。

Cloudflare 还引入了完整事务检测功能，该功能会同时分析来自 HTTP 请求和服务器响应的信号。这为识别可疑请求提供了额外信息，并且能够阻止匹配的响应到达请求方。

随着新规则不断上线，我们的工程师得以看到攻击模式的变化。

截至 10 月 23 日，Cloudflare 面向 Kinsta 站点的防护已拦截了 超过 550,000 个针对 PHP2Shell 的请求。

该数字指的是与这些漏洞相关的被拦截请求，而不是成功入侵次数或不同攻击者的数量。它反映了团队部署 PHP 修复期间，我们的防火墙防护所处理的可疑流量。

添加临时 PHP 配置防护

我们没有仅依赖 Cloudflare。在等待已修补的 PHP 软件包期间，我们的工程团队还在所有托管环境中实施了 PHP 配置更改，以减少已知漏洞利用路径所带来的暴露风险。

其中一项更改是使用 session.upload_progress.enabled 设置关闭 PHP 的会话上传进度功能。

PHP 的安全公告将该设置列为应对某些漏洞利用路径的一项缓解措施。关闭它有助于阻止依赖 PHP 会话上传进度处理机制的攻击，但无法防止这些漏洞以所有可能方式被利用。

在补丁尚不可用或仍在部署期间，防火墙规则和配置更改提供了额外防护。不过，更新 PHP 运行时仍然必要。

10 月 23 日，PHP 团队又发布了一份补充公告，建议在后续缺陷修复版本发布之前，继续关闭会话上传进度功能。这进一步印证了我们的工程团队此前已采取的预防措施。

在补丁部署的整个过程中，无论某个环境是否已经收到更新后的 PHP 软件包，我们的 Cloudflare 规则和本地配置防护都始终保持启用。

在数十万个容器中部署 PHP 补丁

PHP 开发团队于 10 月 21 日发布安全更新后，我们的下一个挑战是将这些修复部署到整个托管基础设施中。

官方发布版本包括 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12。不过，Kinsta 也支持较旧的 PHP 版本，而这些版本需要第三方维护人员提供的安全修复。

我们与 PHP 软件包供应商 Freexian 合作，为平台上运行的各个 PHP 版本获取了已修补的软件包，其中包括较旧的长期支持版本。

这些软件包是逐步提供的，并非一次性全部到位。每当新的构建产物到达我们的软件包镜像仓库，工程团队就会对其进行验证并开始部署，而不必等待所有 PHP 分支准备就绪。

部署进展如下：

以如此规模部署变更的能力是此次响应最重要的组成部分之一。

Farkas 强调了该团队能够多快在整个基础设施中部署变更：

“这是我最引以为傲的部分。一旦变更经过验证，并且我们确认它不会破坏任何东西，我们就能在几个小时内将其部署到整个基础设施。”

这项能力使我们的团队能够在数小时内将修补后的 PHP 软件包部署到数十万个容器中。

我们也不必与每位客户协调 PHP 更新。Kinsta 在平台层面管理 PHP，因此一旦工程团队验证了更新后的软件包，我们就可以将其部署到受影响的环境中，而无需要求网站所有者自行安装更新。

为什么较旧的 PHP 版本需要额外修复

此次部署还必须考虑 PHP 官方支持的分支与由第三方供应商维护的旧版本之间的差异。

PHP 项目发布了 PHP 8.2 至 8.5 的安全更新。PHP 7.4、8.0 和 8.1 等版本不再直接从 PHP 项目获得常规安全发布，尽管长期支持提供商可以提供回移植修复。

回移植使维护者能够将安全修复应用到较旧的软件分支，而无需用户升级到较新的 PHP 版本。

这意味着，随着 Freexian 发布修补软件包，我们可以为这些较旧的 PHP 环境部署安全更新。

这也解释了为什么仅凭 PHP 版本号并不总能判断某个特定安全修复是否已应用。由供应商维护的软件包可以包含修补后的代码，而不必显示与 PHP 官方上游发行版相同的版本号。

在整个部署过程中，我们持续部署更新，同时维持额外的防火墙和配置保护措施。

监控攻击并检查被攻陷的迹象

部署补丁只是响应的一部分。我们的团队还需要确定，观察到的任何漏洞利用尝试是否成功。

当我们在 October 21 凌晨首次注意到针对 Kinsta 托管网站的活动时，我们的工程师手动调查了相关网站。

在整个事件期间，他们持续监控可疑流量并抽查托管环境，寻找攻击者已成功利用这些漏洞的迹象。

Cloudflare 安全事件帮助我们了解攻击目标，以及随着我们发布新规则，攻击模式如何变化。然而，仅凭被拦截请求的数量无法判断是否有任何攻击成功。

正因如此，手动检查才至关重要。我们的团队还与 Patchstack（我们的漏洞防护合作伙伴）保持密切联系，分享双方观察到的威胁和攻击模式。我们还参与了与其他托管服务商的讨论，在整个 PHP 社区应对此次事件期间交流信息和良好实践。

这些工作与我们同 Cloudflare 和 Freexian 的合作相辅相成。Cloudflare 提供针对漏洞利用尝试的防护，Freexian 提供已修补的 PHP 软件包，而与安全合作伙伴的协调帮助我们的工程师了解威胁是如何演变的。

在整个事件期间，我们没有发现与 PHP2Shell 相关的成功入侵证据。

这一结论基于响应期间开展的监控和调查。这并不意味着没有发生过攻击，防火墙数据显示确实存在攻击。这意味着我们的检查未发现成功攻陷的迹象。

解决事件并继续核查

10 月 22 日 08:26 UTC，我们在公共状态页上将该 PHP 安全事件标记为已解决。

届时，我们已经在整个平台推出安全更新，所有站点均受到补丁修复与缓解措施的共同保护。

事件解决并不意味着我们停止检查。在这次公开事件关闭后，我们的团队继续核查各环境并监控防护状态。

在一次涉及多个 PHP 分支和数十万容器的部署过程中，这一点尤为重要。04:31 UTC 时，仍约有 0.5% 的容器需要额外处理。我们的工程师继续处理这些剩余环境并核实结果，而不是将修补软件包已可用视为每个安装均已更新的证据。

在这项核查工作期间，Cloudflare 规则和 PHP 配置防护也继续保持启用。

对客户而言，PHP 安全更新无需手动打补丁或切换版本。

回应采取额外防护措施的客户

对 PHP2Shell 的应对远不止于托管服务商。随着这些漏洞的消息传开，世界各地的政府机构和其他组织开始暂时下线网站，同时准备安全更新。

在荷兰，国家网络安全中心出于预防措施也下线了自家网站。德国、法国、比利时和芬兰的政府网站也被暂时停用。在日本，首相 Sanae Takaichi 在 X 上发布紧急警告，敦促网站运营者尽快应用补丁；如果无法立即更新，则应暂时暂停服务。

在 Kinsta，我们也看到客户中存在类似担忧。我们的支持团队收到的有关 PHP2Shell 的问题大幅增加，一些客户也开始采取额外防护措施保护网站。

这些措施包括使用 MyKinsta 的环境暂停功能将站点下线、通过 Bot Protection 启用全站质询，或要求支持团队在服务器级别屏蔽传入流量。事件期间，客户主动暂停了约 3,000 个站点。

鉴于这些漏洞的严重性以及其他方面正在采取的防护措施，这些决定是可以理解的。不过，工程团队并未建议客户将托管在 Kinsta 上的网站下线。我们已经在整个托管平台上启用了 Cloudflare 的紧急 WAF 规则，因此，保持在线的网站仍能继续获得这些保护，不会出现访客无法访问的情况。

支持团队开始建议客户避免不必要地将网站下线，与此同时，工程团队继续部署 PHP 补丁。

部署安全更新后，我们审查了事件期间采取的停用操作，以确定哪些网站是客户专门因 PHP2Shell 而下线的。

随后，我们的团队重新启用了这些环境，同时未触碰因其他原因而暂停的网站。这要求将预防性下线与其他有意停用区分开来，而不是简单恢复每一个曾被下线的环境。

除了阻止攻击和部署补丁，我们的团队还必须帮助客户从事件期间采取的防护措施中恢复。

这次应对对 Kinsta 客户意味着什么

PHP2Shell 需要工程团队、支持团队以及多家外部安全和基础设施合作伙伴协同配合。不过，补丁部署本身由平台完成。

客户无需追踪每个 PHP 版本的发布情况、确定网站需要哪个已修补的软件包，也无需自行安装更新。

Farkas 解释了这次应对最终对 Kinsta 客户意味着什么：

“对我来说，最主要的信息是，客户根本不需要操心这些事情：更新什么、何时更新或如何更新。他们在我们的平台上就已受到保护。”

事件期间客户的反应也说明了为什么沟通这些防护措施很重要。一些客户即使在紧急 WAF 规则已经启用后仍将网站下线，随后我们的团队着手恢复因这些漏洞而暂停的环境。

与此同时，我们的工程团队将 PHP 安全更新部署到数十万个容器中，且无需客户管理这些变更。

有关安全更新和事件解决情况的记录，请参阅我们的 PHP 安全事件报告。

如需了解这些漏洞对你的网站意味着什么，请参阅我们的配套文章《PHP2Shell：Kinsta 如何保护 WordPress 站点》。

《Kinsta 紧急 PHP2Shell 补丁部署内幕》一文最初发布于 Kinsta®。