---
title: "Emergency PHP Fix: Critical Flaws Let Attackers Run Code on Websites, Including WordPress"
description: "PHP's emergency update fixes two critical flaws that let attackers run code on a server without logging in. Updating WordPress does not apply it."
tldr: "PHP, the server language WordPress runs on, released an emergency update on 21 October 2026 for two critical flaws, both scored 9.2 out of 10, that let attackers run their own code on a web server without logging in. Updating WordPress or its plugins does not apply the fix: the host has to update PHP, and versions 8.1 and older get no official fix. PHP says no workaround fully protects a site. For sites taken offline to patch, Google advises a 503 status code, which marks the outage as temporary, served from outside PHP and for one to two days at most. Patching does not remove a compromise that happened before it."
publishDate: 2026-10-21
updatedDate: 2026-10-23
author: "Liam Hayward"
---
PHP, the server language WordPress runs on, released an emergency update on 21 October 2026 that fixes two critical flaws letting an attacker run their own code on a web server without logging in. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, the public IDs security advisories use, and PHP scores both 9.2 out of 10 on CVSS, the standard severity scale, which puts them in its critical band of 9.0 and above. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The PHP security team says every installation serving web requests is at risk, and the risk is highest where PHP runs inside the Apache web server itself, a setup called mod_php. It lists temporary workarounds that reduce exposure, but says none fully protects a site: "there are no complete mitigations, updating is the only safe choice". CERT-EU, the cyber security service for EU institutions, reports that working demonstrations of the attack are already circulating, which makes exploitation more likely.

On 23 October PHP published an informational advisory for a separate flaw, CVE-2026-115560, which can also let an attacker run code, but only where an application changes `session.serialize_handler` to `php` with `ini_set()` before calling `session_start()` while session upload progress is switched on. PHP calls this setup "unlikely in practice" and will fix it in its next regular release rather than an emergency one. Until then it recommends setting `session.upload_progress.enabled=0`, a workaround it already listed for CVE-2026-109619 on 21 October, so a server where that setting is still in place needs nothing more.

## Does updating WordPress fix the PHP flaws?

No. Updating WordPress or its plugins does not update PHP, and WordPress.org says "no WordPress update is required or planned for these issues". PHP is updated by whoever runs the server, usually the host, and WordPress shows the version a site is running under Tools > Site Health > Info > Server. PHP 8.1 and older get no official fix, so sites on those versions need an upgrade, or a fix from their host or Linux distribution in the meantime.

## Should you take a site offline until PHP is patched?

The UK's National Cyber Security Centre (NCSC) advises it where neither the update nor PHP's temporary workarounds can be applied quickly:

> If you are unable to apply the temporary mitigations, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated.

## How do you take a site offline without dropping out of Google?

Google Search Central posted on LinkedIn that "serving a 503 (Service Unavailable) HTTP status code ensures already indexed URLs are preserved in Search while you work", and warned against generic 404s or 200 error pages. A 503 tells browsers and crawlers that a site is temporarily unavailable rather than gone. John Mueller, a Search Advocate at Google, said on Bluesky that the 503 can be served "outside of PHP / point DNS elsewhere / CDN": from a content delivery network such as Cloudflare that sits in front of the server, or by pointing the domain at a different server. The 2011 Google post he linked shows how to send a 503 with PHP code, which does not run while PHP itself is down.

The LinkedIn post gives no time limit, but Google's documentation does. Its crawl rate page recommends against serving a 503 for "longer than 1-2 days", because a URL that returns one for multiple days "may be dropped from Google's index", and adds that Google Ads campaigns may be paused. Its guide to pausing a site says not to return a 503 for robots.txt, "because this blocks all crawling", and that Google cannot refresh titles, descriptions or structured data on a page returning one.

So a site taken down to patch should serve its 503 from a CDN rule, the web server or a temporary server, with robots.txt still loading normally and, if the return time is known, a `Retry-After` header, which tells crawlers when to come back. For a closure longer than a day or two, Google's pause guide recommends a normal, indexable home page as a placeholder instead.

## Are attackers exploiting the PHP flaws?

Attackers are trying at large scale, but no successful break-in had been confirmed by 23 October. Amazon says its honeypots, decoy servers set up to attract attacks, logged an attempt on 17 October, four days before PHP disclosed the flaws, and that the pair, which researchers have named PHP2Shell, is now seeing "broad exploitation attempts in the wild". It adds that "it's unclear if any of these attempts would have succeeded in real-world systems". Matthew Prince, Cloudflare's chief executive, posted on X that attempts across Cloudflare's network went from thousands in the 10 hours before the announcement to "tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now".

The security company Sophos reported one successful attack in a customer environment on 22 October, then withdrew it the same evening: its telemetry "shows scanning and a small number of failed exploitation attempts", and the payload it blocked, likely a variant of the Mirai botnet malware, "was not delivered". Attempts started before the fix existed, so a server patched on 21 October may already have been probed, which is why the check below still applies.

## What should you check after patching PHP?

Updating PHP closes the flaws but does not undo anything an attacker did before the update. The NCSC advises any organisation that could not update or go offline straight away to look for "evidence of compromise" and for "backdoors installed by an attacker". On a WordPress site, that means checking for web shells (malicious scripts that give an attacker ongoing access), administrator accounts nobody recognises, and PHP files that changed when nobody updated anything.

Once PHP is updated, asking the host to set `expose_php = Off` stops the server announcing its PHP version in an `X-Powered-By` header, which OWASP, the open web security project, advises removing because it helps attackers find vulnerable servers; it does not protect a server that has not been updated, since attacks like these try every server regardless.

## Sources

- [PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 security advisory, PHP](https://www.php.net/archive/2026.php#2026-10-21-5)
- [Informational advisory: Session upload progress, PHP](https://www.php.net/archive/2026.php#2026-10-23-1)
- [Critical security issue affecting PHP, National Cyber Security Centre](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)
- [Critical Vulnerabilities in PHP, CERT-EU Security Advisory 2026-018](https://cert.europa.eu/publications/security-advisories/2026-018)
- [Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)
- [Matthew Prince on PHP2Shell exploit attempts, X](https://x.com/eastdakota/status/2113079352682570051)
- [Proof-of-concept exploit released for PHP vulnerabilities, Sophos](https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619)
- [HTTP Headers Cheat Sheet, OWASP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
- [Don't forget the 503, Google Search Central on LinkedIn](https://www.linkedin.com/posts/how-http-status-codes-affect-googles-crawlers-share-7518727870165385216-gmHF)
- [John Mueller on taking PHP sites down, Bluesky](https://bsky.app/profile/johnmu.com/post/3myfhjovzvk27)
- [Reduce Google crawl rate, Google Crawling Infrastructure](https://developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate)
- [Temporarily pause or disable a website, Google Search Central](https://developers.google.com/search/docs/crawling-indexing/pause-online-business)
- [How to deal with planned site downtime, Google Search Central Blog (2011)](https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime)
- [Critical PHP security release, WordPress.org News](https://wordpress.org/news/2026/10/critical-php-security-release/)
- [Update your PHP today, WordPress.org](https://wordpress.org/support/update-php/)
- [Critical PHP Core Security Flaws Affect Websites, Including WordPress, Search Engine Journal](https://www.searchenginejournal.com/critical-php-core-security-flaws-affect-websites-including-wordpress/593812/)
- [Google Reminds Sites To Serve A 503 During PHP Patch Downtime, Search Engine Journal](https://www.searchenginejournal.com/google-reminds-sites-to-serve-503s-during-server-downtime/593873/)
- [Google On Taking Sites Down When Fixing The Emergency PHP Exploit, Search Engine Roundtable](https://www.seroundtable.com/google-php2shell-42353.html)