PHP Security Vulnerability: Check Your Host and Website

On 21 October 2026 PHP fixed two critical flaws that allow code execution without login. What it means for WordPress sites and what you should check.

News · By Kerem Sinecek · Published 22 October 2026 · Updated 23 October 2026 · 6 min read

On 21 October 2026 the PHP project released four security versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that could let an attacker run code on the server without logging in. Every website that runs on PHP is affected, which includes most WordPress sites. If a hosting provider runs your website, find out whether they have already updated.

Update, 23 October 2026: Many site owners are taking their website offline for a while to update PHP. For that period, Google Search Central recommends the HTTP status code 503 instead of a 404 error or an error page served with code 200. According to Google, pages that are already indexed then stay in search. John Mueller of Google confirmed the advice on Bluesky. The details are in the section on visibility in Google.

What happened?

The PHP project announced the security releases on 20 October and published them on 21 October at 14:00 UTC. Both vulnerabilities are rated 9.2 out of 10 under the CVSS v4.0 scoring system. According to the project, they can allow unauthenticated code execution on the server.

The first vulnerability occurs when PHP is interrupted in the middle of handling a request because memory is running low, and then carries on with incomplete data while cleaning up. In the second, internal state from a request survives even though the memory it belongs to has already been freed, and a later request on the same process can use it. The PHP project considers the risk highest with Apache and mod_php; there, it says, an attack is possible before any of the website's own code runs. According to PHP, however, every installation that serves web requests is affected, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

The vulnerabilities are in PHP itself, not in WordPress, a plugin or a theme. WordPress.org writes that a WordPress update is neither needed nor planned; the fix is the PHP update.

What does this mean for your business?

If your website runs on PHP behind the scenes (typically WordPress, Joomla, Typo3 or a PHP-based online shop), it runs either on a hosting provider's server or on your own server with PHP. The one who installs the update is usually not you but the hosting provider, or, on your own server, whoever looks after it.

Managed hosting: The provider normally installs updates itself. Ask whether the release from 21 October is installed.
Shared hosting: You usually cannot patch PHP yourself. Watch for notices from your provider and ask if anything is unclear.
Your own server or VPS: The packages have to be installed and PHP restarted. The PHP project notes that Linux distributions received the fixes in advance, so check your distribution's package. According to the PHP project, the Remi repository did not yet have updates on release day.
PHP 8.1 or older: These versions no longer get updates from the PHP project. For PHP 7.4, 8.0 and 8.1 the project says there are minimal backports in the source code that distributions or hosting providers can apply. Moving to PHP 8.2 or newer is the clean solution. PHP 8.2 itself will receive no security updates after 31 December 2026.

Websites that do not use PHP at all are not affected by these vulnerabilities.

What should you do now?

Find out your PHP version. In WordPress you will find it under Tools, Site Health, Info, Server. For other systems, your hosting provider or agency will know.
Ask your hosting provider whether the security release of 21 October 2026 or an equivalent patch from the distribution is installed. Some distributions fix the vulnerability without changing the version number.
Make a backup (files and database) before the PHP version is changed, and test the website afterwards.
On your own server, install the PHP update and restart the PHP processes.
If an update is not possible right away: The PHP project lists measures that narrow individual attack paths but explicitly do not offer complete protection, such as session.upload_progress.enabled = 0 at server level. That is a stopgap, not a substitute for the update. If you have no server experience of your own, leave this to your hosting provider or a technical specialist.

A web application firewall, as offered by some hosting providers or Cloudflare, can add protection. According to the PHP project and WordPress.org, however, it does not replace the update.

What about visibility in Google if the website is briefly offline?

If your website is down while PHP is being updated, what matters is the status code that visitors and Google's crawler receive. According to a report by Search Engine Journal (21 October 2026), Google Search Central recommends 503 (Service Unavailable). A blanket 404, or an error page served with code 200, can instead give the impression that the content is gone. According to Google's documentation, the indexing pipeline removes URLs that persistently return a server error.

Points to watch:

Keep it short: Search Engine Journal refers to Google's documentation on crawl rate, according to which a 503 should be served for no more than one to two days. After that, pages risk dropping out of the index.
Keep robots.txt reachable: robots.txt should not answer with 503 either; according to this account, that would block crawling altogether.
Not from PHP itself: If PHP is the very thing that is broken, the 503 can come from outside, for example from a CDN or a maintenance page at your hosting provider. That is the gist of what Mueller said.
Retry-After: Optionally, the Retry-After header can tell Google when to try again.

For most businesses the rule is simple: an update by the hosting provider runs without noticeable downtime. Clarify that first, before you switch anything off yourself.

What is still open?

According to trade media reports, the technical details were circulating before the release. Whether and to what extent the vulnerabilities are already being actively exploited is not documented in the primary sources we checked, so we make no statement about it. An advisory from Germany's Federal Office for Information Security (BSI) was not available to us at the time of writing. This article is as of 23 October 2026; hosting providers and distributions are rolling out their updates at different speeds over the coming days.

How can KSTAQ help?

At KSTAQ in Dortmund, questions like these can be handled as part of the care plan: we check what technology your website runs on and see any necessary update through. If your site is getting on in years anyway, a new website may be the more sensible solution. Send us a short note about what you use, and we will tell you what needs doing. This article is general information and not individual IT security advice.