PHP2Shell vulnerability: what to do now

If your website or any of your company’s systems runs on PHP, update PHP now: to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the branch you use. The flaws known as PHP2Shell let an attacker run code on the server without logging in, affect every PHP version released in the last decade, and real-world exploitation was confirmed on October 26. Updating WordPress or its plugins does not help: the flaw is in PHP, not in the application.

This guide is written for people who run a company, not for whoever manages the server, although the last section is technical so you can pass it on to your team or provider.

What happened, briefly

October 21, 2026. The PHP project released patches for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 (CVSS v4.0). Both allow remote code execution.
Scope. According to Wiz, one of the firms that found them, every PHP version released in the last decade is affected by at least one of the two, going back to 5.4. They do not depend on your application code: the attack was demonstrated against fresh installs of WordPress, Drupal and Joomla.
October 26. A successful attack against a honeypot server running PHP 8.4.26 was confirmed. Five days passed between the patch and the first confirmed attack.
A third flaw has no patch yet. On October 23 PHP announced CVE-2026-115560. According to the project, it only occurs under an unusual combination of configuration and code, and will be fixed in the next release. Until then it is mitigated with a setting described below.

What makes this case different is how it was found. Researchers used AI models to find the flaws and to adapt the exploits to different versions and configurations. Wiz says a single researcher did in about a week what would previously have taken a specialist team months.

Is my company affected?

Probably yes, if you have any of these:

A WordPress, Drupal or Joomla site, which run on PHP.
A system built with Laravel, Symfony, CodeIgniter or plain PHP.
A WooCommerce, Magento or PrestaShop store.
Software from a vendor that runs PHP under the hood, installed on your server or provided as a service. If you don’t know what it is built with, that is the first question for your vendor.

PHP branch you use	Version you should have	Note
8.5	8.5.12 or later
8.4	8.4.27 or later
8.3	8.3.36 or later
8.2	8.2.35 or later	8.2 reaches end of life on December 31, 2026
8.1 or older	No official fixed release	Migrate to 8.2 or later. The PHP team published minimal source patches for 7.4, 8.0 and 8.1 for those who build from source

What to do depending on where your site runs

Shared hosting (the typical plan with a cPanel-style control panel). Your hosting provider patches PHP, not you. Write to them today and ask which exact version your account runs and whether the fix is applied. If the panel lets you choose the PHP version, pick the newest branch your site supports, and test it first: an old site can break when PHP is upgraded.

Your own server or VPS. Update PHP from your operating system packages or the repository you use, then restart every PHP process (PHP-FPM or Apache). Processes that stay alive keep running the old code.

Docker containers. Bump the base image to a fixed tag (for example php:8.3.36-fpm), rebuild the image and redeploy. Restarting the container with the same image fixes nothing. If you run several servers, or one server per customer, the patch has to reach each of them.

Vendor software. Don’t assume it’s done. Ask in writing which PHP version your system runs and the date the fix was applied.

Questions to send your provider today

Which exact PHP version runs my website or system?
Have you updated to a version fixed against CVE-2026-109618 and CVE-2026-109619? On what date?
Did you restart every PHP process after updating?
Did you disable session.upload_progress until the CVE-2026-115560 fix ships?
Did you check the server logs for attack attempts since October 17?
How long do you usually take to apply a critical patch, and how do you notify me?

The last question tells you the most. A provider that answers with a number and a procedure has this under control.

For whoever manages the server

PHP’s official advisory is clear: there is no complete mitigation, and updating is the only safe choice. While you update, these measures reduce the risk:

Set session.upload_progress.enabled = 0 in php.ini, the PHP-FPM pool or the server configuration, and restart every worker. ini_set() or .user.ini do not work for this. The setting also covers CVE-2026-115560, so keep it after updating until the next PHP release.
Limit request size: PHP recommends post_max_size = 8M if the application does not accept uploads, or 32M if it does, with upload_max_filesize below that value.
Enforce limits at the web server or proxy too (request size, field count, multipart part count), and enable your CDN provider’s WAF rules if you have one.
On PHP 8.5, set fatal_error_backtraces = 0.

The full list is in the security advisory on php.net.

Signs someone tried, according to Wiz and incident responders: unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, oversized or malformed PHPSESSID cookies, unexplained PHP worker restarts, shells spawned by the web server user (such as www-data) and outbound traffic you don’t recognize. If you find any of that, updating is no longer enough: the patch closes the door but does not remove whoever already got in. That calls for a forensic review by incident response specialists.

What this signals

PHP2Shell is not an isolated case. On the same day, Node.js fixed ten vulnerabilities, including one in the Brotli compression library that also affects Python and .NET, found by a team at OpenAI, which expects this kind of finding to increase sharply in the coming months.

For a company, the practical consequence is simple: the time between a patch and an attack is now measured in days. The useful question is no longer whether your software is secure, but this: if a critical patch ships tomorrow, how many hours until it is running on all your servers?

If the answer is “it depends on who is available” or “we have to do it server by server”, the risk is not PHP. It is how your software is operated. That is solved with three things that don’t require rewriting anything: an inventory of what runs where and on which version, automated deployments so a patch is built once and reaches every server, and someone responsible for watching security advisories and acting the same day.

How we can help

At GeekCorp we build and operate software for companies. We can review what runs on your servers, update PHP and your systems’ dependencies, and set up a process so the next critical patch is applied in hours, not weeks. When a formal penetration test or a forensic review is needed, we work with information security specialists.

If you want us to take a look, get in touch and tell us what you have. The first conversation is free.

Sources: security advisory and releases on php.net · Wiz: PHP2Shell · Enter.co: confirmed exploitation · OpenAI: Patch the Planet