PHP2Shell: A Years-Old Vulnerability, a Global Emergency, and What to Do Now

A memory flaw was first spotted in PHP in 2024. Two years passed without a fix. Then AI-assisted research turned it into a working exploit. Now, more than 22.6 million internet-exposed instances are potentially at risk. Currently, attackers are probing vulnerable servers, and public websites across Europe have gone dark while teams patch.

The scramble traces back to two critical flaws in PHP, known together as PHP2Shell. On October 21, PHP developers released patches for both CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 for severity. PHP powers roughly 70% of websites that use a known server-side programming language, including sites built on WordPress, Drupal, and Joomla. And because the flaws sit in PHP itself rather than in a plugin or app, attackers could run malicious code without logging in. From there, they could take over a vulnerable server or pull sensitive data straight from its memory.

PHP2Shell is more than a patching problem. AI-assisted research can turn old flaws into working exploits faster than teams can test and ship fixes. And a breached public web server can give attackers a path to databases, internal apps, and cloud workloads. Patching has to come with a second plan: see those paths, limit lateral movement, and contain a breach before it spreads.

“It's almost like somebody found a universal key to all our front doors,” said Christer Swartz, Illumio director of industry solutions.

The race to patch began with a leak. On October 20, the two CVE identifiers began circulating online. PHP moved its release up by a day. That evening, security firm Calif posted a video of a working exploit by mistake. Copies spread on social media. The next morning, Chainguard published software images with the fix more than six hours before the coordinated release. Attackers could study the fix before most teams had a chance to patch.

The fallout reached public services fast. Government agencies, universities, and other public websites across Europe went offline as teams rushed to patch. Security agencies urged immediate updates. Cloudflare saw attack traffic against its customers before the patches shipped. Amazon Threat Intelligence says it spotted an exploit attempt on October 17, four days before the flaws went public. It now reports broad exploitation in the wild. It's not yet clear how many attempts succeeded.

The warning that went unresolved

The clock started long before the public knew about PHP2Shell.

In 2024, a PHP developer found the first signs of the memory problem while fixing a different issue from a security audit. The team weighed several fixes. Each one risked breaking compatibility, creating new denial-of-service risks, or forcing changes on third-party extensions. With no known path to remote code execution, the work stalled.

Then the stakes changed.

In August, AI-assisted research showed what the flaw could do. On August 11, researchers at Calif and OpenAI separately reported a remote code execution path with the same root cause. Days later, Wiz used frontier AI models to find more attack paths. Its team showed working attacks on WordPress, Drupal, and Joomla sites. The bug was now a way into a live web server.

The PHP team and researchers began to work on patches. They aimed to give site owners time to prepare. But the plan fell apart when details escaped before the release.

The path from warning to crisis

• 2024: While fixing an audit finding, a PHP developer spots the memory flaw. A fix stalls.
• August 2026: Calif, OpenAI, and Wiz use AI-assisted research to show remote code execution.
• August to October 2026: PHP maintainers and researchers work on a fix for an October 22 release.
• October 17: Amazon detects an exploit attempt on a honeypot.
• October 20: The CVE identifiers leak. PHP moves the release up a day. Calif posts an exploit video by mistake.
• October 21: Chainguard publishes fixed images early. PHP releases patches as websites go offline and exploit attempts surge.

The PHP Foundation has since acknowledged gaps in how it dealt with the old warning. Its account also shows how hard it is to keep a fix under wraps once proof of an exploit spreads. A patch needs testing. Attackers need only one server that has not yet been patched.

Not every PHP site faces the same risk. Risk depends on the version in use, the server setup, and the controls around it. But the crisis put a harsh limit on the time teams had to act.

A web server can be a path into the network

Think of a customer portal. It may connect to a database for account records, an API for payments, and cloud apps for other tasks. Those links let the site work. They may also give an intruder a route past the front door.

Swartz warned that an attacker who takes over a web server can follow the paths the app already uses.

“And if this threat lands on a customer-facing … web server, and you can't spot it, it's just going to start following the same paths deeper and deeper into your network that you've left open,” he said.

The attacker might search for API keys or login tokens in server memory. Wiz showed these flaws can leak exactly that kind of data. The attacker might also test which systems the server can reach. If access is too broad, one breach could put customer data, internal apps, and critical assets at risk.

Patch status alone won't tell you how far that could go. Teams also need to know what a server can reach after it's breached.

That includes any links between IT and operational technology (OT), where a poorly secured path could expose plant systems.

AI has changed the pace of the race

AI helped researchers uncover the risk. That gave defenders a chance to fix it. But the same tools can help attackers find ways in.

Swartz sees a new problem for teams that rely on manual response.

“I'd say what it means for the vulnerability window is it's way shorter now than any human can respond to it,” he said. He was more direct about the cost of delay: “If you rely on a person… a human typing on a keyboard, you've lost.”

The problem is speed. Analysts still need to assess risk and investigate attacks. But by the time someone spots an unfamiliar connection and acts on it, an attacker may have moved on.

How to limit the damage

1. Start with the exposed servers

The first move is to find affected PHP servers and apply the security updates. If a public-facing server can’t be patched, restricting access or taking it offline may be the safer choice.

Swartz would rank the work by exposure, not just the number of servers. A site linked to a sensitive database or other critical asset deserves close attention.

“You have to patch, but you also have to ask what that server can reach,” he said. “If it connects to critical assets, the risk is much bigger than the vulnerability on that one machine.” For load-balanced sites, he recommends patching one group of servers while the others keep the site running. Then teams can switch traffic and patch the rest.

2. See where an attacker could go next

Swartz’s next concern is the web server’s links to APIs, databases, internal apps, and cloud workloads. Those paths often make sense for the business. They can also become routes for lateral movement.

“If you don’t know which systems your web server talks to, you don’t know how far an attacker could get,” he said. “Map those connections first. Then you can see which ones need to be there and which ones put critical assets at risk.”

3. Watch for changes in traffic

He would also look for traffic that breaks a server’s normal pattern: new workload connections, strange destinations, or a sudden jump in volume.

He gave DNS as one example. A server that usually sends small DNS requests but starts moving large amounts of data may need a closer look. It isn't a PHP2Shell-specific sign, and it doesn't prove a breach. For PHP2Shell, Wiz suggests watching for unusual upload requests followed by memory-limit errors or repeated HTTP 500 responses.

“You may not know which vulnerability an attacker used,” he said. “But you can still see a workload doing something it’s never done before. That’s the kind of change you need to catch before the attack spreads.”

4. Cut off unnecessary paths

“The best practice, I would say, is to segment your applications independent of underlying segments,” Swartz said. In other words, set controls around each app, whatever network it sits on.

He argues that a firewall at the edge, a VLAN, or a cloud network boundary doesn't always control access between apps. Workload-level segmentation can restrict each server to the services it needs.

“A web server may need to talk to one database,” he said. “That doesn’t mean it should be able to reach every database. If the server is compromised, those limits can stop the attacker from using it as a bridge to the rest of the network.”

5. Assume the patch may not be the end

Swartz also cautions that a patch closes a vulnerability but can't remove an attacker who got in before the fix. Teams still need to check logs, processes, access tokens, and new connections.

“Once a server has been exposed, don’t assume the patch means you’re done,” he said. “Look for signs that someone got in, check where they went, and isolate the workload if you find a threat.”

The aim, he says, is to contain a breach without cutting off every service the business needs.

Contain what you can't patch in time

PHP2Shell puts two clocks in motion. One tracks how long teams need to test and deploy a patch. The other tracks how fast an attacker can find a way in.

Swartz compared PHP2Shell to a universal key to the front doors. Teams can't always change the locks before someone tries the key. But if they know the paths between workloads, limit access, and act fast on unusual traffic, one open door doesn't have to open the whole house.