Security advisory: PHP fixes two critical remote code execution flaws

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which Cloudflare and others call php2shell.¹² PHP says both can allow unauthenticated remote code execution and urges all users to update immediately. Both CVE records carry a CVSS v4.0 score of 9.2 (Critical).³⁴

This advisory explains what PHP has published, how to tell whether a server is fixed and what to do if you cannot update today.

What PHP fixed

PHP's advisory describes two separate flaws:¹

• CVE-2026-109618, RCE via out-of-memory corruption. When PHP runs out of memory, it can stop in the middle of a request while internal request data is only partly set up. The cleanup that follows can then treat that invalid data as valid.⁵
• CVE-2026-109619, RCE via stale global state. Some internal state that belongs to a request can survive after its memory has been freed. A later request handled by the same worker can use that stale state before it is reset.⁶

PHP says it has a working exploit against Apache with mod_php, where an unauthenticated request can trigger the attack before any application code runs. That is why it rates the risk highest for mod_php. But it lists every installation that serves web requests as at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.¹

Which versions are fixed

The CVE records list only the supported branches, 8.2 to 8.5, as affected.³⁴ Do not read that as meaning older versions are safe. Cloudflare's write-up says the flaws affect PHP 5.4 and later.² PHP's advisory says 8.1 and older no longer receive updates from the project, and, given how severe these flaws are, the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source or have no long-term support vendor.¹

Linux distributions and long-term support vendors received the patches in advance, so updated packages may already be available. A vendor package often keeps the original version number and adds the fix, so a server reporting 8.3.35 may or may not be fixed. Check the package changelog, not only the version string.

PHP also warns users of the volunteer-run rpms.remirepo.net repository that it will not have updates on 21 October, and recommends switching to distribution packages or building from source.¹

Check what your web server runs

The php command on a server's command line can be a different build from the one serving web traffic. Check the packages behind the web server itself: PHP-FPM, the Apache module, or LiteSpeed's lsphp.

1. 1

   List the PHP packages installed. On Debian or Ubuntu, dpkg -l | grep php. On Red Hat-based systems, rpm -qa | grep php. On a control panel such as cPanel or Plesk, check every PHP version the panel offers to sites.

2. 2

   Check the package changelog for the two CVEs. On Debian or Ubuntu, apt changelog <package> | grep -E 'CVE-2026-10961[89]'. On Red Hat-based systems, rpm -q --changelog <package> | grep -E 'CVE-2026-10961[89]'. If the version is below the fixed release and the changelog mentions neither CVE, treat the package as unfixed. If you are unsure, ask your hosting provider or vendor.

3. 3

   Update, then restart every worker. A new package does not help until the processes that loaded the old one have stopped. Restart PHP-FPM pools, Apache, or LiteSpeed and its lsphp processes.

4. 4

   Check every site on the server. Shared servers often run several PHP versions side by side. Each one needs the fix.

$ dpkg -l | grep php8.3-fpm
$ apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

Hiding the version header with expose_php = Off is good hygiene, but it does not fix anything.

If you cannot update today

PHP lists temporary measures, and is clear about their limits: "only an update is a complete solution", and these measures "reduce exposure to specific attack paths but do not make an installation safe".¹ Treat them as a way to buy hours, not as a fix.

For CVE-2026-109618, out-of-memory corruption:

• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application sets a finite limit again. PHP notes that an underlying allocation failure can still reach the vulnerable code.
• Lower post_max_size: 8M for applications without file uploads, 32M if uploads are needed. Keep upload_max_filesize below it.
• Consider limits at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth. They must also cover requests without a usable Content-Length.
• Use a container or cgroup memory limit as an availability boundary, preferably one that kills only the affected worker. PHP warns not to use RLIMIT_AS or RLIMIT_DATA instead, because they can cause the very allocation failure the attack needs.

For CVE-2026-109619, stale global state:

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then restart every worker. Do not rely on ini_set() or FPM .user.ini files. PHP says this blocks the confirmed session paths, not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed fatal-backtrace path.
• Remove invalid or deprecated per-request settings that produce warnings before initialization. Hiding the warnings with error_reporting, display_errors or @ does not help.
• Fix fatal errors and execution timeouts that an attacker can trigger, including in callbacks, upload or import processing and cleanup.

Cloudflare's WAF protection

Cloudflare calls the two flaws php2shell. It says it worked on the coordinated response with the PHP Foundation and others, and deployed WAF rules about nine hours before public disclosure. From 03:02 UTC on 21 October, Cloudflare customers using its free or paid WAF were protected by default.²

Cloudflare also says the vulnerability leaked before the official release, that it saw attack traffic aimed at its customers, and that attackers changed their payloads to try to get past its rules. Its write-up says the flaws affect all web servers running PHP 5.4 or later.²

The protection comes in three parts:²⁷

The last one uses a new Cloudflare capability, full transaction detection. It looks at the origin's response as well as the request, and can stop a response that shows a successful exploit before it reaches the attacker. Cloudflare says this lets the rules match exploits with more confidence and fewer false positives than request-only rules.²

If your sites are behind Cloudflare:

• Confirm the rulesets above are deployed and blocking on every zone that serves PHP.
• Make sure your origin accepts web traffic only from Cloudflare. A request sent straight to the origin's IP address never passes through the WAF.
• Watch Security > Security Analytics > Events, filtered by these rules, in case a legitimate form or upload is blocked. If one is, narrow the scope of the Managed Ruleset rather than turning the rules off.

How Vigilbase can help

If Vigilbase manages your Cloudflare account, contact your account team or our support team and reference this advisory. We can check that Cloudflare's php2shell rules are deployed and blocking on your zones, review the matching security events, check that your origins accept traffic only from Cloudflare, help you list the public hostnames that show signs of PHP, coordinate with your hosting provider and review any temporary request limits you put in front of your origin. Updating PHP itself is a change on your servers, made by you or your hosting provider.

If you are not a customer and want help working through these checks, contact us.

We will update this advisory if PHP publishes new information.