PHP.net announced that it will release a critical update today. We decided to change the infoCon to YELLOW due to the widespread use of PHP, the expected severity of the flaw (CVSS 9.4), and the availability of early PoC exploits ahead of the patch becoming available. 

The PHP update was released as schedule: https://www.php.net/index.php#2026-10-20-1

This diary will be continuously updated today. I am starting to write this diary with many details still unclear and with the patch not yet available.

Which versions of PHP are vulnerable?

The easy answer: All of them. At least starting with PHP 5, including the most recent releases.

PHP Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all realeased today, are currently the only "safe" versions. Note that Linux distributions may backport the patch for older versions.

Which versions will receive patches?

Only PHP 8 is expected to receive a patch. Older versions are no longer supported. The patch is expected to be released at 14:00 UTC today, October 21st. [php] Ubuntu will release patches "as soon as possible" and may include backported patches for PHP versions included in supported Ubuntu versions.

The real "race to patch" does not start at 14:00 UTC for most people, but at the time distributions release updated packages. Most PHP sites do not use PHP compiled from php.net directly. It will almost certainly be faster to wait for your distribution to release an update.

Does this vulnerability affect specific configurations or extensions?

The vulnerability is in the PHP core, and all default PHP installations are expected to be vulnerable (see below for mitigations). 

What steps can I take to mitigate the vulnerability, ahead of applying the patch?

Early guidance suggests that the configuration setting "session.upload_progress.enabled = Off" provides partial mitigation against the vulnerability being exploited. Buy default, this setting is "On". Restricting the maxmimum allowed request size in your web server and/or PHP configuration may help as well.

Are there WAF rules or other measures to protect a site running PHP?

Yes. I will add more as I verify them. Cloudflare appears to already have deployed some protections. Other vendors have likely done the same.

Have exploits been seen "in the wild"?

Cloudflare is reporting exploits [cloudflare]. PoC exploits and vulnerability details have been released [jackalsyn]

How do the vulnerabilities work?

• CVE-2026-109618

This vulnerability is described as a remote code execution vai out-of-memory corruption. [CVE-2026-109618]. The advisory describes several issues related to this vulnerability. Firstly, a multipart MIME request without a Content-Length header may bypass the post_max_size setting, which is intended to restrict the amount of data sent in a request. As a result, more data than expected may be sent to PHP. Second, the number of headers is not restricted, allowing for additional memory use. Finally, the max_file_uploads setting is supposed to limit the number of files uploaded, but it does not consider empty files. The structures set up for empty files will also exhaust memory (this is likely where the oversized filename in the early PoC exploit below came from). 

• CVE-2026-109619

???????PHP workers track global state (for example sessions) that is associated with a specific request. Before releasing the memory associated with the request, the state must be reset. There are considtions where the state is not properly reset, causing a use after free condition. [CVE-2026-109619].

What does the PoC exploit do?

The PoC exploit sends a POST request using a multipart MIME payload. These payloads are commonly seen with file uploads or other POST form submissions. According to the discussion at [jackalsyn], the trigger is in part a very large filename. The PoC exploit does not appear to be reliable, but may provide indicators as to what to look for in a working exploit.

Exploit snippet (I abbreviated the filename as it is about 5 MByte long:

POST / HTTP/1.1
Host: localhost
Cookie: PHPSESSID=s0123456789abcdefghijklmnopqrstuv
Content-Type: multipart/form-data; boundary=SctxPoc2026
Content-Length: 5244717
Connection: close

--SctxPoc2026
Content-Disposition: form-data; name="PHPSESSID"

s0123456789abcdefghijklmnopqrstuv
--SctxPoc2026
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"

x
--SctxPoc2026
Content-Disposition: form-data; name="upload0"; filename="f0-NNNNNNNNN[continues...]

NNNNNNNNNNNN"

Z
--SctxPoc2026--

(again, this is the unreliable/incomplete exploit PoC published by [jackalsyn].)

Anything else I may want to do?

Again, the only real fix is the patch, but in a pinch, some other filters and adding some "obscurity" may help:

• Block all requests with "Content-Type: multipart/form-data". This of course will break file uploads.
• Hide the fact that you are using PHP. Now we are talking real weak "security through obscurity", but it may help with some early exploits. This involves using extensions other than .php, and setting expose_php=Off in your PHP configuration to get started. You may also want to review the PHP session cookie name.

[cloudflare] https://x.com/IntCyberDigest/status/2112845843938054610/photo/1
[jackalsyn] https://jackalsyn.com/posts/php-up-2026.html
[php] https://www.php.net/archive/2026.php#2026-10-20-1
[CVE-2026-109618] https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
[CVE-2026-109619] https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|