HomeServicesOur WorkArticlesAbout UsLet’s Talk

The fix was out. The attackers were faster.

PHP2Shell explained: what a CVE is, why the NSA spoke up, and what “70% of the web” really means

dillnavaj · 23 October 2026 · 11 min read
Talk to usSee our work
A timeline card from the CVE leak on 20 October to the PHP fix on 21 October at 14:00 UTC, a server status card showing PHP 8.1.31 with security support ended, and labels reading last updated: 2014 and 69.3% of sites whose language is known

In the days around 21 October 2026, the Dutch government took DigiD, the login people use for government services, offline. Finland’s government IT centre began taking public web services down, France’s Interior Ministry took its prefecture websites offline, and Denmark shut Aula, the platform schools use to talk to parents. None of them had been hacked. They were waiting for a fix to the programming language behind their websites, and they did not want to find out what could happen in the meantime.

What happened

PHP is the programming language that runs on the server behind a large share of the web, including WordPress, Drupal and Joomla. When someone opens a page, PHP builds it. On 21 October at 14:00 UTC, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two flaws in PHP itself:

  • CVE-2026-109618: if PHP runs out of memory at the wrong moment, a request can be left half set up, and the clean-up code then treats the broken data as valid.
  • CVE-2026-109619: data belonging to one request can survive after its memory has been freed, and the next request handled by the same server process can use it.

In plain terms, an attacker can send a specially made request to a server without the fix and run their own code there, without logging in. PHP’s advisories say the code runs with the web server’s account, not as the system administrator (“root”). That is still serious: the web server’s account can usually read the website’s files and settings, which often include database passwords and API keys. One of the bugs can also leak memory, and Wiz, one of the teams that found the flaws, says that can expose passwords, tokens and keys belonging to other requests.

The flaws are in PHP, not in the website built on it. PHP lists every installation that serves web requests as at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest. Wiz showed the attack working against WordPress, Drupal and Joomla without a login, and says even a simple “Hello World” page on an affected version can be vulnerable. The researchers trace the affected code back to PHP 5.4, released in 2012. So a WordPress site with every update applied is still exposed until the PHP underneath it is updated.

Both flaws score 9.2 out of 10 for severity. A score of 10.0 circulated online before the release; the PHP Foundation says that was wrong.

What a CVE is, and what it is not

The two long numbers are CVE IDs. CVE stands for Common Vulnerabilities and Exposures: a public catalogue, running since 1999, that gives each known security flaw one ID, so software makers, hosting companies and security teams all know they are talking about the same problem. It is run by MITRE, a non-profit, and sponsored by CISA, the US government’s cybersecurity agency. Its funding nearly lapsed in April 2025 and was extended at the last minute; in March 2026, CISA said the programme was fully funded.

The score comes from a separate standard, CVSS (Common Vulnerability Scoring System), maintained by FIRST, a non-profit organisation of security teams. It rates a flaw from 0 to 10 by how it can be reached and how much damage it can do. PHP2Shell’s 9.2 means critical: reachable over the internet, with no login and nothing for a user to click, and a high impact on the affected system. It is not a 10 because the attack needs certain conditions to line up.

A CVE is a record that a flaw exists and, usually, that a fix is available. It is not a report that anyone has been hacked. Being vulnerable means a door can be opened; it does not mean someone has walked through it. Whether that happens depends, more than anything, on how long the door stays unlocked after the fix is out.

Why the NSA got involved

The NSA is best known for intelligence, but it also has a cybersecurity mission. When it set up its Cybersecurity Directorate in 2019, it said it would “prevent and eradicate threats to national security systems and critical infrastructure”, with an early focus on the defence industry. Government and defence systems run PHP like everyone else, and that side of the NSA speaks up when widely used software puts them at risk.

Its advisory on 21 October was blunt. “These vulnerabilities are flaws in PHP itself, not in the hosted application or its configuration,” it said, and “cyber actors are likely to weaponize PHP2Shell vulnerabilities.” It told organisations to list every system that relies on PHP, and: “If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated.”

Despite some headlines, the NSA did not discover the flaws; private researchers did (more on that below). It was one of several agencies that each issued its own warning that day:

  • CISA urged an immediate update, said it had “not observed exploitation” when it published, and told anyone who could not update, or was still on PHP 8.1 or older, to take those systems offline until patched.
  • The FBI’s Cyber Division repeated the advice to take systems offline if they cannot be updated, and asked organisations to report compromises.
  • Elsewhere, Turkey’s Cyber Security Presidency started nationwide scans and sent urgent notices to public bodies. In Kuwait, Al Rai reported that the Central Agency for Information Technology warned system administrators to apply PHP’s security updates.

Some governments went further and took sites offline while they patched:

  • Netherlands: MijnOverheid, DigiD and the House of Representatives website, according to NOS. The National Cyber Security Centre took its own website down too.
  • Finland: public web services were taken offline by Valtori, the government IT centre, according to Yle.
  • France: the Interior Ministry took prefecture websites offline “pending the release of a security patch”, Reuters reported.
  • Denmark: Aula, the schools platform, was shut down completely and reopened on 22 October.
  • Canada: some government websites were taken down as a precaution.

The Wikimedia Foundation, which runs Wikipedia, also took a number of its systems down as a precaution.

The race: how the head start disappeared

Every security fix starts a race. Once a patch is public, attackers can compare the old code with the new, work out what was broken, and build an attack against everyone who has not updated yet. Defenders rely on a quiet head start: whoever finds a flaw reports it privately, the maintainers write a fix, and Linux distributions and other vendors get it in advance under an agreed silence, called an embargo, so that the fix and the updates arrive together. PHP2Shell shows that head start being lost.

WhenWhat happened
After a 2024 auditA developer working on PHP finds the first signs of the out-of-memory problem while fixing an issue from a 2024 security audit. It is not fixed. The PHP Foundation later called the delay “a structural failure”.
11 August 2026Researchers at the security firm Calif, working in OpenAI’s “Patch the Planet” programme, report the first bug to PHP. They had found several ways to take over a server.
19 to 24 AugustWiz finds the flaws independently, using AI models from OpenAI and Google, and reports them.
17 OctoberAmazon’s decoy servers record an attempt to exploit PHP2Shell, four days before the flaws are disclosed.
20 October, about 15:00 UTCThe CVE IDs leak online, with a wrong release time and a wrong score of 10.0.
20 OctoberPHP announces an emergency release, brought forward from 22 to 21 October.
20 October, about 20:00 UTCCalif mistakenly publishes a video of its proof of concept. It is deleted, but copies spread.
21 October, about 02:00 UTCThe earliest proof-of-concept exploit appears, according to Amazon.
21 October, 07:41 UTCChainguard publishes container images that include the fix, more than six hours early. The PHP Foundation says this broke the embargo. Chainguard’s chief executive says he released early because exploits had already appeared in the wild.
21 October, 14:00 UTCPHP releases the fixed versions. More proof-of-concept exploits appear within hours.

Cloudflare’s chief executive, Matthew Prince, said attempts against its network rose from thousands in the 10 hours before the announcement to millions afterwards, as reported by SecurityWeek. Censys, which scans the internet, counted more than 3 million hosts running PHP on 22 October.

How many of those attempts worked is still unclear, so it is worth being precise. Amazon says it cannot tell whether the early attempts would have succeeded on real systems. The security firm watchTowr told SecurityWeek that the exploits circulating publicly either did not work, only probed for the flaw, or crashed the target. As of 22 October, CISA had not added either CVE to its catalogue of vulnerabilities known to be exploited, while the Dutch National Cyber Security Centre said it was seeing signs of misuse.

Two things made the window this short:

  • Leaks. The IDs, a video and early builds were all public before the official fix, and each one told attackers where to look.
  • AI. Both teams that found PHP2Shell used AI models, and Wiz wrote that frontier models “were critical to making this process practical”. The same kind of tool can read a newly published fix and help write an attack for it, which shrinks the time between a patch and the first exploit.

Defenders used to be able to count on some time between a fix and working attacks, and most well-run systems were updated within it. With PHP2Shell, the first attempts came before the fix.

“70% of the web”: what the number means

Many headlines said PHP2Shell put 70% of the web at risk. Wiz titled its research “AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”, CNN wrote of a flaw “affecting 70% of the internet”, and TidBITS and ABC News used similar wording.

The figure comes from W3Techs, which surveys websites. Its exact wording on 23 October 2026: “PHP is used by 69.3% of all the websites whose server-side programming language we know.” A year earlier, it was 73.4%.

That is a real number, but the headline version leaves out three things:

  • It counts websites, not visitors. A blog nobody has opened in years counts the same as a national news site.
  • It only counts sites whose language can be detected. Many sites do not reveal what they run on.
  • Using PHP is not the same as being exposed. Many sites are on hosting where the provider updates PHP for every customer at once. Hostinger, for example, told customers its platform was not vulnerable, added an extra layer of protection, rolled out patched versions and said no action was needed from them.

It would be just as wrong to say that big websites do not use PHP. W3Techs finds PHP on 58.9% of the top 1,000 websites and 64.4% of the top million. The difference is who looks after them: large platforms tend to have security teams watching for exactly this kind of notice. The real exposure is elsewhere.

The real risk: websites nobody maintains

WordPress, which runs on PHP, is used by 39.6% of all websites, according to W3Techs. Hacked WordPress sites are common, and the cause is rarely WordPress itself. It is the site that was built once, launched and then left: no updates to PHP, WordPress, the plugins or the theme, and often nobody left at the company who knows where it is hosted.

The version numbers show how common that is. Of websites using PHP, 26.9% still run PHP 7 and 7.7% run PHP 5 (W3Techs), and the PHP project no longer supports either. PHP 8.1 lost security support on 31 December 2025, and 8.0 is unsupported too. Only 8.2 and newer got official fixed releases, which by W3Techs’ figures is roughly half of all PHP sites. Some Linux distributions and paid support vendors offer patched builds of older versions, but for most of the other half there is no simple update to install: the fix means moving to a newer PHP version, and possibly changing the site so it works there.

This pattern is behind most attacks, not just this one. A joint advisory from CISA, the NSA and the FBI on the most exploited flaws of 2022 found that attackers “exploited older software vulnerabilities more frequently than recently disclosed vulnerabilities and targeted unpatched, internet-facing systems.” The vulnerability gets the headline; the system nobody updated is where the damage happens.

What to check this week

  1. Find out which PHP version your site runs. Your hosting control panel usually shows it; otherwise ask your developer or host. You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer.
  2. Ask your host whether it has patched. On managed hosting, the host updates PHP. On your own server or a cloud machine, you or your developer do. Linux distributions received the fix in advance, so check for updated packages from your vendor.
  3. On PHP 8.1 or older, plan the upgrade now. These versions get no official fix, and CISA’s advice is to keep such systems offline until they are patched.
  4. If you cannot patch today, take the site offline. That is the official advice, and it is better than running a server that attackers are scanning for.
  5. Update everything else too. WordPress, plugins and themes. PHP2Shell is in PHP, but most break-ins use older flaws in the software on top.
  6. If in doubt, change your secrets. If a site without the fix was online after 21 October, change its database password and any API keys it stores, and check it for files you do not recognise.
  7. Keep watching for updates. On 23 October, PHP published a further notice suggesting sites turn off a setting called session.upload_progress.enabled until the next regular release. Check php.net for the latest.
  8. Agree who maintains your website after launch. It matters most and is easiest to forget when a project ends: who updates it, how quickly, and who gets the call when the next notice comes out.

We build software and websites for businesses in Kuwait and the Gulf. If you are not sure what your website runs on or who looks after it, get in touch and we will help you find out.

Sources

Let’s build something that thinks

Tell us what you’re working on. We’ll turn it into a clear technical plan and a practical next step.

Get in Touch