Google's Mueller: Serve a 503, Not a 404 or 500, if Patching PHP's Critical RCE Flaws Takes Your Site Offline

Ras Al Khaimah, United Arab Emirates, 22 October 2026.

The PHP project shipped emergency security releases on 21 October 2026, and Google's John Mueller used the moment to remind site owners how to take a site offline without hurting its presence in Search. In a Bluesky post on 21 October, Mueller wrote that anyone taking PHP sites down to make time for unplanned updates should "use HTTP 503 instead of letting responses time out / 404 / 500", adding that this can be done outside PHP, by pointing DNS elsewhere or at a CDN.

The advice follows a PHP security advisory describing two critical vulnerabilities that can allow unauthenticated remote code execution. Search industry coverage has nicknamed the pair PHP2Shell.

What PHP disclosed

According to the advisory, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix the flaws, and all PHP users are strongly encouraged to update immediately. The PHP team lists every installation serving web requests as at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates the risk highest for mod_php, where it says a demonstrated exploit can be triggered by an unauthenticated request before any application code runs.

Identifier	Type described by PHP	Interim mitigation PHP lists
CVE-2026-109618	RCE via out-of-memory corruption	Set memory_limit=-1 at server level and lower post_max_size
CVE-2026-109619	RCE via stale global state	Set session.upload_progress.enabled=0 and restart workers

PHP 8.1 and older no longer receive updates from the PHP project, though the advisory says the security team provided minimal source backports for PHP 7.4, 8.0 and 8.1 given the severity, and that Linux distributions and long-term support vendors received patches in advance.

The exposure is wide. Web technology survey W3Techs reported on 22 October that PHP is used by 69.3% of websites whose server-side language it can identify.

What Google recommends during emergency downtime

Mueller linked to two Google resources: a 2011 Search Central blog post on planned downtime and the current guide to temporarily pausing or disabling a website. Together with Google's HTTP status code documentation, they explain the reasoning.

Response during downtime	How Google's documentation says it is treated
503 with Retry-After	Signals temporary downtime; Googlebot may use Retry-After to decide when to recrawl
5xx in general	Crawlers slow down; indexed URLs are preserved but eventually dropped if errors persist
403, 404 or 410	Google says these remove the site's URLs from Search
200 error or placeholder page	The 2011 post lists this among common problems and recommends 503 instead
503 on robots.txt	Google warns this blocks all crawling

Google's pause guide says a full shutdown should last a few days at most and recommends a 503 informational page for urgent closures of one to two days. It also warns that Google cannot refresh titles, descriptions or structured data while a page returns 503, and that a 503 should not be treated as permanent: the 2011 post says lasting 503s can eventually be read as a server being permanently unavailable.

On the robots.txt side, Google's robots.txt specification says that when the file returns a server error, Google stops crawling the site for the first 12 hours while it keeps trying to fetch the file. That is why the pause guide says the robots.txt file should not return 503.

The 2011 post also suggested using a separate server to return the 503 during planned maintenance, which matches Mueller's point that the response can be set outside PHP. That matters this week: a 503 generated by a PHP script still depends on the PHP runtime being patched and running.

What to do

• Patch first. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from your distribution or hosting provider. PHP says there are no complete mitigations.
• If you must go offline, return 503 from the edge. Set it at the CDN, load balancer or web server, or point DNS to a static maintenance host, rather than letting PHP time out or fail with 500s.
• Add a Retry-After header with a best-effort date or duration, as Google's pause guide recommends, and keep the error page static with minimal external resources.
• Keep robots.txt reachable with a 200 response, and do not swap in a disallow-all file, which Google says may remove content and URLs from Search.
• Do not use noindex, 403, 404, 410 or the Search Console removal tool for a temporary closure. Google lists each as a way to drop URLs from Search.
• Verify with curl, as Google suggests, by requesting a page and confirming the 503 status, then watch Crawl Stats in Search Console after the site returns.

Conclusion

The PHP fixes are the priority, and the PHP team is clear that updating is the only full remedy. For sites that need a maintenance window to get there, Google's position has not changed since 2011: a short, clearly temporary 503, served without relying on the vulnerable runtime and kept off robots.txt, is the way to pause without signalling that pages have gone.

Google's documentation also sets the boundary: a full closure should last a few days at most before it starts to affect how the site appears in Search.

Questions and answers

Which PHP versions fix the vulnerabilities?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, fix CVE-2026-109618 and CVE-2026-109619, according to the PHP security advisory.

What did John Mueller recommend?

In a Bluesky post on 21 October 2026, Mueller said site owners taking PHP sites down for unplanned updates should use HTTP 503 instead of letting responses time out or return 404 or 500, and that this can be done outside PHP, via DNS or a CDN.

How long can a site return 503 without harming Search?

Google's guide to pausing a website recommends a 503 for urgent closures of one to two days and says disabling a whole site should last a few days at most.

Should robots.txt also return 503?

No. Google's documentation says a 503 on robots.txt blocks all crawling, and its robots.txt specification says Google stops crawling for the first 12 hours when the file returns a server error.

###