On Wednesday, October 21, the PHP project shipped emergency fixes for two critical flaws in the software that runs a huge share of the web. Within hours, governments and companies were pulling websites offline to patch them. The Guardian reported (https://www.theguardian.com/technology/2026/oct/22/websites-across-world-hit-by-millions-of-attempts-to-exploit-php-code-flaw) that 32 UK government services went offline as a precaution, and that sites including the Internet Archive and Wikipedia were reportedly affected for a time. Cloudflare’s chief executive said the company saw tens of thousands of attempts to exploit the flaw in the 45 minutes after it was announced, “hundreds of thousands within two hours, and millions now.”
The vulnerability is called PHP2Shell. It is a server problem, and the people who run websites have urgent work to do. But it is also a story about everyone else: the employees who visit those websites every day, and the way AI is changing how fast flaws like this go from hidden to dangerous. Here is what happened, how the attack works in plain language, and why a patch being available does not mean the danger has passed.
What Is PHP2Shell?
PHP is a programming language that runs on web servers. It powers WordPress, Drupal, Joomla, and MediaWiki (the software behind Wikipedia), along with countless custom sites. Wiz Research, one of the teams that found the flaws, estimates PHP powers about 70 percent of the world’s websites.
PHP2Shell is the name for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 for severity. According to Wiz’s write-up (https://www.wiz.io/blog/php2shell-php-rce), they let an attacker who has no account and no password do two things to an affected server:
- Run their own code on it. That means taking over the server, stealing its data, or changing the website it serves.
- Read pieces of its memory. Wiz says that memory may contain “passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.”
What makes this different from the usual website vulnerability is where the flaw lives. Most website bugs sit in a specific plugin or application. These sit in PHP itself, below the application. Wiz showed the attack working against the latest versions of WordPress, Drupal, and Joomla, and noted that “even a simple ‘Hello World’ application running on an affected PHP version can be vulnerable.” Every PHP version from 5.4 through 8.5.11 is affected, which covers more than a decade of releases.
How Does the PHP2Shell Attack Work?
You don’t need to read memory dumps to understand the idea. A PHP server handles web requests one after another, and the same worker process often serves many visitors in a row. Think of it like a hotel room. One guest checks out, housekeeping resets the room, and the next guest checks in.
PHP2Shell is what happens when an attacker interrupts housekeeping halfway through. The PHP Foundation explains (https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) that if a request runs PHP out of memory “at exactly the wrong moment,” PHP can leave half-built internal data behind and later treat it as valid. In the second flaw, a fatal error leaves behind internal state pointing to memory from a previous request, and the next request handled by the same worker uses it. In hotel terms, the next guest walks into a room that still has the last guest’s belongings in it, and the hotel acts as if they belong there.
An attacker who can shape what gets left behind can turn that confusion into running their own commands. Or, with the memory flaw, they can get the server to hand back leftover data from other people’s requests. Wiz found that the server can be tricked into sending chunks of its memory back inside an ordinary-looking session cookie, even on sites that never use sessions.
Two details make this especially hard for defenders. First, it happens before the website’s own code runs, so the application’s logs may show little or nothing. Second, success can look normal. Datadog Security Labs built a working exploit to develop detections (https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/) and found that its refined version returned an ordinary “200 OK” response while the server kept running. Nothing crashed. Nothing looked wrong.
Why Did It Take AI to Find a Decade-Old Flaw?
The vulnerable code had been in PHP for more than ten years. The PHP Foundation says a core developer first spotted signs of the underlying problem in 2024, during an external security audit. At the time, nobody could show a realistic way to exploit it, competing fixes each came with painful trade-offs, and the work stalled. The Foundation is candid about it: “the delay was a structural failure.”
What changed in 2026 was the tooling. Between August and September, researchers at Calif, OpenAI, and Wiz reported the problem to PHP along with working ways to exploit it. Wiz used frontier AI models throughout its research, and says turning the flaw into a working attack required a chain of steps “at the edge of what human researchers could practically achieve.” AI made it practical:
“With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work.”
This time, the people using AI were defenders who reported the flaw so it could be fixed. But the same capability is available to attackers, and that is the real lesson of PHP2Shell. Amazon’s threat intelligence team put it bluntly (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/): “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 of a vulnerability are disclosed.” Its advice to security leaders is to measure patch timelines for critical, internet-facing systems in hours, because “a 7-day or 30-day SLA assumes a delay that no longer exists.”
The flood is already visible. The PHP security team has published 15 CVEs since July 1, and has worked through more than 100 additional reports that turned out to be invalid, duplicates, or impossible to reproduce. Old, complicated code that once seemed too hard to exploit is now being examined at machine speed. Expect more vulnerabilities like this one, in more of the software the web depends on, and expect the gap between disclosure and attack to keep shrinking.
If There’s a Patch, Why Is PHP2Shell Still a Problem?
PHP released fixed versions (8.5.12, 8.4.27, 8.3.36, and 8.2.35) on October 21, and CISA urged organizations to patch immediately (https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching). A fix existing and a fix being installed are two very different things, though, and there are several reasons this one will linger.
Attacks started before the patch
The coordinated disclosure leaked. On October 20, the CVE numbers started circulating online, and one of the research firms mistakenly published a demonstration video that was copied before it was taken down. The PHP project moved its release up by a day. Amazon says it saw an exploitation attempt against one of its honeypots on October 17, four days before the public announcement. Its conclusion: investigations should start from October 17, not from the disclosure date.
Most servers weren’t patched on day one
According to SecurityWeek (https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/), Censys found that of roughly 1.58 million internet-facing hosts reporting an identifiable PHP version on October 21, about 1.57 million were not patched. That is understandable on the first day. But the long tail is where risk lives.
Many servers can’t simply be patched
PHP is not releasing fixes for version 8.1 or earlier, which are past end of life. VirusTotal told SecurityWeek that of about 1.1 million servers that announce their PHP version, around 758,000 are running one of those unsupported versions. CISA’s advice for systems that can’t be updated is to take them offline. The UK’s National Cyber Security Centre warned that the patch would not work for some organizations running older systems, which would need to be replaced, and the Guardian noted particular concern for schools, local governments, and charities without dedicated security staff.
Nobody knows where all their PHP is
PHP hides inside other things: content management systems, hosting control panels, vendor appliances, a marketing microsite someone built five years ago. As BlueVoyant’s CISO told SecurityWeek, “the harder problem is finding everything that needs patching.” Plenty of organizations will patch the servers they know about and miss the ones they don’t.
To be fair about the current state: on October 22, watchTowr said the exploits being sprayed across the internet either don’t work, only probe for the flaw, or crash the target, and one of the original researchers told the Guardian that exploitation did not yet appear widespread. That is good news, and it is also a countdown. Researchers have already built working exploits privately, and AI makes it faster for attackers to build their own.
What Happens to a Website After It’s Hacked?
When attackers take over a web server, they rarely just deface it. Hacked servers are useful. Attackers install cryptominers, steal the data and credentials stored on the server, and use the machine to attack others. But one of the most common uses has nothing to do with the server’s owner at all. It targets the people who visit the site.
Switzerland’s National Cyber Security Centre reported in August (https://www.bacs.admin.ch/en/clickfix-en) that more than 100,000 websites worldwide had been compromised to show visitors fake CAPTCHA checks. Most of the affected sites it sees run WordPress, which runs on PHP. The fake checks imitate Cloudflare, adapt to the visitor’s language, and give Windows and Mac users different instructions that end with the visitor running a command that installs malware. We broke down this technique, known as ClickFix, in our ClickFix explainer.
These are not small operations. Check Point Research uncovered a single operation (https://research.checkpoint.com/2026/thousands-of-hacked-wordpress-sites-one-operation-unmasking-stopandprotect/) that kept a list of close to 2,000 compromised WordPress sites, used them to show visitors fake CAPTCHAs, and then stole files or deployed ransomware on the computers that fell for it. Sekoia tracked another framework (https://www.sekoia.com/blog/meet-iclickfix-a-widespread-wordpress-targeting-framework-using-the-clickfix-tactic) on more than 3,800 WordPress sites in 82 countries, installing remote access software on visitors’ machines. And New Zealand’s National Cyber Security Centre warns (https://www.ncsc.govt.nz/alerts/compromised-websites-serving-clickfix-pages/) that these sites often show a clean page to security scanners and search engines, and save the trap for real people in real browsers.
Those campaigns didn’t need PHP2Shell. As Check Point notes, many WordPress sites are vulnerable simply because their owners don’t keep them and their plugins updated. We have not seen public reports of PHP2Shell being used this way yet. But a flaw that opens up the PHP layer underneath sites like these could feed exactly this playbook, at a scale those campaigns never had.
Why Is the Browser the Front Line?
Think about what this means for an employee. Most security awareness training teaches people to be suspicious of messages: check the sender, hover over the link, question the urgency. None of that helps here. There is no suspicious sender. The employee typed the address themselves, or clicked a bookmark they have used for years. The domain is correct, the padlock is there, and it might be a supplier’s site, an industry association, a local news page, or a school portal. The website is real. That is the problem.
What changes is what the page asks them to do. A verification check that wants them to press keyboard shortcuts. A pop-up saying their browser needs an update. A sign-in prompt on a site that never asked for one before. A download that doesn’t match what they came for. Those moments happen in the browser, on a trusted site, with no email anywhere in the chain. It is why we keep saying phishing doesn’t end at the inbox, and why awareness programs that only test email leave the biggest gap untested.
The memory flaw adds a quieter risk. If a vulnerable server leaks leftover data from other visitors’ requests, then passwords and session tokens people sent to that site could be exposed through no fault of their own. If those people reuse that password at work, one unpatched website becomes a way into your company. Unique passwords, a password manager, and phishing-resistant multi-factor authentication matter more this week, not less.
What Should Organizations Do About PHP2Shell Now?
For the teams that run websites and servers:
- Inventory every place PHP runs, including vendor products, hosting control panels, and forgotten microsites. CISA notes that PHP “is often a component of other software.”
- Patch internet-facing systems first, then restart or replace every PHP worker so the old code stops running.
- Take unsupported versions offline if you can’t upgrade them, as CISA recommends. A web application firewall can help in the meantime, but it is a stopgap.
- Investigate from October 17, not from the disclosure date. Look for PHP processes launching shells or downloading tools, and for changed files you didn’t make.
- Rotate secrets on exposed servers. If memory could have leaked, treat the passwords, API keys, and tokens on those servers as compromised.
- Ask your vendors. If an agency, host, or SaaS provider runs your website or customer portal, ask them in writing whether it was affected and when it was patched.
For everyone else, a few habits to share with your team this week:
- A trusted site can still be compromised. Judge what a page asks you to do, not how familiar it looks.
- No real website asks you to paste a command. If a “verify you are human” check wants keyboard shortcuts, close the tab and report it.
- Be wary of surprise prompts on familiar sites: browser updates, sign-in requests, or downloads you didn’t go looking for.
- Don’t reuse passwords, and turn on multi-factor authentication everywhere it is offered.
- Report anything odd. One report about a strange page on a supplier’s site can protect everyone else who visits it.
This Won’t Be the Last One
PHP2Shell will eventually fade from the headlines, but the conditions that created it will not. AI is making it faster to find old flaws and faster to weaponize new ones, and the gap between a patch and an attack is now measured in hours. Meanwhile, the long tail of unpatched, unsupported, and forgotten servers will keep handing attackers trusted websites to work from.
That is why security awareness has to cover more than the inbox. So much of the workday now happens in a browser, and the browser is where a compromised website, a fake verification check, or a stolen session turns into an incident. Your people cannot patch the internet. What they can do is recognize the moment a page asks for something it shouldn’t, and they should have protection that steps in when that moment comes.
How SavvyShield helps: SavvyShield protects the moment a compromised or malicious site turns on the person visiting it. Our browser extension analyzes pages in real time and steps in when an employee reaches a fake CAPTCHA or verification lure, a fake sign-in page, or a malicious ad, even when the site’s address looks familiar and no email was involved. Each blocked attempt comes with a short explanation of what gave it away. Realistic simulations run in the browser as well as the inbox, so your team practices the situations they actually face, and bite-sized training keeps those lessons current as attacks like this one evolve. Want a quick read on your team? Try our free cyber savviness quiz.
