On Wednesday 21 October 2026, PHP released emergency fixes for two bugs that let an attacker take over a web server without logging in. PHP runs a large part of the web, including every WordPress, Drupal, Joomla, Magento and Laravel site, so the response was unusual. The NSA, CISA and CERT-EU told organisations that could not patch straight away to take their sites offline, and governments, banks, airlines and broadcasters did exactly that.

Flat illustration of the blue PHP elephant in front of three browser windows, two showing a pulled plug and the word OFFLINE and one a warning sign

The bugs became known as php2shell. Here is what they are, who was affected, and what to do if you run a PHP site or pay someone to host one.

What the two bugs are

The PHP Group published two CVE records on 21 October, CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state"). This is the second one:

The CVE record for CVE-2026-109619, published by the PHP Group on 21 October 2026, titled RCE via stale global state

PHP rates both 9.2 out of 10 (CVSS v4.0). In plain terms, according to Rapid7's analysis:

  • CVE-2026-109618: running out of memory mid-request. When PHP runs out of memory, it can stop processing a request halfway through and then tidy up data that was never fully set up. An attacker can trigger this with specially crafted form or file uploads, even ones that look within the size limits.
  • CVE-2026-109619: leftovers from the previous request. A PHP worker handles one request after another. Some internal state can survive after its memory has been freed, and the next request on the same worker can use it before it is reset. Rapid7 confirmed two ways in: the session upload progress feature (switched on by default) and, on PHP 8.5, the fatal error backtrace feature.

Either one can end in remote code execution: the attacker runs their own commands with the same permissions as the web server. Every common way of running PHP for the web is affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and almost every PHP version back to 5.4. Huntress reports that researchers at Wiz demonstrated unauthenticated takeovers of WordPress, Drupal and Joomla, and a memory leak path that could expose passwords, API keys and certificates.

Why the CVE page says so little

If you open either CVE record you get one paragraph and a list of weakness types, with no exploit and no fix instructions. That is by design. A CVE record is an identifier, a shared name so that PHP, hosting companies, governments and security tools all know they are talking about the same flaw. The details live in the vendor's advisory and in write-ups from security firms like the ones linked throughout this post.

How the week unfolded

The order of events, from the Huntress timeline and Help Net Security:

  • August 2026: Ryan Austin of the security firm Calif found one of the bugs with an AI model as part of OpenAI's "Patch the Planet" project. Researchers at Wiz found them independently (Wikipedia summary). OpenAI later called the flaw "one of the most impactful vulnerabilities in recent memory" (The National).
  • 17 October: Someone tried to exploit the bugs against one of Amazon's honeypots, four days before the fix was public. Amazon only connected the attempt to php2shell after the disclosure, which is why it now recommends checking server logs back to 17 October.
  • 20 October, morning: A post on Hacker News said two critical PHP bugs were about to be disclosed. It was taken down, but screenshots spread, and the security firm watchTowr confirmed the bugs were real. PHP brought its release forward by a day.
  • 21 October: PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and published the advisories. CISA issued an alert the same day.
  • 21 and 22 October: Organisations around the world took sites offline while they patched (the full list is below), and attack attempts climbed into the millions.

Why governments said "take it offline"

Telling people to switch off their own websites is rare. It happened here because the bugs can be reached before any login, affect almost every PHP version in use, and were public before most people could patch.

The NSA's first post put it bluntly:

The next day it followed up with detailed guidance:

CISA gave the same advice for anyone who could not update, or who runs PHP 8.1 or older. CERT-EU advised taking sites offline while patches were pending, and the UK's National Cyber Security Centre warned organisations to look for backdoors.

The most unusual warning came from Japan. Just before 10 pm Tokyo time on 21 October, Prime Minister Sanae Takaichi posted on X asking everyone to act that night: check whether their public websites use PHP, get the fix ready, and treat temporarily stopping a site as a valid way to reduce the risk. She took her own website offline too, as did Kobayashi, the policy chief of her Liberal Democratic Party (Jiji, Nikkei, both in Japanese).

English translation of the opening: "An urgent request that I would like everyone to act on tonight. PHP's security team has issued a warning about two serious vulnerabilities in PHP, which is used by many websites."

A day later she followed up for the businesses that still had their sites switched off:

English translation of the opening: "I imagine some businesses and others still have their websites temporarily suspended while they deal with this PHP vulnerability."

Who went offline

These are the organisations reported to have taken websites or services down as a precaution. Most come from a Reuters factbox; others are linked individually. None of them reported a breach. They switched off to patch safely.

  • Netherlands: the government portal Overheid.nl, the Port of Rotterdam, the national football association KNVB, the websites of the five largest political parties and many hospital websites, following the National Cyber Security Centre's lead.
  • Finland: Valtori, the state IT centre, shut down the government's public web services. It said it had seen no attempts to exploit the bugs.
  • France: the Interior Ministry disabled the websites of the prefectures (local government offices), and the telecoms company Orange suspended some websites, services and apps across several subsidiaries.
  • Germany: ITZBund, the federal IT provider, shut down several sites as a preventive step.
  • Belgium: the foreign ministry took its websites offline.
  • Czech Republic: the government took its website offline at 7 pm on 21 October on the advice of the national cyber watchdog.
  • Denmark: Aula, the platform Danish schools use to talk to parents, went offline on Wednesday afternoon and came back on Thursday morning (The Copenhagen Post).
  • United Kingdom: the BBC took some web portals down, as did several councils, including the City of Edinburgh.
  • Japan: the Ministry of Finance, the Meteorological Agency and the National Tax Agency suspended some online services, and so did Nomura, Mitsubishi UFJ Financial Group, the airline ANA and East Japan Railway.
  • The wider web: the Wikimedia Foundation took many of its supporting services offline, saying all its PHP systems were affected, and the Internet Archive went down for emergency maintenance and patching before coming back online.

Who this affects

People who run websites. If your site, or any tool it relies on, runs on PHP, it is exposed until PHP itself is updated. That includes WordPress and other content management systems, online shops, forums, booking systems and the admin panels that hosting companies use. A data company, Veridion, matched public version information to businesses and counted about 7 million companies running an affected version, most with fewer than 50 employees (Wikipedia summary). Small businesses are the ones least likely to have someone watching for this.

People who use websites. For everyone else, the main effect this week was services being unavailable: tax portals, train and airline bookings, banking and school platforms. The bigger worry is a site that stays unpatched. An attacker who takes over a server can read what it stores, including logins, personal details and payment data, and can use it to attack its visitors. There is nothing an ordinary user can patch here, but it is a good week to make sure your passwords are not reused across sites.

How fast attackers moved

Cloudflare sits in front of a large share of the web, so it sees attacks early. Its CEO, Matthew Prince, shared these numbers on 22 October:

These are attempts, not confirmed break-ins. On 21 October CISA said it had not yet seen successful exploitation, and Germany's BSI and the Dutch authorities reported the same (The Next Web). Amazon's security team, on the other hand, says the bugs are now being exploited broadly (Cybernews). Cloudflare added firewall rules for all its customers, including free accounts, but describes them as a stopgap: they only help traffic that passes through Cloudflare, and attackers have already been changing their payloads to get around them.

What to do

If your site is on shared or managed hosting, the PHP version is your host's responsibility. Updating WordPress, plugins or your own code does not fix this. Check your host's status page or ask them directly whether PHP has been updated to one of the versions below. Most large hosts have published notices, including Plesk, GoDaddy, DigitalOcean and Laravel Forge.

If you run your own server:

  1. Update PHP to a fixed version and restart every PHP worker. The old code keeps running in memory until you do.

    PHP branch Update to
    8.5 8.5.12
    8.4 8.4.27
    8.3 8.3.36
    8.2 8.2.35
    8.1, 8.0, 7.4 Source patches only

    PHP 8.1 and older are out of support, so there is no official release for them, only source patches. Use your Linux distribution's backported package or move to a supported version. Distributions also use their own version numbers, so check their security notices rather than comparing numbers directly. Debian 12, for example, ships the fix as 8.2.35-1~deb12u1.

  2. Check the version your web server actually uses. php -v shows the command-line version, which can differ from the one serving your site. Check the FPM service or Apache module, or use a phpinfo() page that you delete straight afterwards.

  3. If you cannot update today, these settings from Rapid7 reduce the risk but don't remove it. Set them at server level (php.ini, the FPM pool or Apache config), not with ini_set() or .user.ini, which apply too late, and then restart the workers:

    • session.upload_progress.enabled = 0 blocks the confirmed session path for CVE-2026-109619.
    • fatal_error_backtraces = 0 blocks the backtrace path on PHP 8.5.
    • Keep post_max_size small (8M if you don't need uploads) and block multipart uploads at your proxy if your site never accepts them.

    PHP's own advice is that updating is the only complete fix. If none of this is possible, do what CISA and the NSA said: take the site offline or put it behind a VPN until it is patched.

  4. Look for signs of compromise from 17 October onwards. Watch for PHP worker processes starting shells or downloading tools, new files in the web root, new cron jobs and new user accounts. If you find any, isolate the server and keep the logs before you clean up.

The rest of the week

PHP was not the only problem. This viral post summed up the mood of the week, half joking:

checked three of the other incidents in the post, and they are real:
  • GitLab fixed CVE-2026-110264, rated the maximum 10.0, which lets an attacker run code on self-managed GitLab servers without logging in by sending a specially crafted regular expression. It affects every version since GitLab 7.0 in 2014. The fix is in 19.5.1, 19.4.3 and 19.3.6, with backports to older branches (GitLab's release notes).
  • LiteLLM 1.107.0, a popular Python library for calling AI models, was published to PyPI and Docker with a credential stealer inside. It was live for about two hours on 21 October, and installing it was enough to run the malware. LiteLLM says 1.106.2 is safe and that any machine that installed 1.107.0 should be treated as compromised, with every secret on it rotated (LiteLLM incident report).
  • eMudhra, an Indian certificate authority, had eight intermediate certificates revoked after their private keys turned out to be tiny numbers. One was literally 4. Mozilla, Google, Apple and Microsoft have blocked them (BleepingComputer).

I haven't verified the rest of the list, so treat it as a snapshot of how the week felt rather than a checklist.

The following cards provide further definitions of concepts discussed above, and possible links to related posts.

CVE

Security

Common Vulnerabilities and Exposures: a public catalogue that gives each known security flaw a unique ID, so everyone refers to the same bug by the same name.

About CVE

Remote code execution (RCE)

Security

A flaw that lets an attacker run their own commands on someone else's server over the network. Unauthenticated RCE means they don't need an account or password first.

CVSS

Security

The Common Vulnerability Scoring System rates how severe a flaw is from 0 to 10. 9.0 and above is critical.

CVSS specification