PHP2Shell: What Happened, Why, and How We Responded

On October 21, the people who maintain PHP released fixes for two serious security flaws in PHP itself. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and they quickly picked up a nickname: "PHP2Shell." By that evening, government security agencies in the US, the UK, Australia, and the EU were telling everyone who runs PHP to update right away. Attackers had started testing the flaws before the fixes were even out.

PHP is the programming language behind WordPress, WooCommerce, Laravel, and most of the sites we build and maintain at Curious Minds Media, so this one landed on our desk the moment it was announced. Here's what happened, why it happened, what our hosting partners did, and how our team handled the sites we look after.

Where things stand

The US Cybersecurity and Infrastructure Security Agency (CISA) has confirmed that attackers are using PHP2Shell in real attacks. The PHP project rates both flaws 9.2 out of 10 for severity. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older versions (7.4, 8.0, and 8.1) didn't get an official update, but the PHP team shared basic fixes that hosting companies could apply on their own. The fix has to be installed by whoever runs the server, which is usually your hosting company.

What is PHP2Shell?

PHP2Shell is the name for two flaws in PHP that let an attacker take over a web server by sending it a specially built request, with no password or account needed. Because the problem is in PHP itself, any site on an unpatched server was at risk, whether it was built on WordPress, Drupal, Laravel, or custom code. The NSA's advisory warns that an attacker with that access could steal data, take services offline, or reach deeper into an organization's network.

How the week unfolded

Amazon's security team saw the first attack attempt on October 17, four days before any fix existed. On October 20, details about the flaws leaked online ahead of the planned announcement, and PHP said it would release fixes the next morning. The updates went out at 10:00 a.m. Eastern on October 21, and security agencies in the US, the UK, Australia, and Europe issued warnings the same day.

Some organizations took their sites offline rather than wait, including Australia's cyber.gov.au, government sites in Finland and the Netherlands, and parts of Wikipedia, iTWire reported. The security company Patchstack was already getting reports of attacks from hosting companies that morning, according to WebHosting.Today's timeline, and Wordfence has since reported blocking more than 74,000 attack attempts, Hostinger noted.

At first, it wasn't clear whether any of those attacks were working. On October 22, Sansec shared one researcher's test showing that the attack code posted online didn't work on a standard PHP setup. Then, on October 24, researcher Adel Karimi caught attackers taking control of test servers he had set up as bait, known as honeypots, and the activity matched the first of the two flaws. BleepingComputer reported it on October 26 as the first confirmed successful attack.

That same day, CISA added both flaws to its list of vulnerabilities being used in real attacks and gave federal agencies until October 29 to patch. A week earlier, it had said it hadn't seen any successful attacks yet. CISA hasn't said who was hit, and it's urging private organizations to make these updates a priority too.

Why did PHP2Shell happen?

Both flaws come from how PHP manages memory while it builds a page. The first, CVE-2026-109618, happens when PHP runs out of memory partway through a request and doesn't clean up properly. The second, CVE-2026-109619, happens when PHP holds on to leftover data from one request and uses it again on the next one. An attacker can take advantage of either mistake to run their own code. The risk is highest when PHP runs through Apache’s mod_php, one of the two most common setups, though the PHP project says the other, PHP-FPM, is also at risk.

The flaws can also let an attacker read whatever is sitting in the server's memory, which can include passwords, login sessions, and API keys. Installing the fix doesn't undo anything an attacker already saw, which is why changing passwords and keys is on the checklist below.

Memory bugs like these are very hard to spot by reading code. Tenable's Gavin Millard said they had been in PHP "for more than a decade," according to iTWire. This year, researchers at Calif and Wiz found them separately, with Calif using an AI model from OpenAI to help. When the details leaked early, PHP rushed its release, which gave hosting companies less time to prepare.

Is WordPress affected?

Yes, but only through the version of PHP it runs on. WordPress.org said on October 21 that the flaws aren't a WordPress problem and that no WordPress update is coming for them, so a site with the latest WordPress, theme, and plugins was still at risk on an unpatched server. Security plugins couldn't help either. As MalCare explains, the attack happens before WordPress or any plugin has even started, so protection had to come from the server or from a firewall in front of it.

How WP Engine and BigScoots responded

Most of the sites we maintain are hosted on WP Engine or on BigScoots with Cloudflare Enterprise, and both had protections in place before the official fixes came out. WP Engine added filters through Cloudflare and Fastly on the morning of October 21, then updated PHP across its platform during the day. By 8:19 p.m. Central, it reported that sites were running patched versions.

BigScoots added a firewall rule to block the known attack and turned off a rarely used PHP feature called session upload progress, which one of the attacks depends on. The one side effect BigScoots flagged is that a few plugins may stop showing a progress bar during uploads, though the uploads still work. It also turned on Cloudflare's emergency firewall rules and blocked the internet addresses of anyone caught probing for the flaw. BigScoots began installing patched PHP the same day, including fixes for 7.4 and 8.1, and it's recommending that sites on PHP 7.3 or older move to 8.2 or newer. Each step is posted on its status page. For clients on our managed hosting, the hosting side was covered within hours.

The October 23 follow-up: CVE-2026-115560

Two days after the fixes, PHP announced a related issue, CVE-2026-115560. It only affects sites with an unusual combination of settings, and the October 21 updates don't fix it. Until PHP's next regular update, the workaround is to turn off session upload progress. BigScoots had already done that on October 21, and WP Engine said its customers were already protected.

How we responded

When PHP announced the emergency release on the evening of October 20, we started following it closely, along with our hosting partners' status pages. Early on the 21st, WP Engine's support team confirmed that its firewall rules were active. Before the 10:00 a.m. release, we made a list of every site we look after that isn't behind BigScoots' or WP Engine's firewalls, so we'd know exactly where to focus once the fixes were out. Later that morning, WP Engine confirmed that PHP 7.4 would get the fix too, and we started checking with our other hosting providers about older versions.

On October 22, our security monitoring tool was still flagging sites from the previous day's scans, and we suspected many of those warnings were out of date. A fresh scan cut the list by more than two-thirds. For the sites still on it, our developers updated PHP on a test copy first, made sure everything worked, and then updated the live site. For the few sites on hosting we don't control, we asked the client to get confirmation from their host, or we worked with the host directly.

On October 23, BigScoots confirmed that its services were fully updated, including PHP 7.4 and 8.1, which took care of the last sites we'd been watching. We also emailed our current clients to explain what happened and what we were doing for each site.

If we manage both your site and your hosting, you don't need to do anything. If your site is hosted somewhere else, we'll reach out about anything that needs your host's help or your approval.

Who patches PHP?

It depends on where your site is hosted, because the fix has to be installed on the server. On managed WordPress hosting like WP Engine or BigScoots, the host takes care of it, and sites we manage on those platforms are already covered. On shared hosting with cPanel or Plesk, the host usually handles it, but ask them to confirm in writing.

If your site runs on its own server, such as a VPS, a dedicated server, or one managed through Laravel Forge, you or your developer need to install the update and restart PHP. Forge's automatic updates don't cover PHP, so each server has to be updated by hand. Sites running in Docker containers need to be rebuilt with the patched version and redeployed.

What to check now

If a hosting company or another developer manages your site, ask them in writing whether the October 21 PHP fixes are installed and which PHP version your site is on. You can see the version in WordPress under Tools, then Site Health, then Info, then Server, but some hosts install fixes without changing the version number, so a written answer is more reliable. The fix also doesn't take effect until PHP restarts, and staging copies of your site need it too.

If your site is on PHP 8.1 or older, plan an upgrade. Security support for PHP 8.2 ends on December 31, 2026, so aim for 8.3 or newer.

If your site was on unpatched PHP without a firewall in front of it, check your server logs back to October 17, look for admin accounts or files you don't recognize, and change the passwords, database logins, and API keys your site uses. Watch out for phishing emails that use this news as cover, too. And if your site is on a self-managed cPanel server or another older setup, this is a good moment to ask whether managed hosting makes more sense.

The Node.js advisory released the same day

Node.js, another platform used to build websites and apps, released its own security updates on October 21. The most serious fix, for CVE-2026-111497, covers a flaw in Brotli, a Google tool for compressing data that's built into Node.js. According to Vercel, researchers used it to read data and run their own code. The fixed versions are Node.js 22.23.4, 24.22.1, and 26.12.1, and Node.js 18 and 20 won't get the fix. Because Brotli is built into so much software, the flaw also reaches tools like Microsoft .NET and Python, Canada's Cyber Centre warns, and CISA added it to its list of actively exploited vulnerabilities on October 27.

We flagged this to our team the same morning, since it affects WordPress themes built with Sage or other Node-based tools, headless and JavaScript sites, and custom Node.js apps. We're going through affected projects one at a time and planning Node.js upgrades with each client.

How we approach security on the sites we maintain

Curious Minds Media has been maintaining WordPress and PHP sites since 2004 with an in-house team of US-based developers, and security monitoring is part of every WordPress maintenance plan we offer. When these warnings came out, we already knew which host and PHP version each of our sites was on, which let us quickly sort the sites our hosting partners had protected from the ones that needed our attention that day. For business-critical sites, our Enterprise Website Care program covers both the hosting and the site itself.

We'll update this post when PHP releases the fix for CVE-2026-115560. If you have questions about your own site, reach out to your project lead or email our support team at support@curiousm.com, and we'll walk through it with you.