Critical PHP Flaws Patched; Google Says Serve 503 During Downtime

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution, both rated 9.2 on CVSS v4.0, and told every PHP user to update immediately. The same day, Google Search Central and Google's John Mueller reminded site owners who take servers offline to patch that they should serve an HTTP 503 status code, not timeouts, 404s or error pages returned with a 200, so indexed pages survive the downtime. The fixed versions and the risk details come from the PHP.net security advisory published on 21 October 2026.

What PHP announced on 21 October

The PHP security team gave advance notice on 20 October 2026 that a security release was scheduled for Wednesday 21 October at 14:00 UTC, addressing two critical vulnerabilities both rated CVSS v4.0 9.2. The release followed on 21 October with fixes on the four supported branches. Each release announcement says there are no complete mitigations and that updating is the only safe choice.

The fixed versions, as listed by PHP.net, are below. If your server runs an older patch release on any of these branches, it is not fixed.

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. According to PHP.net, the first, "RCE via OOM corruption", happens when out-of-memory handling interrupts PHP while internal request data is only partly initialised, so request cleanup may treat invalid data as valid. The second, "RCE via stale global state", happens when request-owned internal state survives after its memory has been freed, so a later request handled by the same worker may use that stale state before normal initialisation resets it.

Who is at risk, according to PHP

PHP.net says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers the risk highest for mod_php, where it says a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. For WordPress owners, the implication is that a security plugin cannot be relied on here: if the attack happens before application code runs, it happens before WordPress loads.

Older PHP versions

PHP 8.1 and older no longer receive updates from the PHP project. PHP.net says some Linux distributions and long-term-support vendors provide backported fixes, and that given the severity, the PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source or have no LTS vendor. Linux distributions and LTS vendors received the patches in advance, so PHP advises checking your vendor for updated packages. Search Engine Roundtable, which reported that the flaws are being called "PHP2Shell", said all versions from 5.4 through 8.5.11 are vulnerable.

If you cannot update straight away

PHP.net lists interim measures, while stressing that they reduce exposure to specific attack paths and do not make an installation safe. They are server configuration changes, for example setting session.upload_progress.enabled=0 and restarting every worker, setting a low post_max_size, and on PHP 8.5 setting fatal_error_backtraces=0. The advisory gives exact conditions for each, including that some settings must be applied in php.ini or the FPM pool rather than through ini_set() or .user.ini. These are tasks for whoever administers the server, and they are a stopgap, not a fix.

Why sites went offline, and why that is an SEO question

Search Engine Roundtable reported on 21 October that many sites were patching without downtime, but that many others were going offline until patches were in place. It quoted Reuters reporting that several government, school and hospital websites in Europe were taken offline as organisations rushed to protect themselves. Taking a site down is a reasonable security call. How the site responds while it is down is what decides whether its Google rankings and indexed pages come through intact.

Google Search Central: "Don't forget the 503"

According to PPC Land, Google Search Central posted a reminder on its LinkedIn page on 21 October for everyone running emergency PHP patches or taking servers offline. It said serving a 503 (Service Unavailable) status code ensures already indexed URLs are preserved in Search while you work, that things return to normal once the site serves 200 responses again, and that site owners should avoid generic 404s or 200 error pages during downtime. The post linked to Google's documentation page "How HTTP status codes affect Google's crawlers", which shows a last-updated date of 4 February 2026, so the guidance itself is not new.

John Mueller: do it outside PHP

John Mueller of Google wrote on Bluesky on 21 October, in a post quoted by Search Engine Roundtable, that anyone taking PHP sites down should use HTTP 503 instead of letting responses time out or return 404 or 500, and that this can be done outside of PHP, by pointing DNS elsewhere, or at a CDN. The reason is practical: if PHP is the component being patched, a 503 generated by a PHP maintenance plugin may not be available, so the 503 needs to come from the web server, a load balancer, a CDN rule or a separate host.

How Google treats each status code during downtime

Google's documentation explains the mechanism behind the advice:

• 5xx, including 503: Google's crawlers temporarily slow down crawling. Already indexed URLs are preserved in the index, but eventually dropped. Content received with a 5xx is ignored. Once the server returns 2xx again, Google gradually increases the crawl rate. Google says its indexing pipeline removes URLs that persistently return a server error.
• 404 and 410: Google's guide to pausing a site says returning 403, 404 or 410, or using noindex, will remove the site's URLs from Google Search.
• 200 with an error message: if the content of a 200 page looks like an error or an empty page, Search Console reports it as a soft 404.
• Timeouts: Mueller named letting responses time out as one of the things to avoid.

So a 503 is protection with a time limit. It buys time, but it does not keep pages in the index forever.

How long is safe, according to Google

Google's guide "Temporarily pause or disable a website" says disabling a whole site is an extreme measure that should only last a very short period, a few days at most. For an urgent shutdown of one to two days it recommends an informational error page with a 503 status. For longer closures it recommends an indexable placeholder home page served with a 200 status instead. Google's 2011 Search Central blog post on planned downtime adds that a lasting 503 can eventually be read as a sign that the server is permanently unavailable, which can lead to URLs being removed. Google does not give an exact number of hours beyond that guidance.

Google's best practices for the 503 page

• Keep robots.txt reachable. Google says not to return a 503 for robots.txt, because that blocks all crawling, and not to serve a robots.txt that disallows all crawling.
• Add a Retry-After header with a best-effort date or duration. Google's 2011 post says Googlebot may use it to decide when to recrawl.
• Use static HTML with minimal external resources, and tell visitors when the site is expected back and how to reach you.
• Confirm the status code yourself, for example with curl -I -X GET against your home page, and check the response line reads 503.
• Do not use Search Console's temporary removal tool for a closure.

Practical steps for WordPress and PHP site owners in Thailand

The steps below are guidance built from the PHP advisory and Google's documentation. Your hosting provider's own instructions take priority.

1. Find your PHP version in WordPress. In wp-admin, go to Tools, then Site Health, then the Info tab, and open the Server section. It shows the PHP version the site is running. Compare the full number, not just the branch: 8.3.35 is vulnerable, 8.3.36 is fixed.
2. Check the hosting panel. Control panels such as cPanel, Plesk and DirectAdmin show the PHP version per domain. On shared hosting you usually cannot patch PHP yourself, so the host has to update it.
3. Ask the host a precise question. If your host uses Linux distribution packages, the version string may follow the vendor's numbering rather than PHP.net's. Ask whether the PHP serving your site includes the fixes for CVE-2026-109618 and CVE-2026-109619, and get the answer in writing.
4. If you run PHP 8.1 or older, plan an upgrade to a supported branch or confirm that your vendor provides a backport, as PHP.net advises. Test themes and plugins on a staging copy first.
5. If you must go offline, serve the 503 from outside PHP: the web server, the CDN or a separate host. Keep robots.txt returning 200, add Retry-After, and keep the downtime to a day or two at most, in line with Google's guidance.
6. Do not use a maintenance page that returns 200. Some maintenance or "coming soon" setups can return 200, so check the status code with curl; Google classes error pages served with 200 as soft 404s.
7. After patching, confirm the site returns 200 again, check Search Console's Page indexing and crawl stats reports over the following days, and confirm the new PHP version in Site Health.

What the sources did not say

• PHP.net's advisory does not give figures on how many sites have been attacked, and this article does not estimate any.
• Google did not say how many days of 503 a specific site can sustain; its documentation speaks of a few days at most.
• No source in this article says whether any particular Thai hosting provider has patched.

What this means for Thai marketers

For businesses whose WordPress or WooCommerce site brings in leads or sales, this is a security issue first and a search issue second, and both have a clock on them. Confirm the PHP version today, push your host for a written answer, and if the site has to go down, make sure it returns 503 rather than an error page. If indexed pages slip after a rough patch window, a technical SEO audit can trace what crawlers saw. For older sites stuck on unsupported PHP, it may be time to review the stack with a web design and development partner, and to protect the SEO in Thailand work already built on the site.

FAQ: the PHP patch and Google's 503 advice

Which PHP versions fix the two critical vulnerabilities?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix them, according to PHP.net's 21 October 2026 advisory. Anything older on those branches is not fixed, and PHP 8.1 and older need a vendor backport or an upgrade.

How severe are the flaws?

Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution. PHP.net says the risk is highest for Apache with mod_php, where an exploit can run before any application code.

Will taking my site offline hurt my Google rankings?

A short outage served with a 503 status should not, because Google preserves already indexed URLs while it sees 503s. Long outages are different: Google says persistent server errors eventually lead to URLs being dropped, and recommends disabling a site for a few days at most.

Why not just show a maintenance page?

A maintenance page is fine only if it returns a 503 status code. If it returns 200, Google can treat it as a soft 404, and a 404 removes URLs from Search.

How do I check my PHP version in WordPress?

Open wp-admin, go to Tools, Site Health, Info, and expand the Server section to see the PHP version. Your hosting control panel shows it too.

Patch first, then check that Google saw a clean 503 and a clean recovery. Site owners who want a second pair of eyes on indexing after this week's PHP updates can contact the Relevant Audience team.