On 21 October 2026, the PHP project shipped emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known together by the name security researchers gave them: PHP2Shell. Both let an attacker take over a web server remotely, with no password and no user interaction, and together they affect software running roughly 70% of all websites on the internet. If you run PHP anywhere, directly or through WordPress, Drupal, Joomla, or Magento, this post explains what happened, what the jargon means, and exactly what to do about it.
What PHP Is, and Why This Matters So Much
PHP is a programming language built in 1994 to make it easy to generate web pages on the fly. A web browser asks a server for a page, the server runs a PHP script to build that page from a database or a form submission, and sends back the result. It has been the default choice for “make the web do things” for three decades.
The scale is hard to overstate. According to W3Techs, which tracks the technology behind the web, PHP powers roughly 70% of all websites where the server-side language is known.[1] That includes WordPress, Drupal, Joomla, and Magento, the content management systems and shopping platforms behind a huge share of the small business, charity, and e-commerce sites online. WordPress alone, which is built on PHP, runs well over 40% of all websites.[2]
A flaw this deep, inside PHP’s own engine rather than a plugin or theme sitting on top of it, reaches roughly 70% of all websites on the internet, including sites their owners haven’t touched since the day a developer or an agency built them.
What Happened
On 20 October 2026, the PHP security team posted an advance warning: an emergency security release was coming the next day, fixing two critical vulnerabilities, each rated 9.2 out of 10 on the CVSS v4 severity scale.[3] Before the official release, details leaked on a popular developer forum, so PHP’s maintainers pushed the patch out early rather than let attackers get a head start.[4]
The two flaws, tracked as CVE-2026-109618 and CVE-2026-109619, are now collectively known by the nickname security researchers gave them: PHP2Shell. Both are rated critical, meaning no password or user interaction is needed, an attacker who reaches your server over the network can take it over outright, and together the two flaws affect roughly 70% of the internet.[5]
Both bugs come from the same root cause: PHP can leave its internal memory in a corrupted state when a web request ends abnormally, for example because the server runs out of memory partway through handling it. An attacker who understands that corruption can shape a request so that, instead of crashing harmlessly, it hands them control of the server. Both vulnerabilities require no password, no login, and no user interaction. The attacker just needs to be able to send a request to your website.[6][7]
The affected software is not an obscure corner of PHP. It covers PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed, which between them run the overwhelming majority of PHP websites in production today.[4]
The Jargon, Explained Simply
Security stories like this one get buried in words that mean nothing to most business owners. Here is what they actually mean.
Vulnerability. A mistake in how software was built that lets it be made to do something it was never supposed to do, the software equivalent of a lock that can be picked.
0-day (“zero-day”). A vulnerability that is public, or being actively attacked, before a fix exists. The name comes from defenders having had zero days to prepare. PHP2Shell briefly became a 0-day the moment its details leaked, before the patch was ready.
Exploit. The actual piece of code or technique that takes advantage of a vulnerability. A vulnerability is the unlocked door; an exploit is someone walking through it.
RCE (remote code execution). The most serious outcome a vulnerability can have. It means an attacker, from anywhere on the internet, can run their own commands on your server, as if they were sitting at the keyboard. From there they can steal data, install malware, deface the site, or use your server to attack other people.
Shell. In this context, not a literal seashell, a command-line interface that lets someone type instructions directly to a computer. A “web shell” is a small, often disguised, program an attacker plants on a hacked server so they can keep typing commands to it later, even after the original hole is patched. The “Shell” in PHP2Shell refers to this: the flaw’s end state is an attacker gaining this kind of direct control.
CVE. Short for Common Vulnerabilities and Exposures. It is just a shared ID number, like a case reference, so that security teams, vendors, and researchers worldwide are all talking about the exact same flaw. CVE-2026-109618 and CVE-2026-109619 are the two PHP2Shell flaws.
CVSS score. A 0 to 10 severity rating. Above 9 is “critical”, the highest band. Both PHP2Shell flaws score 9.2.
Patch. The fix. Applying it means updating your software to a version where the mistake has been corrected.
Unauthenticated. Requires no username or password. This is what makes PHP2Shell so dangerous: there is no login screen standing between an attacker and your server.
Why the Industry Reacted the Way It Did
This was not a quiet patch Tuesday. Several national bodies and large organisations treated it as an emergency.
The UK’s National Cyber Security Centre urged organisations to update immediately or take affected systems offline until they could.[4] The US CISA issued an advisory telling agencies and organisations to patch without delay.[8] Dark Reading, a widely read security publication, called it a “red alert for the security industry."[9]
More strikingly, some organisations did not wait for the patch at all. Public bodies, universities, and news outlets in the Netherlands, Finland, and Austria took websites offline as a precaution before updating, rather than risk staying exposed.[10] In Japan, at least 19 organisations, including hosting providers, announced shutdowns or emergency maintenance windows to apply the fix.[10]
Cloudflare said its team was already seeing early exploitation attempts before the official patch was even released, and rolled out temporary firewall rules, while stressing those rules were not a substitute for patching.[4] VirusTotal scans at the time of disclosure found over 5.1 million PHP hosts reachable from the internet, with roughly 3.8 million of them having at least one relevant port open to attack.[4]
One mitigation that circulated widely, turning off a setting called session.upload_progress.enabled, was reported as helpful but incomplete: it blocks one path to exploitation, not the other. PHP core developer Gina Peter Banyard was blunt about it: applying the official patch is the only complete fix.[4]
Where PHP Is Hiding in Your Business
Most business owners never write a line of PHP and still run it everywhere. PHP sits underneath:
- WordPress, which powers over 40% of all websites, including most small business sites, blogs, and brochure sites built by freelancers or agencies.[2]
- Drupal, used heavily by universities, government bodies, and larger publishers.
- Joomla, another widely deployed open-source CMS, particularly for membership and community sites.
- Magento (now also sold as Adobe Commerce), a common choice for mid-size online shops.
- Custom-built web applications, internal tools, booking systems, and member portals that an agency or a long-departed developer built for you years ago and that nobody has looked at since.
If your business has a website, an online store, a booking system, or a customer portal that was built any time in the last twenty years, there is a good chance PHP is running somewhere underneath it, whether your current team knows it or not.
What to Do Right Now
1. Find out what PHP version your site is running. If you use WordPress, most hosting control panels (cPanel, Plesk) show this under “Software” or “PHP Selector.” If a developer or agency manages your site, ask them directly: “What PHP version are we on, and have we applied the PHP2Shell patch?”
2. Update to a patched version. The fix is in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.[4] If you are on an older branch, PHP 7.4, 8.0, or 8.1, the PHP project has stopped general support for those versions, but published minimal emergency source patches for them given the severity. You should treat this as a prompt to move to a supported version, not just apply the one-off fix and stay behind.[4] If you are still running PHP 5 or PHP 7 in general, those are long past end-of-life and should be migrated off entirely, this vulnerability aside.
3. Restart your web server after updating. A PHP update only takes effect once the web server process (Apache, Nginx with PHP-FPM, or similar) is restarted or reloaded. Confirm with whoever manages your hosting that this step happened, it is the most common reason a patch “applied” doesn’t actually take effect.
4. If you run WordPress, Drupal, Joomla, or Magento, update the PHP runtime itself, not just the CMS or plugins. This is a flaw in the PHP language underneath your CMS. Updating WordPress core or your plugins does not fix it. You need the server’s PHP version updated.
5. Check for signs of compromise if you were running an old, unpatched version with internet-facing access for any length of time after 21 October 2026. Look for unfamiliar files in your web directories (especially ones with generic names like cache.php or config_old.php), unexpected admin accounts, or unusual outbound traffic. If you are not confident doing this yourself, this is worth a professional check rather than a guess.
“What If My Hosting Provider Won’t Update PHP?”
This is one of the most common situations small businesses find themselves in, and it is worth taking seriously rather than just hoping it gets sorted eventually.
First, check whether you can change it yourself. Most shared hosting control panels (cPanel’s “MultiPHP Manager”, Plesk’s “PHP Settings”, or similar on other panels) let you pick your site’s PHP version directly, often without needing to contact support at all. This is worth checking before assuming you are stuck.
If you cannot change it yourself, contact your host directly and ask when the patched version will be available. Reputable hosts, including the large managed WordPress and shared hosting providers, typically roll out security-critical PHP updates within days of a release like this one. If your host cannot give you a clear date, that is useful information in itself.
If your host is unresponsive or refuses to patch, you have three realistic options. Put a web application firewall in front of your site as a compensating control (see the next section), this does not fix the underlying flaw but reduces your exposure while you sort out the host. Ask whether you can move to a different plan or server with the same provider that gives you PHP version control. Or treat this as the trigger to migrate to a host that takes security updates seriously, many SMEs discover their hosting relationship has been quietly degrading for years and a forced-patch moment like this is often what finally prompts the move.
What you should not do is nothing. “My host handles that” is only true if you have checked that it is actually true. A quick email or a five-minute look at your control panel settles the question.
Can a Web Application Firewall Protect You?
A web application firewall, or WAF, sits in front of your website and inspects incoming traffic before it reaches your server, blocking requests that look malicious. Think of it as a security guard checking bags at the door, rather than a lock on every individual room inside.
For PHP2Shell specifically, a WAF is a genuinely useful layer, but it is a compensating control, not a fix. Cloudflare deployed WAF rules against known PHP2Shell exploitation methods within hours and described them as reducing risk while explicitly not replacing the patch.[4] That distinction matters: the underlying flaw is still there in unpatched PHP, a WAF just makes it harder for an attacker’s specific request pattern to reach it. Attackers can and do adjust their techniques to get around firewall rules over time.
What a WAF is good for here:
- Buying time while you arrange a PHP update, particularly if your host is slow to patch.
- Blocking the specific request patterns (large, malformed, or unusually structured multipart form submissions) that this vulnerability relies on.
- Ongoing protection against the next vulnerability, and the one after that. This is not a one-off problem; PHP, like every widely used piece of software, will have more critical flaws discovered in the future.
Most reputable hosts and CDNs, including Cloudflare, Sucuri, and others, offer a WAF as a standard or low-cost add-on, and for WordPress sites, plugin-based WAFs are also available. If you do not have one in front of your site today, this is a sensible moment to add one, alongside patching, not instead of it.
What This Risk Actually Means for Your Business
Strip away the technical language and the risk is simple: an unpatched, internet-facing PHP website can be taken over by a stranger, with no password required, in an automated way that does not need a human attacker typing commands in real time. Once that happens, the consequences for a small or medium business are concrete, not abstract.
Data theft. Customer records, order histories, and payment details stored or processed through the site can be extracted.
Ransomware and extortion. A compromised server is a common entry point for ransomware gangs, who have historically moved quickly to exploit critical PHP flaws like this one; a similar PHP vulnerability in 2024 (CVE-2024-4577) was used by the TellYouThePass ransomware group within days of disclosure.
Your website used to attack others. A hacked server is valuable to attackers even if you have nothing worth stealing, it can be used to host malware, send spam, or attack other websites, with your business’s name and domain attached to the activity.
Downtime and reputational damage. A defaced website, or one quietly used for fraud, damages customer trust in a way that is hard to repair, particularly for a small business where the website often is the storefront.
Regulatory exposure. If customer data is involved, a breach traced back to a known, unpatched vulnerability makes it harder to demonstrate under UK GDPR that you took “appropriate technical measures” to protect that data, which carries its own legal and financial consequences.
The reassuring part is that the fix here is genuinely simple and well understood: update PHP. The businesses most at risk are not the ones that will be attacked through some exotic technique, they are the ones that simply never get round to checking what PHP version they are running.
Disclosure Timeline
- 20 October 2026: PHP security team announces an emergency security release planned for the next day, citing two critical (CVSS 9.2) vulnerabilities.
- 20 October 2026: Details leak on a developer forum ahead of the planned embargo.
- 21 October 2026, 14:00 UTC: PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619 (PHP2Shell). Minimal emergency backports issued for PHP 7.4, 8.0, and 8.1.
- 21 October 2026: Cloudflare reports early exploitation attempts observed before and around the release, and deploys temporary WAF rules.
- 21-22 October 2026: National cyber agencies, including the UK NCSC and US CISA, issue advisories urging immediate patching. Public bodies and universities in the Netherlands, Finland, and Austria, plus hosting providers in Japan, take systems offline as a precaution.
Conclusion
PHP2Shell is about as serious as website vulnerabilities get: unauthenticated, remote, and affecting the software underneath roughly 70% of the web. The good news is that the fix is not complicated. Update PHP, confirm your server restarted, and add a WAF as a second layer if you don’t already have one. The businesses that get hurt by this are not the ones facing a sophisticated attacker, they are the ones who assumed someone else was handling it.
Hadosec has spent years securing PHP applications, from WordPress sites to custom-built platforms, and we know exactly where this kind of flaw tends to bite SMEs hardest. If you are not sure what PHP version your site is running, whether your host has patched, or how exposed your specific setup is, get in touch.
We can check your PHP version, confirm your host has patched, and help you put a WAF in place if you need one.
Get in touch →References
[1] W3Techs, "Usage statistics of server-side programming languages for websites," accessed October 2026. w3techs.com
[2] W3Techs, "Usage statistics of WordPress," accessed October 2026. w3techs.com
[3] PHP.net, "Upcoming Critical PHP Security Release," 20 October 2026. php.net
[4] BleepingComputer, "PHP ships emergency patches for critical PHP2Shell flaws," October 2026. bleepingcomputer.com
[5] Wiz Vulnerability Database, "CVE-2026-109618 (PHP2Shell)," October 2026. wiz.io
[6] GitHub Security Advisories (php/php-src), "GHSA-w8hw-w9fx-j79w: RCE via OOM Corruption," 21 October 2026. CVE-2026-109618. github.com
[7] GitHub Security Advisories (php/php-src), "GHSA-6wmf-4rv5-p3rp: RCE via Stale Global State," 21 October 2026. CVE-2026-109619. github.com
[8] SC World, "CISA advises orgs to patch PHP2Shell bugs immediately," October 2026. scworld.com
[9] Dark Reading, "'PHP2Shell' Bugs Signal Red Alert for Security Industry," October 2026. darkreading.com
[10] Pasquale Pillitteri, "PHP2Shell: Netherlands, Finland switch off government sites before patch," October 2026. pasqualepillitteri.it