PHP2Shell: what happened and how we protect our servers.
In October 2026, two critical PHP vulnerabilities were disclosed that allow an attacker to take control of a server without a password. We explain how they work, what needs to be done and how we handled them at Brova Cloud.
PHP2Shell is the name given to two PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. They were disclosed on 21 October 2026 and both have a severity score of 9.2 out of 10.
They allow code to be executed on the server through a specially crafted request, with no username or password. With that access, an attacker can install a web shell, a back door for controlling the server and the data it holds.
PHP is the language behind WordPress, Drupal, Joomla and Magento. According to W3Techs, it is used by around 69% of websites with a known server-side language.
How the attack works
Both flaws lie in how PHP handles memory when it receives a request:
CVE-2026-109618. If PHP runs out of memory while preparing a request, the clean-up process can treat half-built data as if it were valid.
CVE-2026-109619. Data from one request remains in memory after being freed, and the next request handled by the same process can use it.
The risk depends on how PHP runs on the server. With Apache and mod_php, the attack can take place before a single line of the website’s code is executed. With PHP-FPM, the exposure is lower but depends on the configuration.
Visitors to a vulnerable website are not at risk from browsing it. The risk lies in the server and the data it holds.
The timeline
17 October. Amazon records the first attack attempt on its honeypot servers, four days before the patch.
20 October. The CVE numbers leak and PHP brings its security release forward by a day.
21 October. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released with the flaws fixed.
23 October. PHP discloses a third flaw, CVE-2026-115560, in session upload progress. It has no patch yet.
After the disclosure, Amazon, Cloudflare and watchTowr reported large-scale attack attempts. Wordfence reported more than 74,000 attempts blocked on WordPress sites.
Which versions are affected
PHP version
Fixed in
8.5
8.5.12
8.4
8.4.27
8.3
8.3.36
8.2
8.2.35
8.1 and earlier
No official release. Only patches from some Linux distributions.
Older versions have no fix. PHP 8.1 and earlier no longer receive security updates. If your website runs on one of them, the complete solution is to move to a supported version.
What is not enough
Updating WordPress, its plugins or its theme does not fix PHP2Shell. The flaw is in PHP itself, and it is fixed on the server. These measures are not enough either:
A firewall on its own. A web application firewall stops known attacks, but if the server also responds directly, an attacker can bypass it.
Checking the version with php -v. Some Linux distributions apply the patch without changing the version number. You need to check the installed package.
Installing the patch without restarting. With mod_php, Apache needs a full restart. With PHP-FPM, the service must be restarted or reloaded.
Hiding errors or disabling file uploads. Neither makes any difference to these flaws.
How we handled it at Brova Cloud
Brova Cloud is our managed hosting service, reserved for the websites we build. The servers are in Helsinki, Finland, and all traffic passes through the Cloudflare network.
Hetzner, our infrastructure provider, updated its own systems. Brova Cloud, however, runs on several private servers, and each one is updated separately. So we worked through them server by server:
Backups first. Before touching anything, we backed up every server.
PHP updated on every server. We installed the patched versions one by one and restarted the services so that the fix took effect.
Every recommended measure. We applied the security measures recommended for PHP2Shell, including those that have to be configured by hand.
A full review. We checked service by service, account by account and site by site.
We found no open vulnerabilities and no traces of attack on the websites we host.
Staying informed is part of the job. We take part in system administrator communities and follow security alerts every day. Security and compliance with international standards are a priority for every website we host.
What to check if your site is with another host
Ask your provider whether they have installed PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patch, and whether they restarted PHP afterwards.
If your website runs on PHP 8.1 or earlier, plan the upgrade as soon as possible.
Until a patch for CVE-2026-115560 is released, disable session.upload_progress.enabled in your PHP configuration. WordPress does not use this feature.
Check the website folder for any new or modified PHP files that you do not recognise.
If the server was exposed, change the passwords and API keys stored on it, because a related flaw can leak server memory.
If you have questions about your server, write to us and we will review it with you.
Joaquín Martinez Herrera 7 min read
