PHP2Shell: the critical PHP flaw and what to do if your site runs on it

On 21 October 2026 the PHP project shipped an out-of-cycle security release. It fixes two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known together as PHP2Shell. Both score 9.2 out of 10 and both allow the same thing: someone running code on your server by sending a web request, with no account, no password, and no bug of your own application involved.

The technical details leaked on 20 October, a day before a patch existed. That is why the warning arrived with so much urgency.

This article is for anyone with a website, a store or an internal system who isn't sure whether it runs on PHP. Spoiler: if you have a WordPress site, it does.

What it is, without the jargon

PHP is the language behind WordPress, WooCommerce, Joomla, Drupal, Moodle, PrestaShop, Magento and a good share of the systems built with Laravel or Symfony. When someone visits your site, a PHP process on the server builds the page.

Both flaws are in how PHP cleans up memory between one visit and the next:

• CVE-2026-109618: if a request runs out of memory halfway through, PHP can be left with half-built data and later treat it as valid.
• CVE-2026-109619: data from an earlier visit can survive after it was freed, and the next visit uses it before it gets reset.

An attacker who knows how to trigger those situations can turn them into code execution with the web server's permissions. From there they can read the database, steal the credentials stored in the configuration, or install whatever they like.

The most worrying part: on Apache servers with mod_php, the PHP team demonstrated that the attack works before a single line of your application runs. It doesn't matter how well written your site is or which plugins it has.

Am I affected?

It affects every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. In other words, practically any shared host, VPS or container serving a PHP site.

These are the fixed versions:

Branch	Fixed version	Note
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	Stops receiving fixes on 31 December 2026
PHP 8.1 or older	No official release	Source patches or vendor fixes only

If your version is lower than the one in the table for its branch, you are exposed. 8.3.35 is vulnerable; 8.3.36 is not.

How to find out which version you run

It depends on where your site lives:

• Shared hosting (cPanel, Plesk, DirectAdmin): look for "Select PHP version" or "MultiPHP". It shows the branch (8.2, 8.3…), but not always the exact patch. For that, ask the provider.
• WordPress: Tools → Site Health → Info → Server shows the PHP version the site is using.
• Your own server or VPS: php -v shows the command-line version, which may not be the one serving the web. Also check php-fpm8.3 -v (or whichever version applies) and restart the service after updating.
• Docker: open a shell in the container that serves the site and run php -v there, not on the host.

If none of that is within reach, a temporary file containing <?php phpinfo(); on the server shows the exact version. Delete it as soon as you've read it: it exposes a lot about your configuration.

What to do today

If your site is on a hosting provider

The provider does the update, but don't wait for them to announce it. Write to them:

Hi. Have you updated PHP for CVE-2026-109618 and CVE-2026-109619? My site uses PHP [8.x]. I need to know whether it is running a fixed version (8.5.12, 8.4.27, 8.3.36 or 8.2.35) and since when.

If the answer is vague, or your site is on PHP 8.1 or older, that is already information: you have a risk the provider isn't solving.

If you run the server

1. Update PHP with your distribution's packages. Distributions received the patches in advance, so they should normally be available already.
2. Restart every PHP process (PHP-FPM, Apache). As long as an old process is alive, it is still vulnerable.
3. Start with internet-facing servers and, among those, the ones using mod_php.
4. Check the version from the web, not only from the console.

If you use containers

There's a trap here we got to see up close. An image based on php:8.3-fpm-alpine looks like it updates itself, because the tag always points to the latest patch. But if your CI builds with a cache, it can reuse the old base layer and publish a "new" image with the vulnerable PHP inside.

The safe move is to pin the exact version in the Dockerfile (FROM php:8.3.36-fpm-alpine), rebuild, deploy, and check with php -v inside the running container.

If you can't update today

The PHP team published measures that reduce exposure, with an explicit warning: they do not make an installation safe. They buy you hours; they don't replace the patch.

; php.ini or the FPM pool configuration (ini_set and .user.ini are too late)
session.upload_progress.enabled = 0
post_max_size = 8M            ; 32M if the site receives files
upload_max_filesize = 8M      ; always lower than post_max_size
; PHP 8.5 only:
fatal_error_backtraces = 0

They also recommend limiting request size and complexity at the web server or proxy and, if your application doesn't receive file uploads, blocking multipart requests altogether. A web application firewall (WAF) can help in the meantime.

After any configuration change, restart the PHP processes so it takes effect.

Is it already being exploited?

The sources disagree, and it's worth saying so plainly:

• CISA and the security firm Huntress said that, as of 21 October, they had not observed exploitation on real systems.
• Qualys cites Cloudflare, which reports attack traffic aimed at these flaws.
• Rapid7 says several teams are already reproducing the research and expects a public exploit soon.

In practice it doesn't matter who is right today: with the details leaked and the patch public, anyone can compare the code before and after. The reasonable thing is to assume the attack will exist and act first.

After the patch

Updating closes the door, but it doesn't tell you whether someone came in earlier. If your server was exposed between 20 October and the moment you updated:

• Check whether any PHP process launched system commands (sh, bash, curl, wget). That is the signal CISA recommends watching for.
• Look for new or modified PHP files in folders where they shouldn't change, such as uploads.
• Rotate the credentials stored in the configuration (database, email, API keys) if you find anything odd.

Clean logs don't prove nothing happened. Rapid7 says so explicitly.

In short

• If you use PHP for the web, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart the processes.
• If you're on a hosting provider, ask them with the exact versions.
• If you're on PHP 8.1 or older, the problem is bigger than this flaw: plan the migration and, meanwhile, get a vendor patch or take the system offline.
• And use the scare to write down where PHP runs in your company. The next alert will come, and knowing that in advance is what makes the response take an hour instead of a week.

---

Sources: PHP project announcement, CISA alert, Rapid7 analysis, Qualys and Huntress.

Not sure where PHP runs in your company? Let's talk