PHP2Shell: Why Governments Took Websites Offline on 21 October

On 21 October 2026, public bodies in the Netherlands, Finland, Denmark, France and elsewhere took PHP websites offline over PHP2Shell (CVE-2026-109618 and CVE-2026-109619). CERT-EU and the UK NCSC advised isolating systems that could not be patched; national bodies chose to go dark. If you run PHP, patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every worker.

To be precise: the EU did not shut down websites. CERT-EU, the EU institutions' cybersecurity service, published advice. National agencies, state IT providers, ministries, ports and hospitals each decided to pull services. Their choice is yours too: patch now, mitigate for a few hours, or go offline until you can do one of those.

For the vulnerability itself, read our companion explainer on PHP2Shell, CVE-2026-109618 and CVE-2026-109619. This post is about the shutdown decision.

What happened

PHP's security team gave advance notice on 20 October that it would ship fixes for two critical flaws at 14:00 UTC the next day, and said it might release earlier if details became public. Details did leak ahead of the coordinated release, according to SecurityWeek. That leak turned a routine patch day into a race.

Two timing details are disputed. Reuters, via RTE, describes the CERT-EU advisory as issued the day before 21 October, while the advisory on cert.europa.eu carries a release date of 21 October at 15:20. Earlier CERT-EU guidance may have circulated before the published page; we could not confirm which. The release time also differs by a few minutes between CERT-EU and Reuters.

What the agencies actually advised

The advice was conditional in every case. Nobody told organisations to go offline instead of patching.

CERT-EU (Security Advisory 2026-018) says to patch immediately. If that is not feasible, it recommends considering isolating internet-facing resources from public networks until the fix is applied and verified. Reuters paraphrased this as taking affected sites offline. CERT-EU also warned that products embedding PHP may be affected even when they do not expose PHP directly.

The UK NCSC gives an ordered list: find every PHP installation, update, apply PHP's hardening and temporary mitigations, and only if those cannot be applied in time, "consider taking the system offline until it can be fully mitigated." It also asks teams that cannot update or disable a system to check it for compromise.

Others. Reuters reported that agencies in Australia, Japan and Britain urged updates. A Reuters factbox said the US NSA advised taking systems offline if they could not be updated. NBC News reported that CISA recommended patching but did not advise going offline. The Australian Cyber Security Centre said it was not aware of active exploitation at the time, per Reuters via RTE.

PHP itself was blunt: "There are no complete mitigations, updating is the only safe choice." Its workarounds reduce exposure to specific attack paths but do not make an installation safe.

Who went offline, country by country

All entries below come from news reporting, mostly Reuters. We could not find primary statements from each organisation, so treat the list as reported, not exhaustive. None of the reports we read describes a confirmed breach at any of these organisations; several explicitly called the move precautionary.

Outside government, the Reuters factbox reported that the Wikimedia Foundation took a number of PHP systems down as a precaution, and NBC News reported voluntary shutdowns of some Japanese sites, citing ITmedia. We found no report of when each organisation came back online, so this post does not claim any restoration times.

Why "patch or go dark" became the choice

Three facts pushed teams toward the offline option on the same morning.

First, the reach. NCSC-NL, as quoted by DutchBrief, warned that almost any public PHP system was probably vulnerable. PHP's advisory lists every web-serving setup: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for mod_php, where PHP says a demonstrated exploit runs from one unauthenticated request before any application code. There was no "we do not use the vulnerable feature" escape.

Second, the clock. The details leaked before the fix existed. For several hours, defenders knew a critical flaw was public and had nothing to install. A website that cannot be patched for six hours is a website that is exposed for six hours.

Third, uncertainty about exploitation. Sources disagreed and still do:

• Cloudflare's CTO said it was seeing early attacks and called its WAF rules a stopgap, according to Reuters.
• NBC News reported Patchstack citing reports of active exploitation.
• Huntress and watchTowr said they had not seen exploitation in the wild at the time they wrote, per Huntress and SecurityWeek.
• NCSC-NL reported no confirmed active exploitation, according to Techzine and DutchBrief.
• NBC News reported CISA had not observed exploitation at publication.

With experts split and remote code execution on the table, a precautionary shutdown is reasonable for a service that can tolerate a few hours offline. It is a poor call for a service people need for urgent help, unless another channel exists.

How to make the call: a decision checklist

Use this for public sector and regulated teams. Write the answers down; you will want them in the after-action review and possibly for a regulator.

1. Is the system reachable from the internet? Internal-only PHP behind a VPN can usually wait for the normal patch window. Public systems cannot.
2. Which PHP version and SAPI is it running? mod_php carries the highest risk per PHP. A branch at 8.1 or older gets no project fix; you need a vendor backport, PHP's minimal source backport or an upgrade.
3. Is a fixed package available from your actual supplier? Distros and LTS vendors received patches in advance, according to PHP. Help Net Security and CERT-EU noted that the volunteer Remi repository had no release-day update.
4. Can the temporary mitigations be applied correctly? PHP's mitigations must be set in php.ini, the FPM pool or server config, not through ini_set() or .user.ini, and every worker must restart. If you cannot verify that, treat the mitigation as absent.
5. Is there an edge filter in front? A WAF rule buys time. Cloudflare's own CTO called it a stopgap. Count it as a reason to wait hours, not days.
6. What can this server reach? A brochure site on an isolated host is a different risk from a portal with database credentials, a citizen login or a route into the internal network.
7. What is the service obligation? For statutory services, check whether a phone line, counter or static page can carry the load while the site is down, and who must approve the outage.
8. Who decides, and how fast? Name one accountable owner per service with authority to pull it without a committee.
9. How will you go offline? Prefer blocking at the load balancer, firewall or CDN and serving a static maintenance page from something that is not PHP. Keep the host running so logs survive for later checks.
10. What will you tell people? A short, honest notice ("taken offline as a precaution while we apply a security update") is what Valtori, the French Interior Ministry and others effectively said.

If the answers to 1, 2 and 4 are "public, unpatched, mitigations unverified", going offline is defensible. If you can patch within the hour, patching beats going dark.

What to do now

The fixes are out. The work now is finding every runtime and proving it is patched.

1. Check the CLI and the web runtime separately. They can differ.

php -v
php-fpm -v            # or php-fpm8.3 -v on Debian and Ubuntu
apachectl -M 2>/dev/null | grep -i php   # is mod_php loaded?

2. List installed packages on each host.

dpkg -l | grep -i php       # Debian and Ubuntu
rpm -qa | grep -i php       # RHEL, Alma, Rocky, SUSE

3. Check containers, which carry their own PHP regardless of the host.

docker ps --format '{{.Image}}' | sort -u
docker run --rm --entrypoint php <image> -v

4. Find bundled copies on appliances and Windows servers. Huntress points to php.exe and php-cgi.exe inside vendor software, and to control panels such as cPanel and Plesk. NCSC-NL's php2shell repository lists products with a PHP dependency.

5. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's backport, then restart every PHP worker. Running processes keep the old code until restart, as Techzine reported from NCSC-NL.

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # or httpd

6. Rebuild and redeploy images from patched base images. Pulling a new tag does nothing until the container is replaced.

Our step-by-step guide, find and patch every PHP runtime after PHP2Shell, goes deeper on each environment.

Bringing sites back safely

Coming back needs its own short checklist.

• Confirm the running version, not the installed one. Check from the serving process or a restricted status endpoint after restart. The CLI can report a patched version while FPM workers still run the old binary.
• Check for compromise before restoring. The NCSC asks teams that could not update in time to look for backdoors. Huntress suggests looking for webshells, new files in the web root, new cron jobs or scheduled tasks, and new accounts. If you find anything, keep the server isolated and preserve web server and PHP logs.
• Restore in stages. Bring back the lowest-risk static or read-only pages first, watch logs, then reopen forms, uploads and logins.
• Keep the edge rule in place. Leave the WAF rule active for a while after patching as an extra layer, not a replacement.
• Watch the workers. Huntress recommends alerting when php-fpm, php-cgi, httpd or apache2 spawns a shell, interpreter or download tool.
• Record the decision. Note who decided, when the site went down, when it returned and what was verified. Regulated teams will be asked.

What would have helped

Going offline is a blunt tool. Teams that can answer "which of our sites run which PHP version" in minutes can patch or isolate precisely instead of pulling everything.

Practices any team can use

• A runtime inventory, not just an application inventory. Know which hosts, containers and appliances run PHP, which version and which SAPI. A list of "WordPress sites" does not tell you this.
• Bundled runtime tracking. Appliances and vendor products embed PHP. Ask suppliers which version they ship and how fast they patch, and keep the answer.
• Owner per service. Every public site needs a named owner who can approve an emergency outage and a named team who patches the server. Wordfence warned, per Reuters, that WordPress auto-updates would not apply this fix; whoever runs the server must.
• A pre-approved maintenance mode. A static page served from outside PHP, ready to switch on at the CDN or load balancer, turns a hard shutdown into a controlled one.
• A tested rebuild pipeline. For containers, a base image bump should flow through build, test and redeploy in hours. Our post on container image supply chain incidents in 2026 covers this pattern.
• Restart as part of patching. Treat "package updated" and "workers restarted" as two separate checks.
• Leave end-of-life branches early. PHP 8.1 and older got no project fix. PHP says 8.2 reaches end of life on 31 December 2026.

For the inventory approach in general, see using SBOMs to find affected products fast.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell, and it would not have made the shutdown decision for anyone. What it can do is shorten the "where is PHP and which version" step for code and images you build.

• Scan what you build. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image, and safeguard scan --sbom <file> analyses an existing SBOM. Results land as JSON under ./output. Image scans list the packages inside the image, which includes PHP when it is installed as a distro package. If an image compiles PHP from source, confirm the version with php -v inside the container.
• Find every project with a given component. The platform shows which projects contain a given component and version, so "which of our images carry PHP 8.3 below 8.3.36" becomes a query, not a spreadsheet hunt.
• Match and prioritise. Findings are matched against vulnerability databases, and reachability analysis helps rank application dependency findings.
• Gate deployments. Policies and gates evaluated in the platform can block an image with a vulnerable component from moving forward.
• Make the change with approval. The Safeguard CLI's assistant can edit code, such as bumping a Dockerfile base image tag, and run build and test commands, asking first according to your /permissions mode (Ask, Accept edits, Plan, Auto, which is the default, or Strict). safeguard exec runs it in CI. Autonomous remediation can open fix PRs for dependency findings; it ships off by default.

Where Safeguard does not help: PHP installed directly on servers or VMs you do not build as images or scan as SBOMs, shared hosting, vendor appliances with sealed firmware, the WAF at your edge, the forensic check for webshells, and the judgement call about whether a statutory service can go dark. Those stay with your operations and incident teams.

If you want to try it on your own images, download the app at https://safeguard.sh/download and see the CLI docs at https://docs.safeguard.sh/docs/cli .

Common mistakes

• Trusting php -v alone. The CLI and FPM can be different builds. Check the serving runtime.
• Patching without restarting. Old workers keep running vulnerable code.
• Setting mitigations with ini_set() or .user.ini. PHP and CERT-EU say these do not count.
• Treating the WAF rule as the fix. Cloudflare called its own rules a stopgap.
• Coming back online without checking for compromise. If a site was exposed before it went offline, check it before restoring.

FAQ

Did the EU order websites offline?

No. CERT-EU advised organisations that could not patch to consider isolating internet-facing systems. National agencies, state IT providers and individual organisations decided for themselves to take sites offline.

Which countries took government sites offline?

Reuters reported precautionary shutdowns in the Netherlands, Finland, Denmark and France, and a Reuters factbox added Germany and Belgium. The table above lists the organisations named in that reporting.

Was PHP2Shell being exploited when sites went offline?

Sources disagree. Cloudflare reported early attacks and Patchstack cited reports of exploitation. Huntress, watchTowr, NCSC-NL, CISA and the Australian Cyber Security Centre had not confirmed exploitation when they published.

Is going offline better than applying the workarounds?

Only if you cannot apply the workarounds correctly and cannot patch soon. PHP says the workarounds reduce exposure but do not make an installation safe. Patching is the fix.

How do I know a site is safe to bring back?

Confirm the serving runtime is a fixed version after a full worker restart, check for signs of compromise, then restore in stages while watching logs.

Do WordPress automatic updates fix this?

No. Wordfence warned, per Reuters, that WordPress automatic updates will not apply this fix. PHP is updated by whoever runs the server.

Try it yourself

Watch a real CLI session where the assistant reads a finding, asks before each command, edits a dependency, and runs the install and tests with approval.

Click through it at your own pace, or open it full screen.

Set up the runner on your own machine, approve it with its device code, then scan from the terminal.

Click through it at your own pace, or open it full screen.

Quick check

For more on this week's incidents, see the October 2026 roundup, how AI found PHP2Shell and PwnEscape and our background on PHP security.

Sources

• PHP: news and security advisory for 8.5.12, 8.4.27, 8.3.36 and 8.2.35
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• CERT-EU security advisories list
• UK NCSC: Critical security issue affecting PHP
• NCSC-NL php2shell repository
• Reuters via KSL: Cyber agency warns websites may go dark as PHP prepares critical fix
• Reuters via GV Wire: Government websites go dark as software flaw sparks security scramble
• Reuters factbox via Euronext: Websites taken offline over PHP risks
• Reuters via RTE: EU cybersecurity agency advice on PHP
• NBC News: Critical vulnerabilities in PHP
• Help Net Security: PHP2Shell vulnerabilities patched
• SecurityWeek: PHP2Shell mass exploitation looms for leaked critical PHP flaws
• Huntress: PHP2Shell leaked critical PHP vulnerabilities
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
• Techzine: Why PHP2Shell affects every company
• DutchBrief: DigiD, MijnOverheid and many other Dutch sites pulled offline

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.