PHP2Shell: How Two PHP Bugs Almost Broke the Internet

10 min read · Last updated: October 24, 2026

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that let anyone run code on an unpatched PHP server over the internet without a password. The PHP Foundation shipped patches on Wednesday, October 21, 2026. Mass exploitation has been avoided so far, but confirmed compromises appeared by Friday.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The report

• TechCrunch: PHP-ocalypse, how two critical web bugs almost broke the internet, by Zack Whittaker, October 24, 2026

What that report cites

• Calif's research write-up, Amazon's threat blog post, Cloudflare CEO Matthew Prince, Palo Alto Networks, Trail of Bits and the NSA. I worked only from the report, so every claim from them below is as TechCrunch quoted it.

Around 70% of the web-facing internet relies on PHP. On Wednesday, October 21, 2026, that number stopped being trivia.

In Edegem, Belgium, the Smartschool education platform went dark. Banks, retailers, gaming sites, online stores, hospitals and some government agencies did the same thing on purpose. They pulled their own servers offline because staying up was more dangerous than going down.

Governments started telling anyone with a website to act. Millions of people around the world scrambled to patch before attackers got there first.

Here is the part that should bother every developer. The two bugs behind all of this were not new. They had been found in 2024, looked at, judged harmless, and left alone.

Key takeaways

• PHP2Shell is two bugs, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on unpatched PHP systems.
• PHP runs about 70% of the web-facing internet, including WordPress, Drupal, Joomla and MediaWiki, the software behind Wikipedia.
• The bugs were first found in 2024 but were not considered exploitable, so they were never patched.
• Amazon saw exploitation starting around October 17, 2026, about a week before patches were public.
• By late Friday, October 23, Palo Alto Networks and Trail of Bits confirmed real compromises.
• The NSA says around 75% of actively exploited vulnerabilities abuse memory-related flaws, the class of bug that keeps hitting older software like PHP.

What is PHP2Shell?

PHP2Shell is the nickname for two vulnerabilities in PHP, the open-source programming language used to build a large share of websites and web apps. Together they let an attacker break into any online system running unpatched PHP, such as a website or internet-facing server, and read or change its data without needing a password.

The official identifiers are CVE-2026-109618 and CVE-2026-109619.

PHP is free, relatively easy to use, and has been around for decades. That is why it ended up everywhere: on public websites, and also on company intranets and internal sites that never face the internet.

Its usage has been slowly declining in favour of newer, more secure languages. But slowly declining from 70% still leaves most of the web.

If you want the bigger picture of where PHP sits among other languages and what they are built on, I covered that in programming languages and the languages used to build them.

Why are the PHP2Shell bugs so serious?

The bugs are serious because they combine the two worst properties a vulnerability can have. They are remote code execution, so an attacker anywhere in the world can take effective control of a server. And they are unauthenticated, so the attacker needs no password, no login and no click from the victim.

Most bugs need something from you. You open a file. You click a link. You are logged in as an admin.

PHP2Shell needs none of that. If the server is online and unpatched, it is reachable.

Once inside, an attacker can plant malware to steal data, or quietly keep a foothold they can come back to later. The second one is the scary one, because a patch applied today does not remove a backdoor planted yesterday.

Why was 70% of the web exposed?

About 70% of the web was exposed because PHP sits underneath the software that runs most websites. WordPress, Drupal, Joomla and MediaWiki all rely on it. So does a long tail of developer tools, command-line packages, routers, storage devices, firewalls and VPNs that most people never think of as "PHP".

That last group is the one I would worry about.

Your WordPress site has an update button. Your office firewall or a storage box in a cupboard might not. Some legacy systems have no way to be updated at all.

There is also a money problem underneath this. PHP is one of many ageing tools that act as the glue holding the internet together. They are often built by open-source maintainers who are not paid, who cannot afford third-party security reviews, and who are relied on by companies that contribute nothing back.

Why were bugs from 2024 still unpatched in 2026?

They were unpatched because nobody thought they could be used. The two bugs were discovered in 2024 but were not considered exploitable at the time, so they sat in the code. Then researchers at Calif found a way to exploit them during a security audit of PHP's code, and the harmless bugs became critical ones.

This is the twist, and it is the lesson I keep coming back to.

"Not exploitable" is not a permanent property of a bug. It is a statement about what attackers know how to do today. Knowledge moves. The bug stays exactly where it was.

Calif was taking part in Hack the Planet, an initiative run by OpenAI, the AI model maker, and Wiz, the cloud security company. Wiz then verified the proof-of-concept exploits Calif built. Calif reported the bugs to the PHP Foundation, which maintains PHP.

PHP2Shell timeline: what happened and when

Here is everything with a date attached, in order.

When	What happened	Who said so
2024	Both bugs discovered, judged not exploitable, left unpatched	TechCrunch
Earlier in 2026	Calif finds a working exploit during a PHP code audit for Hack the Planet; Wiz verifies it	TechCrunch, Calif's write-up
Weeks before disclosure	PHP Foundation builds fixes under embargo and gives big internet companies and web hosts an early start	TechCrunch
Around October 17, 2026	Earliest exploitation Amazon says defenders should look for	Amazon blog post
Hours before the embargo ended	One company pushes the patches live early, according to the PHP Foundation	PHP Foundation via TechCrunch
Wednesday, October 21, 2026	Patches released publicly; governments urge action; banks, hospitals, retailers and agencies go offline to patch	TechCrunch
Week of October 21	Cloudflare sees an exponential rise in exploit attempts after disclosure	Matthew Prince, Cloudflare CEO
Late Friday, October 23, 2026	Confirmed compromises and post-exploit activity	Palo Alto Networks, Trail of Bits

Look at the gap between October 17 and October 21. Amazon described it as about a week before patches were available. Someone, somewhere, already knew how to use these bugs while the rest of the world was still waiting for a fix.

How were the PHP bugs exploited before the patch?

Nobody knows yet. Amazon detected exploitation about a week before the patches were public and said it was not clear how the attacker learned about the bugs. There are four theories. Only one has a named culprit, and that one does not explain the full week of activity Amazon saw.

Theory	How it would work	Does it explain October 17?
Patch diffing	PHP is open source, so once a fix is visible, attackers can see where the bug was and how it was closed	Only after a fix is visible
A leak during the embargo	The open-source community is huge and embargoes rely on good faith	Yes
Independent discovery or espionage	Attackers found the bugs themselves, or stole the research	Yes
A company shipped early	The PHP Foundation blamed one company for pushing patches live hours before the embargo ended	No, hours is not a week

The patch diffing point is worth understanding if you maintain anything open source. A fix is also a map. The moment your patch is public, the diff tells attackers exactly where to dig.

Researchers say turning these bugs into working weapons takes real effort. That difficulty is the main reason we have not seen mass exploitation yet. Hard is not the same as impossible, and by Friday it had been done.

Was AI used to find the PHP2Shell bugs?

Partly. Calif says AI helped with exploiting the bugs, but most of the work came from knowledge the researchers already had, including deep familiarity with PHP's codebase and its history of exploits. Their own summary was blunt: no model can find "all bugs" from simple prompts, at least for now.

Here is the exact line from Calif's write-up:

"No model is simply capable of unearthing 'all bugs' with simple prompts. At least for now."

I think both halves of that matter. The first half says expertise still did the heavy lifting. The second half, "at least for now", is the warning.

Some in the security community expect AI to rapidly surface vulnerabilities that have been sitting undiscovered in legacy software. If you are shipping AI-written code yourself, the other side of this problem is real too, which is why I wrote about how to review AI-generated code without missing critical bugs.

What did the PHP Foundation and the industry actually do?

They ran a coordinated disclosure. The PHP Foundation kept the bug details and fixes under a tightly guarded embargo, gave the largest companies and web hosts a head start, then released patches publicly on October 21. Thanks to weeks of quiet coordination, the internet broadly avoided mass exploitation, at least so far.

The process, step by step:

1. Report privately. Calif told the PHP Foundation instead of publishing.
2. Verify. Wiz confirmed the proof-of-concept exploits were real.
3. Fix under embargo. The foundation built patches and kept the details confidential until a set deadline.
4. Patch the biggest exposure first. Major internet companies and web hosts that depend on PHP got the fixes early.
5. Release publicly. Patches went out to everyone on Wednesday, October 21.
6. Take things offline where needed. Banks, retailers, gaming sites, hospitals and some agencies shut servers down rather than run exposed.

It mostly worked. It also showed the weak point. An embargo across an ecosystem this large depends on every party behaving, and the PHP Foundation says at least one company did not.

Is the internet safe from PHP2Shell now?

Not yet. There are no signs of mass exploitation, which is encouraging, but a large number of systems worldwide remain unpatched. Cloudflare reports an exponential rise in exploit attempts since disclosure, and real compromises were confirmed by October 23. The effects could last for years in systems that cannot be updated.

Three groups will lag behind:

• Small IT teams and solo developers, who patch slower than a big host with a security team.
• Companies that build PHP into their own products, which now have to ship their own updates to their own customers.
• Legacy devices, the routers, storage boxes and security appliances that may never get a fix.

The attack surface will shrink as updates land. It will not hit zero.

Will something like PHP2Shell happen again?

Almost certainly. TechCrunch's security editor puts PHP2Shell alongside the 2016 Dyn botnet attack, the 2017 ransomware attack on the U.K.'s health system using leaked U.S. government hacking tools, and the 2024 CrowdStrike update that crashed Windows computers worldwide. The difference is that this one may start a trend.

The reason is structural. PHP, like many technologies from decades ago, is described as "memory unsafe". That means an entire class of bugs can force it to leak sensitive data from memory.

According to the National Security Agency, around 75% of all actively exploited vulnerabilities abuse memory-related flaws. That is why there is a push towards memory-safe languages such as Python, Rust and Swift, which are broadly immune to that class.

New code can move. Old code mostly cannot. Media and video codecs, compression libraries and plenty of other decades-old software still sit under the modern web, and when one of them breaks, everyone above it feels it.

Pair that with AI tools that make finding flaws easier, and you get the forecast: more days like Wednesday.

What you can copy from PHP2Shell

I run Art of Code and I am not a security researcher. You do not need to be one to take the practical lessons here. These are the ones I would act on this week.

1. Patch first, investigate second. Cloudflare is seeing exploit attempts climb fast. An unpatched PHP server on the internet is a target right now.
2. Look back to October 17. Patching does not remove an intruder who is already in. Amazon's advice is to look for evidence of exploitation as early as that date.
3. Find the PHP you forgot about. Check web servers, but also developer tools, command-line packages, routers, storage and firewalls. Ask your vendors directly whether their products are affected.
4. Be willing to go offline. Banks and hospitals chose downtime over exposure. Decide in advance which of your services you would pull, and how.
5. Treat "not exploitable" as "not exploitable yet". If a known bug is sitting in your backlog because it seemed harmless, give it a date.
6. Know who maintains your dependencies. If a critical piece of your stack is kept alive by unpaid volunteers, that is a risk you are carrying. Contribute, fund, or at least know.
7. Pick memory-safe languages for new work where it fits. You do not need to rewrite the past, but you can stop adding to it.

FAQ

What are CVE-2026-109618 and CVE-2026-109619?

They are the official identifiers for the two PHP vulnerabilities known together as PHP2Shell. They allow unauthenticated remote code execution, meaning an attacker can take control of an unpatched PHP system over the internet without any password. The PHP Foundation released patches on October 21, 2026.

Is WordPress affected by PHP2Shell?

WordPress relies on PHP, as do Drupal, Joomla and MediaWiki, so sites built on them sit on top of the vulnerable software. The fix is to make sure the PHP running underneath is patched. If a host manages your server, confirm with them that the update has been applied.

Who found the PHP2Shell bugs?

Researchers at Calif found a way to exploit them during a security audit of PHP's code, as part of the Hack the Planet initiative from OpenAI and Wiz. Wiz verified Calif's proof-of-concept exploits. The bugs themselves had first been discovered in 2024 but were considered unexploitable then.

Was PHP2Shell exploited before the patches came out?

Yes. Amazon said it detected exploitation about a week before patches were available and told defenders to look for evidence as early as October 17. How the attacker learned about the bugs is still unclear. Confirmed compromises were reported by Palo Alto Networks and Trail of Bits by late Friday, October 23.

Check every PHP install you own today, then look back to October 17 for anything strange. When you are done, the free tools on Art of Code are there for the everyday work, and if you are deciding what to learn next, here is our take on the best programming languages to get hired in 2026.

Written by Adithya Guttha, Founder of Art of Code.