PHP安全团队发布公告，将于北京时间10月21日22点发布安全更新，修复CVE-2026-109618和CVE-2026-109619两个严重漏洞。两个漏洞在CVSS v4.0体系中均评为9.2分，安全公司watchTowr确认其均为影响PHP 5及以上版本的零日远程代码执行漏洞。

事件起源于10月20日有网民在Hacker News发帖，爆料两个RCE漏洞即将披露，相关截图随后在社交平台流传，watchTowr随后确认漏洞真实存在。PHP官方原计划10月22日解除信息封锁，如今将修复版本提前至21日发布，并表示若漏洞细节进一步公开或出现实际利用迹象，发布时间还可能继续提前。

目前尚无公开证据显示漏洞已被大规模利用，也未发现官方可用的临时缓解方案。由于PHP是大量内容管理系统与共享主机服务的底层技术，网站管理员、云服务商和企业运维团队应尽快确认服务器PHP版本，在补丁发布后立即升级。

PHP 官方原文：

Upcoming Critical PHP Security Release
The PHP security team would like to give advance notice of an upcoming security release.

It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.

It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.

All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.

We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.

Full details, affected versions, and the fixed versions will be published with the release.

Thank you for helping us keep PHP secure.

据说此次影响面极广，基本上 php8.x 以下版本全部中招，建议大家重点排查,第一时间进行升级修复。

2026 年 10 月 21 日 22:37:35 更新：
官方漏洞披露及补丁发布：

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
How to update:

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
The advisories linked above have the full technical details.