PHP2Shell has website administrators scrambling after researchers confirmed attackers are successfully exploiting a pair of critical PHP flaws. If your company website runs on WordPress, Joomla, or Drupal, it runs on PHP, and so does an estimated 70% to 80% of the web. That’s why these vulnerabilities have triggered urgent action over the past week.
What Happened with PHP2Shell
On October 21, the PHP security team released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a web server without logging in. They were discovered by researchers from Calif, OpenAI, and Wiz, and they affect every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Both flaws come from the same root problem: when a web request ends abnormally, PHP can leave its memory in a corrupted state that an attacker can abuse. The PHP team says the risk is highest for mod_php, where “an unauthenticated request can trigger the attack before any application code runs.” In other words, it doesn’t matter how carefully your website itself was built. PHP2Shell bypasses application-level defenses entirely.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer receive official updates, although the PHP team published minimal source fixes for 7.4, 8.0, and 8.1, and some Linux distributions and long-term-support vendors provide their own backports.
A Leak, Then a Race
This was supposed to be a coordinated release. Instead, details including the CVE numbers and mitigation advice leaked online, and the PHP team had to move its schedule up. Amazon Threat Intelligence says the first exploitation attempts hit its sensors on October 17, four days before patches existed. AWS chief information security officer CJ Moses warned that “defenders should not assume the public disclosure date is the earliest date of exploitation.”
Cloudflare, Hadrian, watchTowr, Previdian, and Patchstack all saw attempts before public disclosure, but flagged them as unsuccessful. The UK’s National Cyber Security Centre told organizations to update PHP immediately or take systems offline until they could.
From Probes to Working Shells
For several days, the activity looked like noise: scanning, fingerprinting, and exploits that didn’t work. That changed when Adel Karimi, detection and response lead at Perplexity, published evidence from his honeypots, decoy servers running Apache mod_php on PHP 8.4.26, just one release behind the fix. “This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process,” he wrote.
Expel researcher Marcus Hutchins called it “by far the highest quality confirmation of in-the-wild php2shell exploitation I’ve seen so far.” Karimi was careful to add that his decoys were set up in a deliberately favorable way, so his results don’t measure how reliable the exploit is against other setups. CISA has shared a detection rule, but as of BleepingComputer’s October 26 report it had not yet added the flaws to its Known Exploited Vulnerabilities catalog.
There’s also a new one. On October 23, the PHP team shared mitigations for a third remote code execution flaw, CVE-2026-115560, which has no patch yet and only affects systems with “an unusual combination of configuration and application code.”
Why PHP2Shell Matters for Your Organization
Most small and midsize businesses don’t manage their own web servers. A hosting company, a web agency, or an IT provider does it for them, which means many owners have no idea which PHP version their site runs on. VirusTotal tracks more than 5.1 million PHP hosts exposed online, and attackers will work through that list for months. PHP2Shell gives them a high-value target that sits underneath popular CMS platforms.
A compromised website isn’t just a defacement risk. It can be used to serve malware to your customers, skim data from contact and payment forms, or give attackers a foothold toward the rest of your environment. We saw the same disclosure-to-exploitation speed with React2Shell last December, and the same lesson as this month’s record Patch Tuesday: a patch only helps once someone installs it.
What to Do This Week
- Find out who runs your web server, whether that’s your host, agency, or IT provider, and ask one direct question: “Which PHP version is our site on, and has the October 21 security release been applied?”
- Confirm you’re on PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or later. If you’re on PHP 8.1 or older, ask whether your vendor has backported the fix, and plan an upgrade either way.
- Don’t forget the sites nobody thinks about: old landing pages, staging copies, client portals, and internal tools.
- If you can’t patch today, ask your host to apply PHP’s published mitigations, such as disabling session upload progress. The PHP team is clear that these reduce exposure but don’t fully protect you from PHP2Shell.
- If a server ran an unpatched PHP version after October 17, have it checked for signs of compromise, not just updated.
- Make sure you have a recent, offline-tested backup of your website.
The Takeaway
PHP2Shell is a reminder that your website rests on software you never see. Attackers were testing these flaws before the patch existed, and working exploits followed within days. The businesses that come through it fine will be the ones that know who owns their web server and get a straight answer about patching this week.
Not sure what’s running underneath your website? Black Belt Secure can help you find out and close the gaps. Schedule a free assessment today.
Source: BleepingComputer, emergency patches (Oct 21); BleepingComputer, exploitation began before patches (Oct 22); BleepingComputer, now successfully exploited (Oct 26).