近日，PHP 官方披露并修复了两个严重的安全漏洞，编号分别为 CVE-2026-109618 和 CVE-2026-109619。这两个漏洞被统称为 PHP2Shell，CVSS 4.0 评分均达到 9.2，攻击者在特定条件下无需身份验证，即可利用漏洞在目标服务器上执行恶意代码，甚至读取 PHP 进程中的敏感数据。
由于漏洞位于 PHP 运行时底层，而非 WordPress 核心、主题或插件代码中，因此所有使用受影响 PHP 版本的网站都需要重点排查。对于运行 WordPress 的服务器而言，即使网站程序和插件均已更新，也不能因此认定系统安全。
PHP 官方已于 2026 年 10 月 21 日发布修复版本。建议站长和服务器运维人员立即检查 PHP 运行环境，优先完成安全更新，并在升级后排查是否存在潜在的入侵迹象。
一、PHP2Shell 是什么漏洞？
PHP2Shell 并不是某个 WordPress 插件的漏洞，而是影响 PHP 语言底层运行时的两个高危安全问题。
根据 PHP 官方安全公告，这两个漏洞涉及内存管理异常和请求处理过程中的内部状态异常，可能导致远程代码执行。其中，CVE-2026-109618 与内存耗尽情况下的异常处理有关；CVE-2026-109619 则涉及已释放内存的再次使用等问题。
两个漏洞的主要风险如下：
- CVE-2026-109618： 在特定内存异常处理路径中，PHP 可能出现内部请求数据未正确初始化等问题，攻击者有机会利用这些异常实现远程代码执行。
- CVE-2026-109619： PHP 在异常处理过程中可能保留失效的内部状态，后续请求处理时可能再次访问已经释放的内存，从而造成远程代码执行或敏感数据泄露。
这类漏洞的危险之处在于，攻击入口可能位于 PHP 处理 HTTP 请求的底层环节。攻击者不一定需要先登录网站后台，也不一定需要利用 WordPress 本身的程序缺陷。
因此，单纯升级 WordPress 核心、停用可疑插件或更换主题，并不能修复 PHP 运行时本身存在的问题。
二、哪些 PHP 版本受到影响？
根据 PHP 官方发布的信息，PHP 5 及更高版本中的多个分支受到影响。官方已针对仍在维护的版本发布安全更新。
截至 2026 年 10 月 22 日，建议优先升级至以下修复版本或更高的同分支安全版本：
| PHP 分支 | 建议最低修复版本 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
上述版本修复了 CVE-2026-109618 和 CVE-2026-109619。对于使用 Linux 发行版软件包、托管主机或面板集成 PHP 的用户，还需要确认供应商提供的安装包是否已经包含对应安全补丁。
特别注意： PHP 8.1 及更早版本已不再获得 PHP 官方常规安全维护，但部分操作系统供应商和商业维护服务可能提供补丁回溯。因此，不能只依据版本号判断某个第三方维护的软件包是否已经修复，必须核对供应商的安全公告和补丁记录。
如果仍在使用长期未维护的旧版 PHP，建议将迁移到受支持的 PHP 分支列入近期工作计划。
三、PHP2Shell 对 WordPress 网站有什么影响？
1. WordPress 核心和插件更新并不能解决问题
WordPress 本身运行在 PHP 环境之上。如果底层 PHP 存在可被利用的漏洞，那么攻击者可能在 WordPress 正常处理请求之前触发漏洞。
这意味着，即使网站已经安装最新版本的 WordPress，所有主题和插件也都保持更新，只要 PHP 运行环境尚未修复，网站仍可能面临风险。
这与常见的插件漏洞有明显区别：插件漏洞通常需要攻击者找到特定插件的可利用代码路径，而 PHP 核心漏洞的影响范围可能覆盖不同的 PHP 应用程序。
2. 未登录攻击者也可能造成严重破坏
PHP 官方确认，这两个漏洞可能导致未经身份验证的远程代码执行。具体攻击条件会因漏洞利用路径和运行环境而有所不同，但不能假定攻击者必须先获取 WordPress 管理员账号。
一旦攻击者成功以 Web 服务进程的权限执行恶意代码，就可能进一步尝试：
- 在网站目录中植入恶意 PHP 文件或 Webshell。
- 窃取 WordPress 数据库连接信息、API 密钥及其他配置数据。
- 修改网站文件、插入恶意跳转代码或篡改页面内容。
- 利用服务器现有权限访问其他应用程序或敏感文件。
- 尝试建立持久化访问机制，方便后续再次入侵。
实际影响取决于 PHP 进程的运行权限、服务器隔离程度和其他安全配置。PHP 进程权限越大，攻击成功后可能造成的损失就越严重。
3. PHP 进程中的敏感数据也可能面临泄露风险
CVE-2026-109619 还涉及失效内存访问问题。在特定利用条件下，攻击者可能获取 PHP 进程内存中残留的数据。
这些数据可能包括数据库凭据、会话令牌、API 密钥或其他请求处理过程中使用的敏感信息。是否能够获取某一具体数据，取决于当时的内存状态和漏洞利用条件。
因此，不能只将此次事件视为网站文件被修改的风险，还应考虑凭据泄露及其后续影响。
四、WordPress 站长应该如何应急处理？
1. 第一优先级：立即升级 PHP
升级到已修复的 PHP 版本，是解决这两个漏洞的首要措施。
建议根据服务器环境采取相应操作：
- 宝塔面板用户： 检查网站实际绑定的 PHP 版本，升级到包含安全补丁的版本，并确认对应 PHP-FPM 服务已重新启动。
- Linux 命令行用户： 检查当前 PHP 软件包及其来源，通过操作系统或软件仓库提供的安全更新进行升级。
- 虚拟主机用户： 联系服务商，确认网站使用的 PHP 运行环境是否已修复。
- 容器及云平台用户： 检查容器镜像、独立 PHP-FPM 服务和平台托管的运行环境。仅升级宿主机上的 PHP，不一定会更新容器或其他独立运行时。
对于生产环境，升级前应做好文件和数据库备份，并先验证 WordPress 主题、插件及业务功能的兼容性。但对于直接暴露在互联网中的高危系统，不应因为常规维护流程而无限期推迟安全更新。
2. 确认所有 PHP 运行实例均已修复
部分服务器同时运行多个 PHP 版本，不同网站也可能绑定不同的 PHP-FPM 服务。因此，只更新其中一个版本并不意味着整台服务器已经安全。
建议逐一检查：
- 所有 WordPress 站点实际使用的 PHP 版本。
- PHP-FPM 是否存在多个独立服务或版本。
- Nginx、Apache、LiteSpeed 等 Web 服务实际连接的 PHP 处理程序。
- 容器、计划任务及命令行任务使用的独立 PHP 运行环境。
- 是否有未纳入日常管理的旧版 PHP 或第三方应用运行实例。
升级完成后，按照运行方式重启对应的 PHP-FPM、Apache 或其他长期运行的 PHP 服务，确保旧工作进程退出，修复后的代码真正生效。
可以通过以下命令查看命令行 PHP 版本：
php -v但需要注意，命令行显示的版本不一定等于网站实际使用的版本。对于宝塔面板等多 PHP 环境，还应在网站设置和对应的 PHP-FPM 服务中进行核对。
3. 无法立即升级时，采取临时防护措施
如果暂时无法完成 PHP 升级，应尽量缩短暴露时间，并根据业务情况限制风险。
可考虑以下措施：
- 在具备条件时，临时限制公网对受影响应用的访问。
- 通过 Web 应用防火墙（WAF）部署针对已知攻击路径的防护规则。
- 在反向代理或 Web 服务器层限制异常请求体大小、表单字段数量、分段数量及其他不合理的请求参数。
- 按照 PHP 官方安全公告，对特定漏洞利用路径应用临时配置缓解措施。
- 加强日志监控，并在必要时将存在较高风险的业务临时隔离。
PHP 官方特别指出，针对 CVE-2026-109619，可以在适用环境中禁用会话上传进度功能：
session.upload_progress.enabled = Off修改后，应确认配置在请求处理前生效，并重启所有相关工作进程。仅在 WordPress 代码中调用 ini_set()，或者依赖 .user.ini，不能可靠地阻止相关漏洞利用路径。
需要强调的是，这项配置只针对部分已确认的利用路径，不能覆盖全部攻击方式。
不建议将全站禁止 multipart/form-data 作为默认解决方案。 这种做法虽然可能拦截部分相关请求，却会影响 WordPress 媒体库上传、插件安装、表单提交以及 WooCommerce 文件上传等正常功能，而且不能保证彻底阻断所有利用路径。
同样，调整 memory_limit 或限制请求大小只能作为整体风险控制的一部分，不能替代 PHP 安全补丁。
4. 检查服务器是否已经遭到入侵
如果服务器在修复前已经暴露于互联网，建议在升级后开展安全检查。特别是出现异常流量、网站文件被修改、CPU 占用突然升高或未知进程等情况时，不应仅凭升级成功就认定风险已经解除。
建议重点检查以下方面。
检查异常进程
观察 PHP-FPM、Apache 或其他 Web 服务进程是否启动了不符合正常业务特征的 Shell、下载工具或其他可疑子进程。
Linux 环境可以使用以下命令辅助查看：
ps auxf注意结合进程的父子关系、运行用户和启动时间进行判断。正常的系统维护或业务任务也可能使用 Shell、curl 和 wget，不能仅凭某个进程名称就断定服务器已被入侵。
检查 WordPress 网站目录
重点检查以下位置是否存在异常文件：
wp-content/uploads/wp-content/plugins/wp-content/themes/- WordPress 根目录及其他可写目录。
关注近期新增或被修改的 PHP 文件、伪装成图片的脚本、异常的代码混淆内容，以及核心文件与官方发行版本之间的差异。
检查系统账户和计划任务
排查是否存在未知系统用户、异常 SSH 登录记录、可疑的 Cron 定时任务，以及未经授权修改的启动项或服务配置。
检查访问日志和错误日志
回溯漏洞公开前后服务器的异常 POST 请求、异常请求体、非正常错误记录及可疑的请求来源。相关日志可能不完整，因此没有发现明显攻击请求并不能证明服务器从未受到攻击。
检查并保护敏感凭据
如果有证据表明攻击者曾获得代码执行权限，建议从可信环境重置可能泄露的数据库密码、API 密钥、云服务凭据和其他重要令牌，并根据风险情况撤销现有会话。
如果确认服务器已被入侵，应优先隔离受影响实例，保留日志和必要的取证数据，再开展清理与恢复。对于高风险业务，直接从可信备份重建环境通常比仅删除几个可疑文件更加可靠。
五、升级后还需要注意什么？
完成 PHP 安全更新后，建议进一步落实以下工作：
- 保持 PHP 分支受支持。 不要长期依赖已停止安全维护的版本。
- 缩小 PHP 进程权限。 尽量避免多个不相关网站共用拥有过高权限的运行账户。
- 做好网站隔离。 限制 PHP 进程访问不属于当前站点的配置文件、密钥和其他网站目录。
- 保护数据库和密钥。 避免将敏感凭据暴露在公开目录中，并控制其读取权限。
- 建立定期更新机制。 将 PHP、操作系统、Web 服务器、WordPress 核心和插件纳入统一的安全维护流程。
- 加强异常监控。 及时发现文件变更、异常进程、可疑登录和不符合正常业务规律的请求。
对于运行多个 WordPress 网站的服务器，建议建立清晰的 PHP 版本清单，记录每个站点对应的 PHP 运行环境、软件包来源和补丁状态，避免遗漏独立运行的旧版本。
六、总结
PHP2Shell 涉及 PHP 底层运行时的两个高危安全漏洞，编号分别为 CVE-2026-109618 和 CVE-2026-109619，CVSS 4.0 评分均为 9.2。漏洞可能导致未经身份验证的远程代码执行，并在特定条件下造成敏感数据泄露。
对于 WordPress 站长来说，最重要的不是盲目更新插件，而是确认服务器实际运行的 PHP 版本，并立即应用对应的安全补丁。
如果暂时无法升级，应尽可能限制公网访问，结合 WAF、请求限制和 PHP 官方建议的临时缓解措施降低风险，同时尽快完成修复。对于已经暴露在互联网中的服务器，还应排查潜在入侵迹象，必要时重置敏感凭据并从可信环境恢复业务。
安全建议：立即检查所有 WordPress 网站的 PHP 运行环境，升级至已修复版本，并确认所有相关工作进程均已重新加载安全补丁。