适用对象：任何在 PHP 上运行网站的人（自有服务器、VPS、云、Docker 或共享主机），以及使用 WordPress、Laravel、EC-CUBE 等构建网站的人。本文基于 PHP 安全团队的官方公告，以及公共机构和服务商的声明。本文不涉及任何攻击方法。
持续更新中：本页面将随着更多信息发布而更新
截至 2026年10月25日（JST）；主机服务商和操作系统软件包信息截至 2026年10月23日 02:15 UTC尚不清楚
- 第三个问题 CVE-2026-115560 的受影响版本、CVSS 评分和修复版本（将随下一个常规版本发布）
- 野外利用情况（官方观点）以及是否发生过入侵
- 其余操作系统软件包分支（RHEL 9 php:8.4、Debian testing forky）
- 尚未宣布完成的主机服务商（KAGOYA、对无修复版本的版本采取措施的 CPI、PHP 5.5 及更早版本的 Xserver 等）
PHP 安全团队于10月21日发布了修复，日本 IPA 与 JPCERT/CC 于10月22日发布了警报。日本大多数主要共享主机服务商已宣布修复已应用。多家公司观察到了利用尝试，但尚未宣布确认的入侵事件。10月23日，披露了第三个问题（CVE-2026-115560），修复版本并未涵盖该问题。PHP 团队称其实际中不太可能发生，但建议在下一个常规版本发布前设置 session.upload_progress.enabled=0。随着其余操作系统软件包和服务商的情况得到确认，本页面将会更新。
修复版本与漏洞（来自 php.net）
2026年10月21日，PHP 安全团队在 php.net 上发布了安全公告（“严重远程代码执行漏洞，请立即更新”），并公布了各分支的修复版本。
- 修复版本
- PHP 8.5.12、8.4.27、8.3.36、8.2.35
- CVE-2026-109618
- 内存不足时的处理可能会在 PHP 内部请求数据只被部分初始化时中断运行，之后请求清理可能会将无效数据视为有效。可导致远程代码执行（RCE）
- CVE-2026-109619
- 请求所属的内部状态在其底层内存被释放后仍可能残留，同一工作进程处理的后续请求可能会在初始化重置之前使用该过期状态。可导致远程代码执行（RCE）
- 严重程度
- 两者 CVSS v4.0 均为 9.2
- 风险对象
- 所有提供网页请求服务的 PHP 安装（PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed）。mod_php 风险最高，已演示的利用方式是未经认证的请求会在任何应用代码运行之前触发攻击
- 8.1 及更早版本
- PHP 项目未发布更新。为 7.4、8.0 和 8.1 提供了最小化的源码回移补丁
- 发行版
- Linux 发行版和 LTS 供应商已提前获得补丁；请向供应商确认更新的软件包
- 缓解措施
- 没有完整的缓解措施；更新是唯一安全的选择（如果暂时无法更新，临时措施见下方方框）
暂时无法更新时的临时措施（来自公告；这些措施不能使您安全）
PHP 团队列出了在您能够更新之前可降低特定攻击路径风险的设置，但表示其中任何一项都无法使安装变得安全。主要包括：检查 memory_limit 以及 post_max_size 等请求大小限制，禁用 session.upload_progress.enabled 并重启工作进程，以及在 PHP 8.5 上禁用 fatal_error_backtraces。这些条件很重要，因此在更改任何设置之前，请先阅读官方公告，并优先完成更新。
发布版本未修复的第三个问题（CVE-2026-115560，10月23日披露）
2026年10月23日，PHP 安全团队在 php.net 上发布了“信息性公告：会话上传进度”，披露了10月21日版本未修复的一个问题。该问题与两个严重漏洞是分开的。
- CVE
- CVE-2026-115560。完整公告将随下一个版本发布（截至10月25日，CVE 记录和 NVD 尚无条目）
- 条件
- 只有异常的配置与应用代码组合会受影响：配置将 session.serialize_handler 设为 php_binary 或 php_serialize，应用在调用 session_start() 之前通过 ini_set() 在运行时将其切换为 php，并且会话上传进度（session.upload_progress）仍处于启用状态。从不在运行时更改序列化处理器的应用可以保持该功能启用
- 影响
- 可导致远程代码执行（RCE）。该团队称这种设置“实际中不太可能”
- 缓解措施
- 在下一个常规版本发布前设置 session.upload_progress.enabled=0。10月21日公告中已将同一设置列为 CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）的缓解措施；如果您当时已应用，请保持不变，无需进一步操作
- 修复
- 由于该设置情况不太可能出现，该问题将纳入常规发布周期，修复和完整公告将在下一个版本中发布。未给出具体日期
- 尚未公布
- 受影响版本和 CVSS 评分
- 利用情况
- PHP 团队的公告未提及利用情况
发布之后（截至 2026年10月23日 02:15 UTC）
- 发布时间
- GitHub 安全公告约于 13:34 UTC（22:34 JST）发布，比 14:00 UTC 的计划时间提前约30分钟
- 受影响版本
- 根据 GitHub 官方公告，受影响的是 8.2.35、8.3.36、8.4.27 和 8.5.12 之前的版本。CVE 记录列出的是 8.2 至 8.5，未提及 8.1 及更早版本（该团队为 7.4、8.0 和 8.1 提供了源码修复）
- 已确认的影响（来自公告）
- CVE-2026-109618：已在 mod_php 上确认未经认证的远程代码执行；根据源码分析，PHP-FPM 可能也受影响，但尚未演示完整利用。CVE-2026-109619：已在 mod_php 上确认远程代码执行；在 PHP-FPM 上也通过会话上传进度路径得到验证，这取决于应用中是否有合适的操作
- 日本公共机构
- 10月22日，IPA 发布了“PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)”（日文，《关于 PHP 漏洞的应对措施》），是其10月21日预先通知的后续。它请用户更新至修复版本（8.2.35、8.3.36、8.4.27、8.5.12）。对于已停止支持的 8.1 及更早版本，它要求用户迁移到受支持的 PHP，或迁移到已修复的产品或服务。如果难以采取有效的临时措施，它要求组织判断是否需要阻断外部访问或临时停止服务。它还引用了参与研究的一家安全公司的观点，认为 PHP 5.4 及更高版本至少受其中一个漏洞影响（这是该公司的观点，并非 PHP 团队的声明）。同日，JVN 于 10:30 JST（01:30 UTC）发布了 JVNVU#99905564，要求用户应用补丁。JPCERT/CC 同日发布了警报（JPCERT-AT-2026-0033），敦促及时更新并检查入侵迹象。该警报还列出了检查入侵时应关注的内容
- CISA
- CISA 于10月21日发布了警报，敦促组织立即打补丁。其中称“截至发布时，尚未观察到对这些漏洞的利用”。它告诉无法立即更新、或仍在运行 PHP 8.1 或更早版本的组织，在能够打补丁或更新之前，应将基于 PHP 的系统下线。这些漏洞未列入已知被利用漏洞目录（10月21日版）
- 野外利用
- PHP 团队未发表声明，CISA 表示截至其发布时尚未观察到利用行为。CVE 记录中 CISA 添加的利用评级在10月22日更新后仍为“无”。一家大型云服务商的威胁情报团队于10月21日表示，其蜜罐在披露前四天，即10月17日，看到了一次利用尝试（原文）。该服务商称这些漏洞“现在正在野外遭遇广泛的利用尝试”，但“尚不清楚这些尝试中是否有任何一次会在真实系统中成功”。它建议至少从10月17日起展开调查。一家 CDN 服务商和多家安全公司也报告观察到攻击或探测流量（CDN 服务商、新闻综述）。另一家安全公司在10月22日的更新中表示，公开的利用代码无法在默认 PHP 安装上运行，大规模利用的可能性低于其最初预期。在日本，Lolipop 和 Heteml 于10月22日表示，它们看到了似乎针对这些漏洞的访问，但迄今尚未确认由此产生的任何未经授权访问或数据泄露。截至 2026年10月23日 02:15 UTC，尚未宣布确认的入侵事件
- 操作系统软件包
- Ubuntu 为所列的 26.10、26.04、24.04 和 22.04 版本提供修复。20.04 和 18.04 的修复需要 Ubuntu Pro；16.04 和 14.04 需要其 Legacy Support 附加组件（USN-8948-1、USN-8948-2）。Debian 已修复 13（DSA-6574-1）和 12（DLA-4848-1）；sid 已提供修复版 8.4.27-1，而 testing（forky）仍为未修复的 8.4.26-1。Red Hat 已修复多个 RHEL 8–10 分支（评级为 Important，access.redhat.com），并于10月21日新增了 RHEL 8 php:8.2（RHSA-2026:87073）。RHEL 9 php:8.4 仍无修复（10月22日更新中为“受影响”）。RHEL 6 标记为“超出支持范围”且无计划修复，RHEL 7 受 CVE-2026-109619 影响但尚无修复。Alpine 已修复 8.5、8.4 和 8.3。如果 PHP 来自操作系统软件包，请立即应用供应商的更新
- Docker 官方镜像
- latest、8.5、8.4、8.3 和 8.2 标签（包括 -apache 和 -fpm 变体）均已指向修复版本（8.5.12、8.4.27、8.3.36、8.2.35）（hub.docker.com）。已停止支持的 8.1 及更早版本标签尚未更新。只有在您重新拉取镜像并重建容器后，修复才会生效
- NVD
- NVD 对两者给出的评分为 CVSS 3.1 9.8（Critical）；PHP 团队的评分为 CVSS v4.0 9.2（nvd.nist.gov）
- 修复不完整的说法
- 一个漏洞邮件列表上的帖子称 8.5.12 的修复“可能不完整”。PHP 安全团队公告的发布者于10月22日（09:11 UTC）在同一列表中回复，称这是“一个与之无关、影响极小的问题”（在不太可能的场景下某个组件崩溃），并且“与 RCE 无关”（回复）。php.net 上的公告未作更改
- Windows
- 已提供修复版本的 Windows 构建
- remirepo
- PHP 团队表示，由志愿者运营的 rpms.remirepo.net 今天不会提供更新，并敦促改用发行版软件包或从源码构建
预先通知（10月20日）
前一天，即2026年10月20日，PHP 安全团队在 php.net 上发布了题为“即将发布的严重 PHP 安全版本”的通知，内容如下。
- 发布时间
- 2026年10月21日（星期三）14:00 UTC（日本时间23:00）
- 范围
- 两个严重漏洞
- 严重程度
- 两者在 CVSS v4.0 下均评为 9.2
- 请求
- 鼓励所有 PHP 用户现在就做好准备，以便在版本发布后立即升级
- 提前发布
- 如果任一漏洞的细节公开，或出现正在进行的利用证据，团队可能会提前发布
- 尚未公布
- 完整细节、受影响版本和修复版本，均将随版本发布
- 当时的最新版本
- 8.5.11、8.4.26、8.3.35 和 8.2.34（2026年9月24日的安全版本）
CVSS 以 0 至 10 分衡量漏洞的严重程度，9.0 或以上属于最高的“严重（Critical）”级别（参见什么是 CVSS）。日本 IPA 还于10月21日发布了“请提前做好准备”的通知，要求组织盘点使用 PHP 的程序。IPA 指出，PHP 不仅可以在网络应用中运行，也可以在软件产品和网络设备内部运行。
谁来更新 PHP：取决于您的部署方式
任何运行在 PHP 上的站点都可能受影响，但实际由谁更新 PHP 因环境而异。搞错这一点会导致“我以为服务商已经更新”或“我更新的 PHP 与服务网站的 PHP 不是同一个”之类的疏漏。
自有服务器、VPS、云
由您更新（升级软件包，然后重启）
Docker（官方镜像）
新标签发布后由您重建
发行版软件包（Debian、Ubuntu、RHEL 等）
发行版回移修复，由您应用。版本号与上游不同
共享主机
由服务商更新 PHP。您需要检查所选的版本
| 环境 | 谁更新 PHP | 您需要做什么 |
|---|---|---|
| 自有服务器、VPS、云服务器 | 您 | 安装修复版本（或发行版的修复包），并重启 PHP-FPM 或 Apache |
Docker 官方镜像（php:8.4-fpm 等） | 镜像维护者和您 | 修复标签发布后，拉取该镜像，重建您的镜像并替换容器。不要复用缓存的旧基础镜像 |
| 发行版软件包（Debian、Ubuntu、RHEL 系列） | 发行版和您 | 查看发行版的安全通知，获取修复包并应用。发行版只回移修复，因此其版本号与 PHP 上游版本号不一致 |
| 共享主机 | 服务商 | 在控制面板中检查每个站点的 PHP 版本；如果是 8.1 或更早版本，请规划切换；并在服务商官网查看通知 |
| 嵌入产品或设备中的 PHP | 供应商 | 查看供应商的安全通知（您可能无法看到其中的 PHP） |
WordPress 或 Laravel 中的更新按钮不会更新 PHP 本身。更新您的应用和更新 PHP 是两项独立的工作。
如何安全地检查您的 PHP 版本
如果您能登录服务器，使用命令行
如果您有 shell 访问权限，可以使用此命令查看 PHP 版本。
php -v不过，这是命令行（CLI）PHP 的版本。为您网站提供服务的 PHP（PHP-FPM 或 Apache 模块）可能是另一个版本。一台服务器同时安装 8.2 和 8.4 的情况很常见。请使用以下方法或通过 PHP-FPM 服务名（例如 php8.4-fpm）检查 Web 端。
在 WordPress 中使用站点健康
在 WordPress 后台打开“工具”，然后打开“站点健康”，选择“信息”标签，并展开“服务器”。它会显示实际运行该站点的 PHP 版本，因此任何拥有管理员权限的人无需登录服务器即可检查。
在共享主机上使用控制面板
在共享主机上，控制面板的 PHP 版本设置会显示为每个域名选择的版本。许多服务商允许您为每个域名选择不同版本，因此请检查每一个域名。
不要在线保留 phpinfo() 页面
查看版本的一种方法是在公共目录中放置一个调用 phpinfo() 的文件，但该页面会列出 PHP 的版本、配置和内部服务器详情。这会为攻击者提供有用的目标信息，因此用完后请立即删除。如果上述三种方法已足够，就不要创建它。如何查找被遗忘的文件，参见公共目录中遗留的机密文件。
更新之前
列出您的站点和服务器
对于每个站点，请在一张表中记录：它所在的服务器、PHP 版本（CLI 和 Web 端）、由谁更新 PHP（您、服务商或承包商）以及负责人的联系方式。包括预发布站点以及仍然公开可访问的被遗忘站点。被遗忘的站点往往会错过更新。方法参见安全资产清单检查表。
做好备份
备份文件和数据库，以便在更新导致站点故障时可以回滚。将备份存放在服务器之外，并确认可以还原（备份与恢复基础）。
设定维护窗口和步骤
确定更新时间（包括深夜时段）、由谁执行，以及如何通知相关人员。对于您自己的服务器，请写下更新命令、需要重启的服务以及如何确认结果。如果承包商或代理机构管理服务器，请今天确认由谁在何时更新。
对于已停止支持的分支，规划迁移
据 php.net 显示，PHP 8.1 的支持已于2025年12月31日结束，8.0 及更早版本也是如此。根据 PHP 项目的支持政策，已停止支持的分支不会获得安全版本。这次同样没有发布官方版本（仅为 7.4、8.0 和 8.1 提供最小化的源码回移补丁）；请规划迁移到受支持的版本，即 8.2 至 8.5。8.2 的安全支持也将于2026年12月31日结束，因此如果您现在迁移，8.3 或更高版本是更稳妥的目标。
不要急于使用未经官方认可的“修复”插件或配置变通方法
在修复发布之前，往往会流传一些声称可以阻止该问题的非官方插件和配置更改。未出现在官方公告中的方法无法得到验证。唯一真正的修复是 PHP 的修复版本（或您发行版的修复包）。WAF（Web 应用防火墙）规则可以争取时间，但对于绕过 WAF 直接到达服务器的流量则无效。
更新至修复版本
修复版本为8.5.12、8.4.27、8.3.36 和 8.2.35（2026年10月21日发布）。如果您通过操作系统软件包安装 PHP，请使用发行版提供的更新包。
升级到您所在分支的修复版本
请查看 php.net 的发布公告和 ChangeLog，确认您所在分支（8.2、8.3、8.4 或 8.5）的修复版本，并更新到该版本或更高版本。如果您使用发行版软件包，请查看发行版的安全通知（Debian、Ubuntu、Red Hat 等），确认修复包版本。对于 Docker，请在修复标签发布后拉取并重建。
重启 PHP-FPM 和 Apache
升级软件包不会改变已经在运行的 PHP 进程。请重启 PHP-FPM（例如 php8.4-fpm），或者如果您使用 Apache 的 PHP 模块，请重启 Apache，以加载新的 PHP。
检查第三个问题（CVE-2026-115560）的会话设置
即使您已升级到10月21日的版本，此问题依然存在。请检查两项内容。
- 配置（php.ini 等）是否将 session.serialize_handler 设为 php_binary 或 php_serialize，且应用代码是否通过 ini_set() 将其切换为 php（在代码中搜索
session.serialize_handler是快速查找的方法） - session.upload_progress.enabled 是否仍处于开启状态（默认即为开启；命令行的
php -i结果可能与 Web 端不同，因此也请检查 PHP-FPM 池和为站点提供服务的 PHP 配置）
如果两者都符合，或者您无法判断，请在下一个常规版本发布前设置 session.upload_progress.enabled=0。请在启动时读取配置的位置进行设置，例如 php.ini、PHP-FPM 池或 Web 服务器配置，并重启每一个工作进程（10月21日公告称应管理性地设置 session.upload_progress.enabled=0，并重启每一个工作进程）。该功能用于显示文件上传进度；如果您的站点显示上传进度，请在设置后确认其仍能正常工作。如果您已根据10月21日公告将其作为临时措施禁用，请保持不变。在日本的共享主机中，Heteml 和 Lolipop 已禁用该功能。
在 CLI 和 Web 端确认版本
除 php -v 外，请使用 WordPress 站点健康或 PHP-FPM 服务状态，确认为网站提供服务的 PHP现已为修复版本。如果服务器安装了多个 PHP 版本，请逐一检查。
检查站点运行正常且没有异常
检查关键页面、登录、联系表单和支付功能。如果您担心站点在修复前已遭攻击，请查找未知文件、多余的管理员账户和页面篡改迹象。一家大型云服务商在披露前四天，即10月17日，看到了利用尝试，并建议至少从该日期起展开调查。JPCERT/CC 的警报也列出了需要检查的内容。如何检查，参见如何检查您的网站或服务器是否被入侵。
共享主机用户须知
在共享主机上，服务商在服务器上安装并管理 PHP。用户无法自行安装修复版本。
服务商负责的工作
- 将服务器上安装的 PHP 更新为修复版本
- 如有需要，应用临时防护或紧急维护
- 在官方网站和社交媒体上发布状态更新
您需要做的
- 在控制面板中检查为每个域名选择的 PHP 版本
- 如果是 8.1 或更早版本，请测试后切换到较新的版本
- 在官方网站上查看服务商通知，而不是通过邮件链接
- 同时保持 WordPress 核心、插件和主题为最新版本
服务商侧的紧急维护可能会使控制面板暂时无法使用。请提前完成检查，以免在该时段内因需要切换 PHP 版本而陷入被动。
服务商的应对情况（本站确认，截至 2026年10月23日 02:15 UTC）
许多服务商表示已完成修复的应用。截至 2026年10月23日 02:15 UTC（日本时间 11:15），KAGOYA 尚未宣布完成。CPI 要求使用无修复版本的客户采取缓解措施，或切换到已打补丁的版本。未发现 Rakko Server 或 WADAX 有关 PHP 的通知。以下时间均为 JST。
| 服务商 | 官方通知 | 内容 |
|---|---|---|
| Xserver（日本） | 为预防安全而临时暂停官方网站和控制面板的通知（截至 10月22日 20:10 的状态，日文） | 对其提供的每个 PHP 版本应用了官方修复或自有修复。10月22日 06:45 完成了 PHP 8.2–8.5 在所有目标服务器上的应用，12:00 完成 7.4–8.1，14:00 完成 5.6–7.3。PHP 5.5 及更早版本的补丁仍在“制作和验证中”。自 20:10 起，其服务站点已依次重新开放；官方网站、控制面板、网页邮件、API/MCP 和联系表单已恢复（部分功能，如旧版网页邮件，仍在维护中）。根据用户使用情况，可能会要求部分客户采取进一步的步骤。该公司称此次措施并非由未经授权的访问引起 |
| Sakura Rental Server（日本） | PHP 漏洞应对状况（10月22日，日文） | 已对控制面板中可选的每个 PHP 版本应用修复；无需客户紧急操作。同时建议迁移到最新的受支持 PHP。部分服务使用的网页邮件已于10月22日 13:45 恢复，phpMyAdmin 于 15:15 恢复（维护通知）。10月21日起的紧急维护（n-2697）于10月21日 22:30 结束 |
| mixhost（日本） | 【已完成】针对 PHP 严重漏洞的应对（10月22日，日文） | 约于10月22日 10:18 在所有服务器上应用了修复包，涵盖 PHP 5.2–8.5。版本号不变（例如 8.4.26 仍为 8.4.26）。无需客户操作。10月21日 22:10 起的 My Page 维护也已结束 |
| ColorfulBox（日本） | 通知（10月22日，日文） | 预先防护和升级至修复版本已于10月22日上午在所有服务器（共享、商业、Tada Server 和独立服务器）上完成，包括 7.4、8.0 和 8.1。采用原地更新，保留您所用的 PHP 版本；无需客户操作 |
| XREA、VALUESERVER、CORESERVER、One Rental Server（日本） | XREA、VALUESERVER、CORESERVER V1 / V2、One（日文） | 五项均已完成。XREA、VALUESERVER 和 CORESERVER V1 于10月22日 00:50 完成，其更新通知称所提供的每个 PHP 版本（5.3–8.5）均已修复。One Rental Server 于 10:20 完成（5.6–8.5），CORESERVER V2 于 11:13 完成（5.2–8.5）。用户无需更改 PHP 版本 |
| Heteml（日本） | PHP 漏洞维护已完成及经过说明、【已完成】维护通知（10月22日 18:05，日文） | 客户站点于10月22日 11:24 恢复，所有服务于 18:05 全部恢复。PHP 8.2–8.5 获得官方修复版本，7.4、8.0 和 8.1 获得 PHP 团队针对已停止支持分支的修复，5.6–7.3 获得服务商基于官方修复制作的自有修复。在所有版本上，此措施都会禁用一项功能（session.upload_progress），并要求客户检查站点是否正常运行，并迁移到 8.2 或更高版本。在修复应用之前，自10月22日约 03:05 起，部分服务器上的站点已被停止 |
| Lolipop（日本） | PHP 漏洞维护已完成及经过说明、【已完成】维护通知（10月22日 16:57 更新，日文） | 客户站点于10月22日约 13:00 恢复，所有维护于 16:57 完成。PHP 8.2–8.5 获得官方修复版本，7.4、8.0 和 8.1 获得 PHP 团队针对已停止支持分支的修复，5.3–7.3 获得服务商基于官方修复制作的自有修复。所有版本上都禁用了一项功能（session.upload_progress），并要求客户检查站点并迁移到 8.2 或更高版本。在修复应用之前，自10月22日约 03:09 起，部分服务器上的站点已被停止 |
| KAGOYA（日本） | PHP 漏洞对其服务的影响（10月22日 18:15 更新，日文） | 对于其租赁服务器（PHP 7.4 和 8.1–8.5），称升级至修复版本正在进行中，预计于10月22日 24:00 完成。截至10月23日 11:15，尚未发现完成通知。对于托管独立服务器、共享主机和 WordPress 方案，永久修复仍在安排中，并要求客户考虑将站点下线（切换到维护页面）或限制访问作为临时措施。其 10:35 的更新称，尚未确认攻击或数据泄露等损害。自10月22日 14:15 起，它还对网页邮件、会员站点和控制面板进行了安全维护，未给出结束时间 |
| ConoHa WING（日本） | PHP 漏洞应对已完成（最终报告）（10月22日，日文） | 截至10月22日 20:45，所有服务器均已应用安全补丁，紧急维护也随之结束。补丁以只接收修复的方式应用于所提供的每个 PHP 版本，未提升版本号，因此 WordPress 站点健康等界面可能仍显示旧版本号（例如 8.5.11）。客户无需更改版本。网页邮件和文件管理器约于 18:30 恢复，phpMyAdmin 也已恢复 |
| Onamae.com Rental Server（日本） | PHP 漏洞应对已完成（10月22日，日文） | 与 ConoHa WING 内容相同：截至10月22日 20:45 已应用补丁（Basic、RS Plan 和 AI Homepage Pack）。仅对所提供的每个 PHP 版本应用修复，因此显示的版本号可能未变。客户无需更改版本。网页邮件和文件管理器约于 18:30 恢复，phpMyAdmin 也已恢复 |
| CPI（日本） | 关于因 PHP 漏洞暂停服务站点和控制面板的通知（10月23日 09:55 更新，日文） | 有最新补丁的版本已完成（例如 SV-Basic 上的 8.2 和 8.3，Business Standard 上的 8.2–8.4）。对于其他版本，要求客户考虑应用缓解措施并切换到已打补丁的 PHP 版本（旧方案上则考虑应用缓解措施）。服务站点于10月22日 21:00 重新开放，控制面板约于 17:00 重新开放；安全文件管理器和其他部分工具预计在10月30日之后恢复。称尚未确认未经授权的访问，也未确认利用这些漏洞的攻击 |
| Rakko Server（日本） | 官方网站（日文） | 其服务站点于10月21日 19:00 起作为预防措施停止（称未发现未经授权的访问）。该站点已恢复，但截至10月23日 11:15 未发现有关 PHP 的通知 |
| WADAX（日本） | 官方网站（日文） | 10月22日查看时，整个站点因安全原因被暂停，直至确认安全为止。截至10月23日 11:15，网站已恢复，但未发现有关 PHP 的通知 |
各服务商的完成通知措辞不同。请查看您服务商的通知，了解涵盖哪些 PHP 版本，以及您是否需要采取任何行动。部分服务商，如 ConoHa WING、Onamae.com 和 mixhost，只接收了修复，因此 PHP 版本号不会改变。不要仅凭版本号判断站点是否未打补丁；请查看服务商的通知。其他服务商的通知在确认后将补充。
提防假冒您主机服务商的钓鱼邮件
当漏洞或紧急维护成为新闻时，声称来自主机或域名服务商的虚假邮件（“请重新登录以进行紧急维护”“您的账户将被暂停”）会变得更加常见。请不要通过邮件中的链接登录。请通过您自己收藏的官方网站或服务商的官方社交媒体账号进行核实。如何识别这类邮件，参见什么是钓鱼。关于如何应对服务商自身遭入侵，参见当您的主机服务商遭入侵时。
发布前的报道
2026年10月21日的官方公告确认了 CVE 编号（CVE-2026-109618、CVE-2026-109619），以及两者均为远程代码执行（RCE）漏洞。下表显示了发布前的报道内容；野外利用情况仍未得到官方确认。
发布前，媒体和安全公司传播了若干说法。这些都不是 PHP 安全团队的官方声明。本站没有因这些说法而更改建议的步骤。
| 说法 | 来源 | 状态 |
|---|---|---|
| 漏洞细节在预定发布前泄露 | 一家安全公司（向新闻媒体发表的言论） | 未经确认 |
| 两者均为远程代码执行（RCE）漏洞 | 安全公司，以及 CERT-EU（欧盟机构的 CSIRT） | 已由10月21日公告确认 |
| CVE 编号（CVE-2026-109618、CVE-2026-109619） | 安全公司、媒体、CERT-EU | 已由10月21日公告确认 |
| 从 PHP 5 起的广泛版本均受影响 | 安全公司、CERT-EU | 未经确认（GitHub 公告涵盖每个修复版本之前的版本，未说明下限；为 7.4/8.0/8.1 提供了回移补丁）。IPA 10月22日的警报引用参与研究的一家安全公司的说法，称 PHP 5.4 及更高版本受影响 |
| 未观察到利用 | 一家安全公司（向新闻媒体发表的言论） | 该来源自身的观点 |
| 观察到攻击迹象 | 一家 CDN 服务商的高管、另一家安全公司（引用托管合作伙伴的报告），以及一家大型云服务商 | CDN 服务商在其 13:56 UTC 的帖子中称观察到攻击流量，一家大型云服务商称其自10月17日起看到了利用尝试（参见“发布之后”）。尚无公共机构确认 |
各来源对利用情况的看法有所不同。IPA 在10月21日的预先通知中表示，当时尚未确认针对这些漏洞的攻击。CISA 也在10月21日的警报中表示，截至发布时尚未观察到利用。另一方面，一家大型云服务商称其在披露前的10月17日看到了一次利用尝试。无论利用是否已经开始，应对措施都是相同的：立即更新至修复版本。
本站观点：今天需要决定的是由谁更新，以及何时更新
修复版本已经发布。剩下的是决定由谁在何时更新，并付诸行动。常见的缺口往往不在技术层面，而在于责任归属。机构搭建的网站、已离职的人员设置的 VPS、无人记得的测试服务器：没有明确负责人的 PHP，往往是保持过期时间最长的。如何判断严重程度，参见如何对漏洞排序（CVSS、EPSS、KEV）；披露后的步骤参见漏洞发布后应该怎么做。
时间线
2026年9月24日
PHP 8.5.11、8.4.26、8.3.35 和 8.2.34 作为安全版本发布（当时的最新版本）。10月17日（10月21日公布）
一家大型云服务商的蜜罐在披露前四天看到了一次利用尝试。10月20日
PHP 安全团队在 php.net 上宣布将于10月21日 14:00 UTC 发布安全版本。两个漏洞在 CVSS v4.0 下均评为 9.2。同日，据报道一家安全公司向新闻媒体表示细节已泄露。10月21日
IPA 发布“请提前做好准备”的通知。Xserver 自 16:00 JST 起暂停其官方网站和控制面板的访问。10月21日
PHP 安全团队发布 8.5.12、8.4.27、8.3.36 和 8.2.35 以及安全公告。公告称 CVE-2026-109618 和 CVE-2026-109619 均可能允许未经认证的远程代码执行，并敦促所有人立即更新。10月21日
CISA 发布警报，敦促立即打补丁，并表示截至发布时尚未观察到利用。10月22日
Xserver（8.2–8.5）、Sakura、mixhost、ColorfulBox、Value Domain 集团服务、Heteml、Lolipop 等宣布已应用修复。JVN 发布 JVNVU#99905564，IPA 发布关于 PHP 漏洞应对措施的警报，JPCERT/CC 发布警报（JPCERT-AT-2026-0033）。10月22日（晚间，JST）
ConoHa WING 和 Onamae.com 表示截至 20:45 JST 已应用补丁。Xserver 于 14:00 JST 前完成 PHP 5.6–8.5，并于 20:10 JST 起重新开放其官方网站。KAGOYA 表示预计其租赁服务器于 24:00 JST 完成。10月23日
PHP 安全团队披露了第三个问题（CVE-2026-115560），该问题未被10月21日的版本修复。团队称该问题实际中不太可能发生，并建议在下一个常规版本发布前设置 session.upload_progress.enabled=0。
来源（公开记录）
本文的事实基于以下公开信息。PHP 未官方公布的内容（如野外利用）已归属于媒体或安全公司，并标注为未经确认。
- PHP 安全团队，“安全公告：严重远程代码执行漏洞，请立即更新”（2026年10月21日）— php.net
- PHP 安全团队，“信息性公告：会话上传进度”（CVE-2026-115560，2026年10月23日）— php.net
- CVE-2026-109618 的 GitHub 安全公告 — github.com
- CVE-2026-109619 的 GitHub 安全公告 — github.com
- ChangeLog（8.5.12、8.4.27、8.3.36、8.2.35）— php.net
- PHP，“即将发布的严重 PHP 安全版本”（2026年10月20日）— php.net
- PHP 首页（当时的最新版本：8.5.11、8.4.26、8.3.35、8.2.34）— php.net
- PHP，“受支持的版本” — php.net
- PHP，“不再支持的分支”（8.1 停止支持日期：2025年12月31日）— php.net
- php-src 安全公告（GitHub）— github.com
- IPA，关于为 PHP 安全版本提前做好准备的通知（2026年10月21日，日文）— ipa.go.jp
- IPA，“PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)”（2026年10月22日，日文）— ipa.go.jp
- JVN，关于允许任意代码执行的多个 PHP 漏洞的 JVNVU#99905564（2026年10月22日，日文）— jvn.jp
- JPCERT/CC，关于多个 PHP 漏洞的警报（CVE-2026-109618、CVE-2026-109619）（JPCERT-AT-2026-0033，2026年10月22日，日文）— jpcert.or.jp
- CISA，“Critical Vulnerabilities in PHP Require Immediate Patching”（2026年10月21日）— cisa.gov
- Xserver Inc.，为预防安全而临时暂停的通知（2026年10月22日；截至 20:10 JST 的状态，日文）— xserver.ne.jp
- 一家大型云服务商的威胁情报团队：披露前自10月17日起的利用尝试（2026年10月21日）— aws.amazon.com
- PHP 安全团队开发者对“修复不完整”说法的回复（2026年10月22日）— openwall.com
- 主机服务商的完成通知：ConoHa WING / Onamae.com / Lolipop / Heteml（均为2026年10月22日，日文）
- CERT-EU，“Security Advisory 2026-018: Critical Vulnerabilities in PHP”（未经确认说法的来源）— cert.europa.eu
- 媒体报道：一家安全公司对泄露的说明及其未观察到利用的观点（BleepingComputer，2026年10月20日）— bleepingcomputer.com
- 媒体报道：第三个问题（CVE-2026-115560）的缓解措施（BleepingComputer，2026年10月23日）— bleepingcomputer.com
- 安全公司警报：来自托管合作伙伴的攻击报告（2026年10月21日）— patchstack.com
- CDN 服务商高管的帖子：早期攻击与 WAF 规则（2026年10月21日；上述警报中引用）— x.com
- 安全公司快速响应：合作伙伴系统上未观察到野外利用（截至2026年10月21日）— huntress.com
- 安全公司分析文章（报告的 CVE 编号、类型和范围）— sansec.io / tenable.com
- 发行版安全通知：Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com（RHEL 8 php:8.2：RHSA-2026:87073）
- Docker 官方镜像（php）— hub.docker.com
更新记录
2026-10-25：添加了 PHP 安全团队于10月23日披露的第三个问题（CVE-2026-115560，未被10月21日版本修复）：其条件、缓解措施（session.upload_progress.enabled=0）和计划中的修复，以及供管理员检查设置的步骤。更新了摘要、状态框、FAQ、时间线和来源。
2026-10-23（02:15 UTC）：添加了一家大型云服务商关于自10月17日起利用尝试的报告（不清楚是否有任何尝试成功），日本服务商关于似乎针对这些漏洞的访问的报告（未确认损害），以及尚未宣布确认的入侵事件；添加了自10月17日起检查日志的建议。添加了 PHP 安全团队开发者关于“修复不完整”报告与此无关的回复。更新了操作系统软件包（Debian sid 已修复，RHEL 9 php:8.4 仍未修复，RHEL 6 无修复计划）和主机状态（ConoHa WING、Onamae.com、Lolipop 和 Heteml 已完成；Xserver 完成了 PHP 5.6–7.3；Value Domain 集团服务涵盖的版本；KAGOYA 和 CPI 的状态）。
2026-10-22（04:45 UTC）：将标题改为重大新闻格式，并添加了 IPA 警报、JPCERT/CC 警报（JPCERT-AT-2026-0033）、JVNVU#99905564 和 CISA 警报。更新了利用报告（仍无确认的入侵）、操作系统软件包（新增 RHEL 8 php:8.2；RHEL 9 php:8.4 和 Debian 开发分支待定）、Docker 官方镜像，以及共享主机的完成状态（Xserver、Sakura、mixhost、ColorfulBox、Value Domain 集团服务、Heteml 等）。
2026-10-21（21:30 UTC）：更新了利用报告（已观察到尝试，无确认的入侵）、操作系统厂商的修复包、Docker 官方镜像已修复、NVD 评分、未经确认的“修复不完整”说法，以及主机更新（Xserver 开始应用修复，添加了 WADAX）。
2026-10-21（14:30 UTC）：添加了一家 CDN 服务商关于观察到攻击流量的报告、Ubuntu 的修复包（USN-8948-1）、NVD 条目以及 Docker 官方镜像的状态。
2026-10-21（14:10 UTC）：添加了发布后的状态（发布时间、受影响版本、公告中确认的影响、官方尚未就利用情况作出说明、操作系统软件包、Docker 官方镜像、remirepo），以及 21:00 JST 之后的主机更新（添加了 CPI 和 mixhost，Xserver 常见问题，Sakura 完成）。
2026-10-21（发布之后）：反映了 PHP 安全团队10月21日的公告（修复版本、CVE 编号、漏洞性质、风险对象、8.1 及更早版本的处理方式、临时措施），并重写了标题和要点。
2026-10-21：首个版本，基于 PHP 安全团队10月20日的通知、IPA 的提前准备通知以及 Xserver 的通知。CVE 编号、受影响版本和修复版本号将在发布后补充。
延伸阅读
- 您的站点是否被攻击：如何检查您的网站或服务器是否被入侵
- 服务商遭入侵时：当您的主机服务商遭入侵时 / ConoHa WING 未经授权的访问
- 共享主机设置：在共享主机上保护 .env
- WordPress 与 Laravel：WordPress 安全 / Laravel 安全
- 准备工作：备份与恢复基础 / 安全资产清单检查表
- 同一周的另一个严重修复：GitLab CVE-2026-110264（含 Ruby 正则修复）
- 术语：什么是 RCE（远程代码执行） / 什么是 CVSS