PHP flaw: patching and the 503 rule for your site

The PHP team has issued emergency updates for two critical flaws that can let attackers run code on a website's server without logging in. According to Search Engine Journal the fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP says no workaround fully addresses the flaws and updating is the only safe choice.

Who is affected?

PHP says every installation serving website requests is at risk, with Apache servers using mod_php facing the highest risk. TechCrunch reports that PHP runs roughly 70% of websites and that the flaws exist in every version since PHP 5. PHP 8.1 and older no longer receive regular support; the team has still published limited source-code fixes for those who build PHP themselves.

The flaws were found with AI tools by an OpenAI security partner and by the Wiz team, which worked with PHP on patches before disclosure. According to TechCrunch, OpenAI says there are no known attacks, while Wiz warns that AI also makes such flaws easier for attackers to exploit.

What happens to search visibility if you take the site offline?

Done with the right status code, your pages stay indexed. Google Search Central reminded site owners taking servers offline for PHP patches to return a 503 (Service Unavailable) status, which preserves already indexed URLs; once the site returns 200 again, things return to normal. Generic 404s or error pages served with a 200 code are discouraged.

There is a catch: the 503 has to come from a layer that keeps running while PHP is down, such as a CDN rule or a temporary server you point DNS at. Google's crawl-rate documentation advises against serving a 503 for more than a day or two; a URL that returns it for several days may be dropped from the index. Do not return a 503 for robots.txt, because that blocks all crawling.

What should companies do this week?

The sources give no Turkey-specific data, but corporate sites, online shops and WordPress pages running on PHP carry the same risk. Agree the following steps with the team or host that manages your web and e-commerce infrastructure:

• Find your PHP version (in WordPress: Tools > Site Health > Info > Server) and ask your host in writing to move to a fixed version.
• If you are on PHP 8.1 or older, back up the site and plan an upgrade to a supported version; ask your host whether it offers an interim fix.
• If you cannot patch immediately, consider taking the site offline and serve the maintenance page with a 503 from a layer independent of PHP, keeping robots.txt responding normally.
• If you use a firewall, confirm all visits pass through it; according to Search Engine Journal a WAF may block some attacks but is no substitute for the patch.
• After patching, look for web shells, unfamiliar admin accounts and unexpected PHP file changes; a patch does not remove an existing compromise.
• Decide in advance who patches, who takes the site offline and who watches search visibility. While the site is down, your SEO team should monitor crawl errors in Search Console.