PHP2Shell: Check Your Server's PHP Version and Patch It

What was fixed

On 21 October 2026 the PHP team shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as an emergency security release. It fixes two flaws:

• CVE-2026-109618: when a request runs out of memory, half-built internal data is reused by a later request.
• CVE-2026-109619: state left over after a fatal error causes the same kind of problem.

Chained together, they let someone run code on the server without logging in. The flaws are in the PHP engine, not in an application. WordPress or hand-written, anything running on PHP is in scope. According to Sansec’s analysis:

• Apache mod_php and PHP-FPM are both affected in their default configuration.
• The code involved goes back to PHP 5.4 (2012).
• Every known trigger is an upload-style (multipart/form-data) request.

What made it urgent: the details leaked two days before the planned release, an exploit tool is public, and Cloudflare saw attack attempts at 07:43 UTC on 21 October, before the fix was out. php.net’s own wording is blunt: there is no complete mitigation, and updating is the only safe choice.

Are you affected?

Branch you run	Fixed in	What to do
8.5	8.5.12	Update to 8.5.12 or later
8.4	8.4.27	Update to 8.4.27 or later
8.3	8.3.36	Update to 8.3.36 or later
8.2	8.2.35	Update to 8.2.35 or later (8.2 reaches end of life on 31 December 2026)
8.1 and older (7.x, 5.x too)	No fix	Move to 8.2 or later

If PHP comes from your distribution’s packages, the table alone can’t answer the question. See step 2.

Check

1. The PHP your web server actually runs

php -v on the command line can differ from what the web server uses, because several versions installed side by side are common. For PHP-FPM, ask the running service:

php -v
php-fpm8.3 -v          # php-fpm, php83-php-fpm … depending on the distribution
systemctl list-units --type=service | grep -i php

If one server hosts several sites, check the PHP-FPM pool behind each one. If you check with phpinfo(), delete that file as soon as you’re done. It tells an attacker the same things.

2. Distribution packages: the package version and the security notice

Ubuntu, Debian and the RHEL family often ship a fix without raising the version number. 8.1.2 may already be fixed, or may not be.

dpkg -l | grep -E '^ii +php'      # Debian, Ubuntu
rpm -qa | grep -i '^php'          # RHEL, Rocky, Alma

Compare the package version with the fixed version in your distribution’s notice (Ubuntu USN, Debian DSA, Red Hat RHSA), for both CVE-2026-109618 and CVE-2026-109619.

3. Shared hosting: ask your host

On shared hosting you usually can’t update PHP yourself. If the control panel lets you pick a PHP version, pick a fixed one. If it doesn’t, ask your host when they will patch.

4. What shows from outside

Some servers announce their version in a response header, like X-Powered-By: PHP/7.4.33. The HTTP security check reads that header. It warns when the version predates the fix, and shows a note asking you to check when it is a distribution build. Most servers hide the version, though, so seeing nothing there doesn’t mean you’re fine. The real check is steps 1–3, on the server.

Fix

1. Update to a fixed release, through whichever channel you use now: official packages, your distribution’s repositories, or your own build.
2. Restart everything that runs PHP. Replacing the package does not stop PHP-FPM workers and Apache processes that are already running the old code. Restart the services you actually use, such as systemctl restart php8.3-fpm or systemctl restart apache2 (or httpd).
3. Rebuild containers. Pull the base image again (php:8.3-fpm and so on), rebuild and redeploy. An image you pulled earlier under the same tag is still the old one.
4. On 8.1 or older, change branch. No fix is coming for those branches. Until you have moved, the surest protection is to take that server off the internet.

It’s also worth hiding the version from headers (expose_php = Off in php.ini). That doesn’t fix the flaw. It just makes you a less obvious target the next time something like this happens.

After updating

• Check again. Run the step 1 commands to confirm the web server really runs the new version.
• Read the logs. The attack uses upload-style requests to make PHP run out of memory. Since 20 October, look for:
  • multipart/form-data POST requests to paths that don’t normally receive uploads;
  • bursts of Allowed memory size ... exhausted errors.
• If you suspect a compromise, a patch is not the end of it. New files, new accounts or new scheduled jobs after odd requests mean the server should be treated as breached. Follow your incident procedure. Updating only stops what comes next.

As of 22 October 2026, neither flaw is on the U.S. CISA Known Exploited Vulnerabilities list. With an exploit tool already public, there is no reason to wait for it.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Diagnose