Emergency PHP Fix: Critical Flaws Let Attackers Run Code on Websites, Including WordPress

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.

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.

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.

Sources

• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 security advisory, PHP
• Critical security issue affecting PHP, National Cyber Security Centre
• Critical Vulnerabilities in PHP, CERT-EU Security Advisory 2026-018
• Don’t forget the 503, Google Search Central on LinkedIn
• John Mueller on taking PHP sites down, Bluesky
• Reduce Google crawl rate, Google Crawling Infrastructure
• Temporarily pause or disable a website, Google Search Central
• How to deal with planned site downtime, Google Search Central Blog (2011)
• Critical PHP security release, WordPress.org News
• Update your PHP today, WordPress.org
• Critical PHP Core Security Flaws Affect Websites, Including WordPress, Search Engine Journal
• Google Reminds Sites To Serve A 503 During PHP Patch Downtime, Search Engine Journal
• Google On Taking Sites Down When Fixing The Emergency PHP Exploit, Search Engine Roundtable