What Happened on October 21?
On October 21, 2026, websites and online services around the world faced an urgent cybersecurity crisis as organizations rushed to protect their systems from a critical vulnerability in PHP, one of the technologies powering the web. Some organizations took services offline while preparing security updates.
All of it came down to one urgent task: updating PHP before attackers could exploit the flaws.
The bugs became known as PHP-to-Shell, or PHP2Shell. The PHP development team disclosed two critical vulnerabilities, both rated 9.2 out of 10 under the CVSS v4.0 severity scoring system. Tracked as CVE-2026-109618 and CVE-2026-109619, they could allow an attacker to execute code remotely on a vulnerable server without logging in.
What made this particularly serious was where the vulnerabilities existed. They were not simply bugs in WordPress plugins, website themes, or individual applications. They were flaws inside PHP itself — the runtime responsible for executing PHP code on the server.
That meant even a well-maintained website could remain vulnerable if the underlying PHP installation had not been patched.
Understanding the PHP-to-Shell Vulnerability
Think of your website as three floors. On top sits your app, such as WordPress, Drupal, Nextcloud, or your Laravel project. In the middle sits PHP, the engine that runs that code. At the bottom sits the server.
PHP-to-Shell is in the middle floor. Automattic put it plainly: this is a runtime fix. So, updating WordPress, your theme, or your plugins will not protect you on its own. Your own code can be perfect, and the server is still exposed.
Who Is at Risk?
The PHP team lists every PHP setup that serves web requests as potentially at risk. That covers PHP-FPM, Apache with mod_php, PHP-CGI, FrankenPHP, and LiteSpeed.
The risk is rated highest on Apache with mod_php, where an attack can start before a single line of your application runs. Wiz says every PHP version from the last decade is affected by at least one of the two bugs.
The flaw sits in how PHP cleans up when a request runs out of memory at the wrong moment. For what you do next, that one sentence is enough.
A Problem Years in the Making
None of this is new. In 2004, a security researcher found the first PHP vulnerability built on its memory limit. In 2020, someone filed a bug report about long variables running PHP out of memory, and not much was made of it.
In 2024, PHP had its first external security audit in years, paid for by Germany’s sovereign tech agency and carried out by QuarksLab. During that work, a core developer found the first signs of this exact problem. Nobody could show a real attack path, so it stayed a theory.
Why Did the Fix Take So Long?
Then, the fix stalled. The security team built several competing fixes. Each one either broke backward compatibility, opened a new way to crash servers, or forced changes on third-party extensions that nobody could coordinate.
The team makes decisions through a consensus-based process, and the few people who know the engine that deeply were busy with everything else. The PHP Foundation calls its own delay a structural failure caused by its decision process and its lack of resources.
Who Really Found the Vulnerability?
Calif, a security firm, started auditing PHP on July 30th as part of OpenAI’s Patch the Planet program. Its researcher reported a remote code execution bug on August 11th, found with GPT-5.6 Sol. OpenAI’s own team reported the same root cause that same day.
On August 24th, Wiz reported more attack paths using Google’s Gemini 4 Argon alongside GPT. Since March, Google owns Wiz. Earlier this year, the foundation had already scanned PHP with Anthropic’s Claude Methos.
Calif writes that it expected to find nothing critical because every lab had already run extensive model-assisted audits of PHP.
What Made the Difference?
The researcher knew PHP’s bug history, had a theory about where old bugs were hiding, and pointed the model at it. Calif says it used no custom tooling and no unreleased model.
So, the model didn’t uncover a mystery. It made proving an old suspicion cheap.
Wiz puts a number on that: with frontier models, one researcher did in a week what would have taken a team of top experts months.
How the Patch Release Fell Apart
By October, the fix was ready. The plan was a quiet, coordinated release on October 22nd, with Linux distributions holding the patch in advance and providers like Cloudflare preparing.
It came apart in the final week.
On October 17th, Amazon’s honeypots caught an exploitation attempt four days before disclosure. Amazon says it’s unclear how the attacker got the information.
On October 20th, both CVE numbers showed up on Hacker News with a wrong score of 10, and PHP moved the release up by a day. That evening, Califf published a video of its exploit by mistake, and copies spread after it was deleted.
The next morning, Chainguard shipped patched images more than six hours early, so anyone could study the fix before most people could install it.
Holding back a finished patch sounds odd. The distributions were still packaging it. And a patch nobody can install with one command mostly tells attackers where to look.
At 1400 UTC on October 21st, the update went out. Cloudflare had switched on firewall rules about nine hours earlier, free plans included, and says it watched attackers change their requests to get past them.
Why Websites Went Offline
The government advice was blunt. CISA told organizations that can’t update right away or that still run PHP 8.1 or older to take PHP systems offline until they’re patched. The United Kingdom’s National Cyber Security Center said much the same.
Taking a site offline was the official advice, not panic.
Were Websites Actually Hacked?
Security researchers have observed attempts to exploit PHP2Shell since its public disclosure on October 21. In its October 27 update, Wiz reported that the attempts it monitored had not completed the full exploit chain.
However, that does not prove that every attack failed or that no other systems were compromised. Findings from individual honeypots and security vendors cover only the activity they can observe.
Administrators should patch affected PHP installations and investigate suspicious activity dating back to before public disclosure. Applying a security update does not establish whether an attacker accessed a system beforehand.
What You Should Do Today
If you run the servers, the order is short.
Step 1: Update PHP
Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to your distribution’s patched package.
Step 2: Restart Every PHP Worker
Running workers keep the old code in memory until they restart. Updating the files alone is not enough.
Step 3: Check What Your Web Server Actually Runs
The PHP on your command line isn’t always the PHP behind your site. Containers need a rebuilt image and a fresh deploy. Official images reportedly took hours to catch up, so check the image you’re really running.
The Problem with Older PHP Versions
Older PHP versions present a particular challenge because many are no longer covered by the project’s standard security-release process. Some distributions and long-term support providers supply their own security backports. Administrators should verify the exact package and patch status rather than relying on the version number alone.
Patching Doesn’t Tell You Whether Someone Got In
Patching closes the door. It doesn’t tell you whether someone came through it first.
Amazon says to start investigating from October 17th, not from the release date. CISA says to watch for PHP worker processes starting shells or downloading tools. Wiz warns that application logs may hold little since the attack happens below the application.
Security vendors add the obvious next step: if you find signs, treat the server as compromised and change the keys and passwords it holds.
What If You Pay a Hosting Provider?
If you pay a host, this is your host’s job. Check the PHP version in your control panel or in WordPress Site Health and ask your host once.
Automattic says sites on WordPress.com and its other platforms were already protected. If you run Nextcloud or another app on a NAS, the vendor has to ship the update, and Nextcloud says it’s working on one.
What If You Only Have Accounts on Websites?
There’s nothing to install. Watch for fake password reset and maintenance emails this week. Those follow every story this big.
The Bottom Line: Update, Restart, and Investigate
Update. Restart every worker. Check the version your site really runs. Don’t bother with the credit debate tonight. It changes nothing on your server.
PHP 8.2 reaches end of life on December 31, 2026. Plan to migrate to a supported release
For two years, a small team was stuck choosing between bad fixes. Models made the proof cheap. The fix still needed people.
So, who found PHP-to-Shell? The model or the human who knew where to look?