PHP2Shell Explained: What Happened and What to Do Now

On Wednesday morning, government websites across Europe went dark. A payroll and HR provider took its service offline in the United States, Canada and Ireland. In the Netherlands, residents couldn't use the national digital ID login. As far as has been reported, none of these organizations had been compromised. They had read the same warning, and decided that being offline was safer than staying up with a flaw in the software underneath their sites.

The cause was PHP2Shell, the nickname for two critical flaws in PHP, the programming language that runs a huge share of the web, including most WordPress sites. This is not a breach in the usual sense, and no one has reported that your data was taken. It is a vulnerability, and it is being attacked at scale. Here is what happened, what is and isn't confirmed, and what to do whether you manage your own website or rely on someone else to.

What PHP is, and why this one reached so far

PHP is the engine that assembles a web page before it reaches your browser. Visitors never see it, and most business owners never touch it. According to the web technology tracker W3Techs, it runs close to 70 percent of the sites where the server-side language can be identified. That includes WordPress, Drupal, Joomla, WooCommerce and Adobe Commerce, as SC Media noted.

The two flaws involve how PHP handles memory when something goes wrong partway through a web request. An attacker can send a request designed to leave PHP's internal data in a broken state, then exploit the mess. According to The Hacker News, the practical consequences are:

• Running commands on your server. This is the "shell" in the name. A successful attacker could take control of the website.
• Reading memory. Memory in a PHP process can hold passwords, session tokens, API keys and certificates from other visitors' requests.
• No account needed. The attacker does not have to log in first.

The part that surprised many site owners: because the flaw is in PHP rather than in your site's code, a well-maintained site can still be exposed. For the most at-risk setup, Apache's mod_php, a single request can trigger the attack before WordPress or any security plugin has loaded.

How the week unfolded

• August Researchers at Wiz, and at Calif working with OpenAI, found the flaws and reported them to PHP privately. Both groups say AI models helped. Wiz's write-up describes demonstrations against stock WordPress, Drupal and Joomla.
• Oct 17 Amazon's honeypots recorded the earliest known exploitation attempt, four days before the public disclosure.
• Oct 20 The CVE numbers appeared in a forum post ahead of the planned October 22 disclosure. PHP moved its release up a day.
• Oct 21 Patches shipped around 2 p.m. UTC, which is 8 a.m. Mountain. CISA urged organizations to patch immediately. The NSA, the FBI and the UK's National Cyber Security Centre said that if an update isn't possible, systems should come offline until they are fixed. Cloudflare reported early attacks.
• Oct 22 Cloudflare reported attempts climbing from tens of thousands within 45 minutes to millions by the early hours of the day, according to Cybernews.
• Oct 23 PHP disclosed a third, narrower issue (more below).

Has anyone actually been breached?

That is reassuring, but only a little. Cloudflare watched attackers change their payloads to get around its emergency firewall rules, and Amazon's analysts said the attempts they saw came from multiple actors. Treat this as an urgent patching job, not a disaster that has already happened and not something that will blow over.

Why updating WordPress doesn't fix it

This is the part most "patch now" headlines skip. The patched PHP has to come from whoever runs the server: your hosting company, the server's operating system, or the container your site runs in. A WordPress update, a theme update or a security plugin cannot replace PHP. Security vendors have been blunt that automatic updates won't deliver this one.

Three things make that harder than it sounds:

• Hosts moved at different speeds. On release day, some package sources had fixed builds within minutes while others had none, and at least one hosting company said it was waiting on its vendor. Martin Cid Magazine tracked how unevenly the fix reached different hosting setups on day one.
• The version number can mislead. Linux distributions often patch a flaw without changing the version number, so a protected server can look outdated. The reverse can also happen: the PHP version you see from the command line may not be the one serving your website.
• Older versions get no official fix. PHP 8.1 and older no longer receive updates from the PHP project. Some vendors have backported fixes, and PHP published minimal source patches for 7.4, 8.0 and 8.1, but those are aimed at people who build PHP themselves. Even PHP 8.2, which did get a patch, loses security support on December 31, 2026. Internet-wide scans counted close to four in five exposed PHP services on versions that are no longer supported.

What to do: a plan for business owners

1. Find out who controls your PHP

   List everything that runs on a website or web application: your public site, online store, customer portal, booking forms, intranet, and any software from a vendor that is hosted for you. For each one, identify who is responsible for the server: a hosting company, a web agency, your IT provider, or the software vendor. PHP is also bundled inside control panels and some appliances, so the inventory is worth doing carefully.

2. Get written confirmation

   Do not assume your host patched automatically. Many did, but they decided when. Send a short note to each responsible party:

   Copy and send

   "Please confirm in writing: (1) which PHP version our site runs, (2) whether the October 21 fixes for CVE-2026-109618 and CVE-2026-109619 are applied, directly or as a vendor backport, (3) the date and time it was applied and that PHP was restarted afterward, and (4) your plan for us if we are on PHP 8.1 or older."

3. Check what you can see yourself

   In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section to see the PHP version. A patched build of a supported branch reads 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or higher. If yours is lower, that is not proof of a problem, because of the backport issue above, but it is a reason to ask your host for confirmation in step 2.

4. If you can't confirm a fix, decide on a stopgap

   Government agencies said to take affected systems offline until they are fixed. For a brochure site, that may be a reasonable call. For a store or booking system, it is a business decision to make with your IT provider. Partial measures exist, and they are real, but they are not a fix. A web application firewall such as Cloudflare's was described by its own CTO as a stopgap, and it only helps if your server refuses traffic that goes around it. PHP's own advisory says updating is the only complete answer.

5. Move off unsupported PHP

   If you are on PHP 8.1 or older, no official fix is coming. Plan the upgrade to a supported version, take a verified backup first (one you have actually test-restored, not just one that exists), and expect older themes or plugins to need testing. This is where sites that have gone unmaintained for years run into real work.

6. After patching, check whether anyone got in

   Patching closes the door. It doesn't tell you whether someone already walked through. Ask your host or IT provider to review server logs for the signs the researchers describe: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors, unusually large session cookies, and PHP workers restarting without explanation. If you find evidence, treat the server as compromised. As a precaution, that means changing passwords and rotating API keys and other credentials stored on it, since this class of flaw can expose memory contents.

The third flaw, briefly

On Friday, PHP disclosed another remote code execution issue, CVE-2026-115560. It is not fixed by the October 21 releases. PHP considers it unlikely to matter in practice because it requires an unusual combination of session settings and application code, so it is being handled in a normal release rather than an emergency one. The interim step is the same one PHP recommended on Wednesday: turn off session upload progress. If your IT team applied that earlier, nothing more is needed for now.

The lesson that outlasts this week

The easy takeaway is "patch faster," and it's true as far as it goes. The harder one is that most organizations can't patch what they can't find. Security leaders quoted by SC Media pointed to legacy applications, vendor appliances and internal tools nobody has touched in years as the places PHP hides. If a flaw like this lands next month, the businesses that recover quickly will be the ones that already know where their PHP lives and who is responsible for it. A routine vulnerability scanning and penetration testing program is one way to keep that list honest.

Two other things are worth noting. Attackers can compare a patch against the old code to learn what changed, which is part of why the window between disclosure and attacks keeps shrinking, and part of why AI-assisted research makes that window shorter still. And the PHP Foundation was candid about its own role: it said signs of one flaw surfaced in a 2024 audit, that work on a fix then stalled for months, and it called the delay a structural failure. Open-source software underpins most of the internet, and the people maintaining it are stretched.