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 before the patch became available. 

Various vendors have released bulletins listing products that must be patched for this vulnerability. For example:

Cisco  https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq
OPNSense https://x.com/opnsense/status/2112985458514756087
PFSense https://forum.netgate.com/topic/201565/critical-php-security-update
Palo Alto Networks https://security.paloaltonetworks.com/CVE-2026-109618
 

Many open source firewall/router products use PHP. Expect updates for them, and as always, do not expose the web admin interface to the internet.

PHP also published a summary around the release:

https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

The PHP update was released as scheduled: 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 released today, are currently the only "safe" versions. Note that Linux distributions may backport the patch for older versions.

Ubuntu just released updated PHP packages for Ubuntu 22.04, 24.04, 26.04, and  26.10. [ubuntu].

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 before applying the patch?

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

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 have already 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?

Wiz Security published a blog post detailing how they discovered the vulnerability using AI tools. [wiz]

• CVE-2026-109618

This vulnerability is described as a remote code execution via 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 conditions in which the state is not properly reset, leading to a use-after-free. [CVE-2026-109619]. To trigger the vulnerability, an attacker would first have to send a request that triggers an error. For example, an "out of memory" or "request execution time exceeded" error. Secondly, a request must be sent to trigger a warning during initialization. The examples mentioned are warnings triggered by various INI settings, such as depreciation warnings. This does not apply to settings in the global php.ini file, which is only applied on startup. Instead, it applies to local configuration overrides, such as .htaccess files, that are applied to individual requests. Exploitation has been confirmed in PHP 8.5 with fatal_error_backtraces enabled. 

Related to the prior vulnerability, file upload errors can also trigger this condition and be used to exploit this vulnerability. 

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 it may provide indicators of 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
[ubuntu] https://ubuntu.com/security/notices/USN-8948-1
[wiz] https://www.wiz.io/blog/php2shell-php-rce

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