PHP2Shell, explained in plain English

If you run a website, an online store or a web application, chances are you noticed nothing unusual during the week of 20–23 October 2026. For the people who manage servers, however, it was one of the most stressful weeks in years. Some shut down entire servers for hours. European governments temporarily took their websites offline.

It all started with two critical vulnerabilities discovered in PHP, which the community nicknamed PHP2Shell. Below we explain, without jargon, what happened, where it started, why it matters and what you should do.

What PHP is, and why it concerns you even if you've never heard of it

PHP is a programming language that runs on a website's server. When you open a page, PHP is what "cooks" it behind the scenes: it pulls products from the database, checks whether you're logged in, calculates your shopping cart and sends the result to your browser.

You never see it, but it's everywhere. According to W3Techs, PHP is used by roughly 70% of websites whose server-side technology can be identified. WordPress, WooCommerce, Magento, Drupal, Joomla, PrestaShop, Laravel and a large share of public-sector, banking and e-commerce sites all run on PHP.

In other words: if PHP has a serious problem, a large part of the internet has a serious problem.

What happened, in short

On 21 October 2026, the PHP team released emergency updates for two vulnerabilities (officially CVE-2026-109618 and CVE-2026-109619). Each received a severity score of 9.2 out of 10.

What that means in practice: under certain conditions, an attacker could send a specially crafted request to a website and end up running their own code on the server, without an account, a password or any other access. Specialists call this "unauthenticated remote code execution" – the most serious kind of problem a web server can have.

And because the flaw is in PHP itself, not in a particular website or plugin, researchers demonstrated the attack against the latest versions of WordPress, Drupal and Joomla. In theory, even a simple "Hello World" page could be vulnerable.

How the problem worked, explained with an analogy

Imagine a very busy restaurant. The waiters (in our case, PHP "processes") serve hundreds of customers one after another. After each customer, the table must be fully cleared before the next one sits down.

The two problems looked roughly like this:

• The first (CVE-2026-109618): if a customer ordered something so large that the kitchen ran out of room (technically, the server hit its memory limit), the order was cut off abruptly, halfway through. The table was left half-set, and when clearing it the waiter treated those unfinished items as if they were fine.
• The second (CVE-2026-109619): sometimes, after a customer left, things stayed on the table that shouldn't have been there. The next customer, served by the same waiter, could use them.

A highly skilled attacker could deliberately "arrange" the table so that the next step ended up executing their instructions. That, very simply put, is PHP2Shell.

Where it started: a problem more than 10 years old

The most surprising part is the age of the problem. According to the researchers, the affected code has existed since PHP 5.4, released in 2012. Practically every PHP version from the last decade is affected by at least one of the two issues.

And it wasn't entirely unknown:

• As early as 2004, and again in 2020, there were reports of problems in the way PHP handles running out of memory.
• In 2024, a PHP core developer spotted the memory issue while fixing something else that came out of the language's first external security audit. Someone theorised at the time that it might be exploitable, but nobody found a concrete way in.
• The team had several possible fixes, but each came at a cost: one broke compatibility with existing applications, another created a risk of servers being knocked offline, another forced thousands of extensions to change. Work stalled and restarted for months.

After the incident, the PHP Foundation openly admitted: "We won't pretend otherwise: the delay was a structural failure."

For a long time, exploiting the flaw was considered so complicated that the complexity itself acted as a form of protection. A real attack required understanding exactly how PHP allocates and reuses memory, and every version, configuration and application changed the rules of the game.

The genuinely new part: artificial intelligence

This is where the story starts to matter for everyone, not just programmers.

In the summer of 2026, several teams used artificial intelligence models to analyse PHP's code, independently of one another:

• 30 July: security firm Calif begins an audit of PHP as part of OpenAI's "Patch the Planet" programme, using the GPT-5.6 Sol model.
• 11 August: Calif reports a critical vulnerability. The same day, OpenAI independently reports the same root cause.
• 19 August: Wiz Research finds the first vulnerability using its own AI system and models from Google and OpenAI.
• 20–21 August: Wiz confirms it can take over a Drupal site, then a WordPress site, without logging in.
• 24 August: Wiz reports both issues to the PHP team.

What did AI change? It didn't "guess" a new problem. It made feasible something that had been almost impossible to see through: it helped researchers adapt the attack to different versions, configurations and applications, analyse failures and try again, in hours rather than weeks. Wiz says a single researcher finished in a week what would have taken a team of top specialists months.

This time, AI was in the hands of the people who found the problem, reported it and helped fix it. OpenAI calls this period the "Defender's Window": the moment when the good guys find a problem before attackers do and have time to prepare a fix.

The uncomfortable question is a different one: the same tools are increasingly available to people with bad intentions too. Next time we may not be so lucky.

Timeline of the critical week

• 17 October: Amazon observes the first exploitation attempt in its network of attacker "traps" – four days before the public announcement.
• 20 October: the vulnerability identifiers appear on forums and social media ahead of schedule, with an incorrect score of 10/10. That evening, a video of the attack working is published by mistake, then deleted, but copies are already circulating.
• 21 October: the release, originally planned for 22 October, is brought forward by a day. The fixed versions go out. Cloudflare reports the first attacks. Finland, the Netherlands and France temporarily take some government websites offline as a precaution.
• 21–22 October: server administrators around the world rush to update. Many shut their servers down completely until they finish.
• 23 October: PHP announces a third vulnerability (CVE-2026-115560), which only affects unusual configurations and has a temporary mitigation until the next update.

Why some chose to shut their servers down completely

You may have seen posts from administrators who took all their sites, their own and their clients', offline for a few hours. It may sound excessive. It isn't.

The PHP team stated clearly that there is no complete workaround: the only real protection is updating. US security agencies recommended that servers which cannot be updated immediately be taken off the internet. CERT-EU, the cybersecurity team of the EU institutions, recommended isolating exposed applications until they were updated and verified.

Weigh it up: a few hours of a website not responding, versus the risk of someone taking over the server, stealing customer data or installing malware. Better for a few people to complain for a few hours that their site is down than for all of us to regret it afterwards.

Who is most at risk

• Websites that haven't been updated. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Any older version in these series is vulnerable.
• Websites on old PHP versions (8.1 or earlier). For 7.4–8.1 there are only patches for people who compile PHP themselves. For versions 5.4–7.3 there is no official fix at all. Security analyses estimate hundreds of thousands of internet-facing servers running such versions.
• Servers running PHP as an Apache module (mod_php), the setup the PHP team itself considered the riskiest.
• "Forgotten" websites: a 2019 campaign page, an old online store, a test subdomain. What isn't maintained doesn't get updated either.

What you should do, even if you're not technical

You don't need to know what PHP is to protect your business. You just need to ask the right questions of whoever manages your website (agency, freelancer, hosting company):

1. "Does my website run on PHP? If so, which version?"
2. "Have you updated to a fixed version (8.2.35, 8.3.36, 8.4.27 or 8.5.12, or newer)? When?"
3. "Do I have other websites, subdomains or old applications running PHP?" Make a list of everything you have online.
4. "Have you checked for attack attempts since 17 October?" Specialists recommend reviewing logs from that date onwards.
5. "If a site runs on an unsupported version, what's the migration plan?"

If the answers are vague, or you get no answer at all, that in itself is a warning sign.

The bigger lesson: digitalisation without security

PHP2Shell isn't just a story about a programming error. It's a story about how the internet's infrastructure actually works.

A technology used by roughly 70% of the web, including public services, banks and stores, is maintained by a small group of developers funded by the PHP Foundation and a handful of volunteers. The Foundation itself has publicly asked the companies, hosting providers and governments that depend on PHP to help fund its security work.

At the same time, we keep putting more data, public services and critical infrastructure into internet-connected systems, often at the pace of "fast-forward digitalisation", without investing at the same speed in the people and the security needed to protect them. And AI has just dramatically shortened the time it takes to turn an old, "too hard to exploit" problem into a practical attack.

The takeaway isn't to be afraid of technology. The takeaway is that maintenance, updates and the people who handle them are not an optional cost. They are the reason most of us noticed absolutely nothing this week.

Sources

• Wiz Research – PHP2Shell: AI uncovers critical RCE vulnerabilities
• CERT-EU – Critical Vulnerabilities in PHP (Advisory 2026-018)
• Tenable – PHP2Shell FAQ
• The Next Web – PHP knew about one of the flaws in 2024
• BleepingComputer – PHP ships emergency patches for critical PHP2Shell flaws
• Rapid7 – CVE-2026-109618 and CVE-2026-109619
• Decrypt – Who found the PHP bug