PHP2Shell: the critical PHP vulnerability and what to do
Announced on 20 October 2026 and fixed the next day, two critical PHP vulnerabilities let an attacker run code on a web server without any credentials. What happened, who is exposed and what to do.
On 20 October 2026 the PHP security team announced an urgent update for two critical vulnerabilities, and on 21 October it published the fixes. The two flaws, nicknamed "PHP2Shell", let anyone run code on a web server without credentials. PHP powers roughly seven in ten websites whose technology is known, including every site built with WordPress, Joomla, Drupal or Magento.
If you are our client, you can relax: we have already upgraded PHP to a safe version for all of our clients. There is nothing you need to do. If your website is managed by someone else, here is what to check.
What happened
- 17 October. Amazon records a first attack attempt on its decoy servers (honeypots), four days before the vulnerabilities become public.
- 20 October. The identifiers of the two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, circulate online earlier than planned. The PHP team announces the fixes for the following day, one day ahead of schedule.
- 21 October. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. Linux distributions had received the fixes in advance. Within hours, Amazon and Cloudflare report the first attacks.
Why it is so serious
Both vulnerabilities have a severity score of 9.2 out of 10 (CVSS 4.0) and three traits that rarely come together:
- No access is needed. A single request to the website is enough, with no login or password.
- The flaw is in PHP, not in the website. Keeping WordPress, Joomla and plugins up to date does not protect you, because the problem lies in the language they run on. Researchers demonstrated the attack against WordPress, Drupal, Joomla and Magento installations.
- Every set-up is affected. The PHP team considers every installation that serves web pages at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, where the attack can start before any of the website's code even runs.
Technically, the first vulnerability (CVE-2026-109618) comes from how PHP handles running out of memory: a failure at the wrong moment leaves the request data half-initialised, and the final clean-up treats it as valid. The second (CVE-2026-109619) leaves a request's data behind after its memory has been freed, and the next request handled by the same process can reuse it. Either way, an attacker can run code with the web server's permissions.
At release, the PHP team had found no working exploits in circulation. Amazon, however, already reports broad exploitation, and several researchers have reproduced the attacks independently: any website that has not been updated should be considered at risk.
Which versions are safe
- PHP 8.5: 8.5.12 or later.
- PHP 8.4: 8.4.27 or later.
- PHP 8.3: 8.3.36 or later.
- PHP 8.2: 8.2.35 or later. Support for 8.2 ends on 31 December 2026, though, so it is worth planning the move to a newer version now.
- PHP 8.1, 8.0 and 7.4: no longer receive official updates. Given the severity, the PHP team published the fixes as source code, and some vendors ship them in updated packages. It is an emergency measure: the right path is moving to a supported version.
- PHP 7.3 and older: no fix. Affected versions go back as far as PHP 5.4, so a website that old needs upgrading at once.
On some Linux distributions the fix arrives in a package that keeps the old version number. If the number you see is not on this list, ask your hosting provider whether the fix is already installed.
What to do if we do not manage your website
- Check your PHP version. You will find it in your hosting control panel. In WordPress it is under Tools → Site Health → Info → Server, in Joomla under System → System Information.
- Ask your hosting provider whether they have updated, and when. On shared hosting the update is the provider's job, not yours.
- Do not rely on "anti-PHP2Shell" plugins or code snippets. The flaw is in the language and a plugin cannot fix it: the only complete fix is updating PHP.
- Look for signs of intrusion from 17 October onwards: administrator accounts you do not recognise, unknown PHP files (in the uploads folder, for example), modified pages, repeated 500 errors. If you find anything, treat the server as compromised: update it, restore a clean backup and change every password and key the website holds (database, FTP, administrators, external services).
If you run the server yourself
If you cannot update straight away, the PHP team lists measures that reduce the risk without removing it: set memory_limit to -1 and session.upload_progress.enabled to 0 at server level (php.ini or the PHP-FPM pool; ini_set() and .user.ini apply too late), on PHP 8.5 also set fatal_error_backtraces to 0, lower post_max_size, and restart every PHP process. The firewall rules Cloudflare has switched on for all its plans also cover only the attacks already known. These are stopgaps: the installation stays vulnerable until it is updated.
This time, updating WordPress and its plugins was not enough: the flaw was in the language they run on. A secure website needs someone looking after the server too.
How we work
Server security updates are part of our managed hosting: clients who entrust us with their website do not need to follow security bulletins or remember to act. If your website is hosted elsewhere and you do not know which PHP version it runs, write to us: we will check together whether it is exposed and what it takes to make it safe.
Article updated on 22 October 2026. The situation is still developing: for the technical details, the official PHP security advisory is authoritative.