PHP2Shell: The Flaw Hiding Inside Your Website

Most small business owners do not think of themselves as running PHP. Most of them do.

If you have a WordPress site, a client portal, a booking widget, or a payment plugin, there is a good chance PHP is running underneath it. It is the plumbing of a huge share of the web, and like plumbing, nobody thinks about it until something bursts. In late October, something burst.

How it happened: a race nobody wanted

On October 21, 2026, the PHP development team shipped emergency patches for two critical flaws. The trouble is that the fix was not the first move. Details of the two vulnerabilities, together called PHP2Shell, leaked online ahead of the planned disclosure, which pulled the whole timeline forward.

Then it got worse. According to Amazon Threat Intelligence, its MadPot honeypot network recorded a PHP2Shell exploitation attempt on October 17, 2026, four days before the patches were released. Because the flaws were still under embargo at the time, the targeting of a honeypot from an anonymized IP address suggests a threat actor was behind the activity, though it remains unclear how the actor acquired exploit information prior to disclosure. In other words, someone was already trying this out before the public even knew the flaws existed.

The disruption showed up quickly. According to The Hacker News, BambooHR took its service offline across the United States, Canada, and Ireland as a precaution, and warned that payroll would be interrupted. In the Netherlands, MijnOverheid, DigiD, the lower house of parliament’s site, the national cyber-security center and several education systems went offline, as the broadcaster NOS reported. To be clear, no source has confirmed any of these organizations was actually broken into. They pulled systems down to be safe, not because they were compromised.

What PHP2Shell actually is

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS score of 9.2, which lands them in the critical range, and both can lead to remote code execution, meaning an attacker can run their own code on a web server. CERT-EU says that, based on the CVSS score, both could be exploited without authentication, so without logging in at all.

The reach is the alarming part. According to The Hacker News, the flaws affect nearly every PHP version back to PHP 5.4, and they sit in the PHP runtime itself rather than in any application, so a site is exposed even when its own code is clean. Servers using Apache’s mod_php face the highest risk, where a working exploit triggers the attack before any application code runs.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For three older branches that no longer get regular updates, PHP 7.4, 8.0, and 8.1, the PHP security team published source backports to help people building from source or waiting on a vendor. If your host is running one of those older branches, there is a path to a fix, but someone has to apply it.

One more thing to watch. After the initial release, PHP warned of a further flaw, CVE-2026-115560, that has no patch yet. This story is not finished.

The AI part worth understanding

Here is what makes PHP2Shell different from the usual critical flaw. These bugs are not new. According to Help Net Security, the underlying flaws had been present for decades, and Wiz researchers explained that demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models, they said, substantially reduced that barrier and turned a longstanding flaw into an exploit.

The speed is the part that should get a business owner’s attention. According to The Hacker News, the researchers say AI models helped turn these long-standing flaws into working exploits, letting one researcher do in about a week what they say would otherwise have taken a team months.

Amazon put the broader shift plainly in its own write-up. AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit, so more actors can act within hours or even minutes once technical details are disclosed. The old assumption, that you have days or weeks after a patch before the real danger arrives, is wearing thin.

Why this lands on your desk

Your website is not a brochure sitting off to the side. It is a front door. So is your vendors’ client portal, and so is whatever your web host runs underneath both. A compromised site can serve malware to your own customers under your own name, which turns a technical problem into a trust problem and then a reputation problem.

You do not need to understand use-after-free bugs or memory handling to take this seriously. You need to know who is responsible for the plumbing, and whether they have touched it since October 21. For most small and midsize businesses, that is a hosting company, a web agency, or a software vendor, and the answer is one email away.

What to do now

Send three questions to your web host and your software vendors this week. Keep it simple.

1. Are we running a patched version of PHP? The fixed versions are 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a backported fix if we are on an older branch.
2. Are you tracking CVE-2026-115560, the newer PHP flaw that has no patch yet, and what are you doing about it until one ships?
3. Have you checked for signs of compromise since the patches landed, given that exploit attempts were seen before disclosure?

If a vendor cannot answer those three questions clearly, that tells you something on its own. The point is not to become a PHP expert. The point is to confirm that someone, somewhere, owns the thing running underneath your website and has done something about it.

Common Questions

Do I run PHP if I just have a WordPress site? Almost certainly, yes. WordPress runs on PHP, and so do many booking, payment, and portal plugins. Updating WordPress itself does not update the PHP runtime beneath it, which is a separate layer your host controls.

My site seems fine. Do I still need to ask? Yes. According to The Hacker News, the flaws sit in the PHP runtime, not in your site’s code, so a site that looks and works perfectly can still be exposed. Looking fine is not the same as being patched.

Has anyone actually been breached through this? No source has confirmed a successful break-in at a named company. Security firms have reported exploit attempts, and some organizations took systems offline as a precaution. That is a reason to confirm your own patching, not a reason to assume disaster.

Who is responsible for fixing it, me or my host? In most cases the fix lives with whoever hosts your site or builds your software, because the PHP runtime comes from the server package, the host, or the container image. Your job is to ask and confirm it happened.

centrexIT has protected San Diego businesses since 2002. If you are not sure what your website runs on or who patched it last, that uncertainty is worth clearing up this week. Take the 2-Minute Cybersecurity Assessment: https://centrexit.com/cyber-security-readiness-assessment/

Sources

• Amazon Threat Intelligence recorded a PHP2Shell exploitation attempt on October 17, 2026, four days before public disclosure: AWS Security Blog, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot” (2026), https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• CVE-2026-109618 and CVE-2026-109619 are rated 9.2 and fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with source backports for 7.4, 8.0, and 8.1: The Hacker News, “PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge” (2026), https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
• One researcher built a working exploit in about a week, work that would otherwise have taken a team months: The Hacker News, “PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge” (2026), https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
• The flaws had been present for decades and frontier AI models substantially reduced the barrier to exploiting them: Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!” (2026), https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• CERT-EU says both flaws could be exploited without authentication: SecurityWeek, “PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws” (2026), https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/