2026年10月21日，PHP官方安全团队紧急发布安全公告，披露并修复了两项严重的远程代码执行漏洞，编号分别为CVE-2026-109618和CVE-2026-109619。这两项漏洞均被评定为CVSS 4.0严重程度9.2分，安全研究人员将其统称为“PHP2Shell”。
此次漏洞影响范围广泛，涉及PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed等多种运行环境。攻击者在满足相应利用条件时，可能无需登录服务器或网站后台，就能通过网络请求触发漏洞，最终获得远程代码执行权限。
由于PHP广泛应用于WordPress、Drupal、Joomla以及大量企业网站、电商平台和在线业务系统，本次漏洞引起了全球网络安全行业的高度关注。欧洲网络安全局（ENISA）及多家安全机构已发布安全警告，建议企业尽快完成排查与修复。
PHP官方已发布8.5.12、8.4.27、8.3.36和8.2.35四个安全修复版本。对于仍在使用PHP 7.x及其他停止维护版本的网站，风险尤其值得重视。
一、PHP2Shell漏洞究竟有多严重？
PHP2Shell并不是普通的网站程序漏洞，而是发生在PHP语言运行时核心组件中的内存安全问题。
这意味着，即使网站使用的WordPress、商城系统或其他PHP应用没有直接的业务代码漏洞，底层PHP运行环境仍然可能受到影响。
此次披露的两项漏洞分别为：
- CVE-2026-109618：内存耗尽处理过程中的内存状态损坏漏洞，可能造成远程代码执行。
- CVE-2026-109619：请求处理过程中残留全局状态导致的释放后使用漏洞，可能引发内存信息泄露或远程代码执行。
两项漏洞的CVSS 4.0评分均为9.2分，属于严重级别。
成功利用后，攻击者可能以Web服务工作进程的账户权限执行恶意代码。根据服务器权限配置和应用环境，攻击者可能进一步读取网站配置文件、接触数据库连接凭据、篡改网站文件或植入恶意程序。
需要注意，严重漏洞并不代表任何攻击请求都能够成功。漏洞利用仍受PHP运行模式、内存布局、扩展组件及具体服务器配置等条件影响。
不过，安全研究人员已经证明相关漏洞具有实际远程代码执行风险，因此不能将其视为普通理论性安全问题。
二、CVE-2026-109618：内存耗尽引发远程代码执行
CVE-2026-109618与PHP处理内存不足错误时的内部机制有关。
正常情况下，PHP程序在运行过程中会使用内存。如果执行的任务超过配置的内存限制，PHP会中止相关操作，并进入错误处理流程。
但安全研究发现，在某些特定情况下，PHP可能在内部请求数据尚未完成初始化时发生内存分配失败。
随后，PHP在终止请求和清理内存时，可能错误地访问尚未正确初始化的数据，从而引发内存损坏。
攻击者如果能够通过特定请求反复触发这一状态，就可能利用内存异常实现远程代码执行。
为什么Apache mod_php风险更突出？
根据PHP官方安全公告，使用Apache mod_php运行PHP的服务器面临尤其值得关注的攻击路径。
安全研究人员已经证明，在部分默认配置下，攻击者能够通过未经身份验证的HTTP请求，在网站业务代码正式开始执行之前触发漏洞。
这意味着，单纯依靠网站程序内部的登录验证或业务安全检查，可能无法阻止相关攻击。
对于使用PHP-FPM的服务器，官方同样确认存在漏洞影响，并发现能够通过应用层代码路径触发相关风险。不过，不同运行模式下的实际利用条件并不完全相同。
因此，不能认为只有Apache服务器需要修复，也不能因为网站采用Nginx加PHP-FPM架构，就判断服务器不受影响。
三、CVE-2026-109619：请求状态残留导致内存漏洞
第二项漏洞CVE-2026-109619同样涉及PHP内部的内存管理，但具体原因与第一项有所不同。
PHP服务器在处理用户请求时，需要保存一些临时状态和内部数据。
正常情况下，请求处理完成后，相关临时数据应被清理，内部状态也需要正确重置。
但研究人员发现，在某些异常终止流程中，部分全局状态可能继续指向已经释放的内存区域。
当同一个PHP工作进程继续处理后续请求时，就有可能再次访问这些失效的数据。
这类问题通常被称为Use-After-Free，即释放后使用漏洞。
其潜在影响包括：
- 造成PHP工作进程异常崩溃；
- 读取不应访问的进程内存信息；
- 破坏程序内部数据结构；
- 在满足特定条件时执行攻击者控制的代码。
安全研究人员已经在实际PHP应用场景中演示了相关漏洞的利用过程，说明问题不仅存在于理论分析中。
四、哪些PHP版本受到影响？
根据PHP官方及Google Cloud公布的漏洞信息，本次问题影响多个PHP历史版本，涉及PHP 5.4至8.5.11范围内的未修复版本。
对于仍在官方维护周期内的版本，已经提供以下修复更新：
- PHP 8.5：升级至8.5.12或更高的安全修复版本。
- PHP 8.4：升级至8.4.27或更高的安全修复版本。
- PHP 8.3：升级至8.3.36或更高的安全修复版本。
- PHP 8.2：升级至8.2.35或更高的安全修复版本。
对于PHP 8.1及更早版本，情况则相对复杂。
这些版本已经停止获得PHP项目的常规安全更新，因此官方不会像受支持版本一样，直接发布新的完整维护版本。
考虑到此次漏洞的严重性，PHP安全团队额外提供了PHP 7.4、8.0和8.1的最小化源码回移补丁，供具备相应技术能力的用户或维护方参考。
部分Linux发行版及商业长期支持服务商，也可能针对旧版本提供经过回移修复的安全软件包。
但是，旧版本可能获得第三方回移补丁，并不代表所有旧版PHP安装都已经安全。
管理员需要确认实际运行的软件包是否包含本次漏洞修复，而不能只根据软件包名称或面板显示的版本号判断。
PHP 7.2和PHP 7.3怎么办？
对于仍在运行PHP 7.2或7.3的服务器，需要特别注意。
这两个版本早已停止官方维护，而且没有包含在此次PHP团队提供的7.4、8.0及8.1源码回移补丁列表中。
如果服务器仍然使用未经维护方修补的旧版本，就无法依靠普通的PHP版本内更新获得本次漏洞的完整修复。
推荐方案是评估业务程序兼容性，逐步迁移至已经获得安全修复且仍受维护的PHP版本。
如果暂时无法升级，应向服务器环境或软件维护方确认是否存在可信的安全回移补丁，同时采取隔离和临时风险缓解措施。
五、WordPress等网站系统是否受到影响？
由于本次漏洞存在于PHP运行时本身，因此可能影响多种依赖PHP的网站应用。
常见的PHP网站程序包括：
- WordPress内容管理系统；
- Drupal和Joomla等建站平台；
- 使用PHP开发的企业官网；
- 在线商城及会员管理系统；
- 订单、支付和账单管理平台；
- 各类PHP框架及自研Web应用。
不过，需要区分网站程序漏洞与PHP环境漏洞。
例如，某个WordPress网站即使已经更新至最新WordPress版本，只要服务器底层仍在运行受影响且未修复的PHP版本，就不能认为本次风险已经消除。
同样，升级PHP也不能替代网站程序和插件自身的安全更新。
对于长期运营的网站，应该同时维护PHP运行环境、业务程序、第三方插件和服务器系统，避免出现某一组件长期停止维护的问题。
六、Nginx、PHP-FPM及宝塔面板用户如何排查？
对于采用Nginx加PHP-FPM部署的网站，建议首先核对实际运行的PHP版本。
如果服务器支持命令行操作，可以执行：
php -v该命令可以查看当前命令行环境调用的PHP版本。
但需要注意，命令行PHP版本不一定等于网站实际使用的PHP版本。
一台服务器可能同时安装PHP 7.4、8.1、8.3等多个版本，不同网站也可能分别使用不同的PHP-FPM服务。
因此，需要进一步检查网站绑定的PHP运行环境。
使用宝塔面板的检查方法
- 登录宝塔Linux面板。
- 进入「网站」管理页面。
- 找到需要检查的网站。
- 查看该网站当前选择的PHP版本。
- 进入「软件商店」，检查对应PHP运行环境及版本详情。
- 确认已安装版本是否包含本次安全修复。
- 如需升级，先完成业务兼容性检查、备份及测试。
如果服务器运行多个网站，建议逐个核对，避免只更新其中一个站点的PHP环境。
同时，部分Linux发行版可能通过安全补丁回移方式修复漏洞，软件包显示的版本号未必发生明显变化。
这种情况下，需要查看对应发行版或软件供应商的安全公告和软件包更新记录。
如果无法确认软件包是否已修复，不应仅凭“已经是最新安装版本”就判断服务器安全。
七、如何正确修复PHP2Shell漏洞？
针对本次漏洞，PHP官方强调：安装包含对应补丁的安全版本，才是完整解决方案。
1. 优先安装官方安全修复版本
对于已经运行PHP 8.2至8.5的服务器，应优先在所属版本分支内更新到对应的安全版本，避免不必要的跨大版本迁移。
例如，正在使用PHP 8.3的企业网站，可以优先评估升级到PHP 8.3.36或更新的已修复版本，而不一定要直接切换到PHP 8.5。
这样通常更容易控制兼容性变化。
2. 旧版本网站先完成兼容性测试
如果网站使用PHP 7.x，不建议未经测试就直接切换到PHP 8.x。
PHP不同主版本之间可能存在语法、函数行为、扩展兼容性及第三方插件支持方面的差异。
对于涉及支付、订单、会员登录和自动开通服务的业务网站，建议先复制测试环境，检查核心业务功能。
确认主要功能正常后，再安排正式迁移。
3. 无法立即升级时采取临时防护
PHP安全团队同时公布了针对部分攻击路径的临时缓解措施。
这些措施包括限制HTTP请求体大小、控制上传及表单解析资源消耗，以及在适用场景下关闭PHP会话上传进度功能等。
例如，官方提出可以根据业务兼容性评估是否关闭以下配置：
session.upload_progress.enabled = 0该措施只能阻断已确认的部分攻击路径，不能防止所有利用方式。修改后需要确保配置已应用到相关PHP工作进程。
官方还提出了针对内存限制的临时缓解方法，但这类配置可能改变服务器的内存资源保护机制，不适合在不了解运行环境的情况下直接照搬。
尤其是低内存云服务器，错误调整PHP内存限制可能导致服务器资源耗尽，反而影响正常网站运行。
因此，临时缓解措施应由管理员根据服务器资源、应用需求和官方公告进行评估，不能代替安全更新。
4. 不要把CDN或WAF当作最终修复方案
使用Cloudflare、腾讯云EdgeOne及其他CDN或Web应用防火墙的站点，可以通过相关防护规则拦截部分恶意请求。
但本次漏洞发生在PHP运行时内部，仅依赖HTTP请求特征过滤，无法保证拦截所有可能的利用方式。
即使CDN厂商发布了专门的防护规则，也应继续完成服务器端的补丁修复。
对于短期无法修复、风险较高的互联网公开服务，还应根据业务重要性考虑限制外部访问，必要时暂时隔离受影响系统。
八、如何判断服务器是否已经遭到攻击？
本次漏洞披露后，安全研究人员已公开部分技术细节和概念验证研究，互联网公开PHP服务面临的攻击风险需要持续关注。
不过，漏洞存在并不代表每台受影响服务器都已经遭到入侵。
管理员可以结合以下项目开展初步排查：
- 检查Nginx或Apache访问日志中的异常请求。
- 检查PHP错误日志是否出现集中发生的内存错误、进程崩溃或异常终止。
- 核对网站目录中是否出现未知PHP脚本及其他可疑文件。
- 检查近期新增的计划任务、异常进程和不明网络连接。
- 确认关键配置文件、后台账户及数据库权限有无异常变化。
- 查看服务器CPU、内存和网络流量是否存在无法解释的异常波动。
需要说明的是，出现内存不足错误或异常请求，并不能直接证明攻击者已经成功利用漏洞。
反过来，即使日志暂时没有明显异常，也不能证明服务器绝对安全。
如果发现未知进程、异常文件修改、可疑外部连接或其他较明确的入侵迹象，应先保留相关日志和证据，再进行专业分析与处置。
对于涉及客户资料、支付数据及其他敏感业务的平台，还应进一步评估数据泄露风险，并按照实际情况采取凭据轮换、访问限制及事件响应措施。
九、生产网站升级PHP需要注意哪些事项？
对于使用云服务器运行正式业务的企业，PHP安全升级应同时考虑漏洞修复与业务连续性。
特别是长期运行的企业系统，可能依赖特定PHP版本和第三方扩展，升级过程中需要避免造成额外故障。
建议按照以下顺序进行：
- 资产排查：确认服务器上运行了哪些PHP版本，以及对应的网站。
- 确定修复方案：核对官方已修复版本或软件供应商提供的安全补丁。
- 完整备份：保存网站文件、数据库和重要配置，并确认具备恢复能力。
- 测试环境验证：检查业务系统与新PHP版本及扩展的兼容性。
- 分阶段升级：避免同时更换PHP、数据库、Web服务器和业务程序。
- 检查服务状态：确认相关PHP工作进程已经使用修复后的运行环境。
- 回归测试：验证登录、订单、支付、邮件、计划任务及其他核心功能。
- 持续观察：检查服务器日志、异常请求及资源使用情况。
对于高可用要求较高的网站，可以考虑提前准备备用环境，并在业务低峰期实施切换。
如果必须进行跨PHP主版本升级，建议安排充分的兼容性测试，保留明确的回滚方案。
需要注意，回滚到未经修复的旧版PHP虽然可能恢复网站功能，但也会重新暴露安全风险，因此应优先解决兼容问题，而不是长期依赖不安全的旧版本。
十、总结：此次PHP漏洞应优先安排安全修复
2026年10月21日披露的PHP2Shell漏洞，是一次涉及PHP底层运行环境的重大安全事件。
CVE-2026-109618和CVE-2026-109619均被评为CVSS 9.2分，攻击者在满足利用条件的情况下，可能无需身份验证就获得远程代码执行能力。
本次漏洞的特殊之处在于，它不仅影响某一个网站程序或插件，还涉及PHP自身的请求处理与内存管理机制。
PHP官方已经发布8.5.12、8.4.27、8.3.36和8.2.35安全修复版本，建议受影响用户尽快完成更新。
对于仍然运行PHP 7.x等停止维护版本的网站，管理员应尽快确认是否存在可信的维护方修复补丁，并安排向受支持版本迁移。
对于云服务器和网站运营者而言，当前最重要的是确认实际PHP版本、核实补丁状态、保护核心业务数据，并尽快完成经过验证的安全修复。
CDN、WAF、防火墙和异常流量限制可以作为辅助防护措施，但都不能代替底层PHP漏洞修复。
从长期来看，持续使用获得安全维护的软件版本、建立完善的数据备份机制，以及定期开展服务器安全检查，才是降低网站遭受攻击风险的重要基础。
官方参考资料：