这周末运维又得加班了

PHP 核心近期披露并修复了两个被称为 PHP2Shell 的极危远程代码执行（RCE）漏洞，编号为 CVE-2026-109618 和 CVE-2026-109619，其 CVSS v4.0 评分均高达 9.2 分

这次披露的两个漏洞都发生在 PHP 核心层面，而不是某个具体的应用程序或框架中。因此，风险可能涉及多种 PHP 运行环境，包括 PHP-FPM、Apache mod_php、php-cgi，以及其他基于 PHP 的运行方式。

两个漏洞的成因有所不同。

CVE-2026-109618：内存耗尽处理过程中的内存破坏。 当 PHP 处理请求时发生内存耗尽错误，部分内部数据可能尚未完成初始化，后续清理流程却错误地处理这些数据，从而引发内存破坏，并可能导致远程代码执行。
CVE-2026-109619：请求状态残留与释放后使用。 某些请求结束后，内部状态没有得到正确清理。长期运行的 Worker 进程在处理后续请求时，可能继续使用已经失效的状态，进而产生安全风险。

这类漏洞之所以危险，在于攻击者可能通过构造特定的网络请求触发问题，而不一定需要先获得网站账户。

对于直接面向互联网的 PHP 网站，尤其是使用 Apache mod_php 等受影响运行方式的服务，及时升级显得尤为重要。

版本升级对照表

根据此次漏洞对应的修复版本，相关 PHP 分支应升级至以下版本或更新的安全版本：

需要注意，PHP 8.1 及更早的部分版本已经停止官方维护。对于这些版本，应优先评估迁移至受支持版本的可行性；如果暂时无法迁移，则需要确认发行版或供应商是否提供了相应的安全补丁。

另外，操作系统仓库中的 PHP 软件包可能采用回补补丁的方式修复漏洞，因此不能只根据版本号判断是否安全，还应核对发行版的安全公告。

对于运维人员而言，最稳妥的处理方式是：先盘点所有 PHP 运行环境，再逐一确认补丁状态，而不是只升级服务器上最容易看到的那个 PHP 版本。

虽然这些年新的开发软件技术工程在逐步蚕食 PHP 的市场。

关于 PHP 的讨论似乎一直没有停止过。

随着 Node.js、Go、Python 以及各种云原生和无服务器架构的发展，PHP 在新项目中的选择不再像过去那样占据绝对优势。

但这并不意味着 PHP 已经退出历史舞台。

但得益于PHP 的快速的开发部署能力和大量的存量网站，现在还有很多的 PHP 网站，公司博客正在运行。

甚至很多公司的官方网站都是用 PHP 做的，因为他们会在WordPress 的架构上设计一套自己的模板。

对于一个访问量很少，只需要提供基础联系方式的公司网站来说，这一套系统足够用，他们并不需要高级复杂的。

虽然这些年 Node 的崛起和无服务方式的部署正在越来越流行，但是 Wordpress 提供了丰富的模板和页面渲染方式，这也是很多中小完站开发和服务商赖于生存和使用的基础架构。

根据网络技术追踪机构 W3Techs 的统计数据，PHP 目前为全球约 70% 至 77% 已知编程语言构成的网站提供底层支撑。

PHP 的应用主要还是在下面几个方面，公司网站，电商网站，教育系统（Moodle），维基百科，以及统计相关的(matomo)，在大数据处理上，PHP 就力不从心了，但又有多少人去真正做大数据的梳理呢？

很多年前，互联网行业都在说 PHP 已死，PHP 没有未来。

但是从今天这次高危漏洞的爆发，可以看到，PHH 不但没有死，还在以自己的方式为互联网信息服务提供自己加基础服务。

从技术发展的角度看，PHP 已经不再是所有新项目的默认选择。但从互联网服务的实际运行情况来看，它仍然支撑着大量网站和业务系统。

对于运维人员来说，一次高危漏洞公告，往往意味着一连串具体工作：检查版本、核对软件包来源、安排升级窗口、重启服务、验证业务，再确认没有遗漏其他运行环境。

如果服务器数量较多，或者同一台服务器上同时运行着多个 PHP 版本，排查工作可能比真正安装补丁更加耗时。

不管怎么样，先打个补丁吧。

没想到 PHP 是以这种方式刷到了存在感。