PHP fixes two critical flaws: what to check if you have a website

You probably have never typed a line of PHP, but you use it every day. PHP is the language behind WordPress and a huge share of the websites you visit. On Wednesday, October 21, 2026, the PHP project shipped an emergency security release for two bugs it rates critical, and this one is worth a few minutes of your time if you own any kind of website.

What happened

The PHP security team gave advance notice on php.net on October 20 that a release was coming the next day at 14:00 UTC (10:00 a.m. Eastern), fixing two critical vulnerabilities both rated CVSS v4.0 9.2. On October 21 it published PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 along with a security advisory titled “Critical remote code execution vulnerabilities, update now.”

The two bugs, per php.net and PHP’s GitHub security advisories:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption.” When PHP runs out of memory, it can be interrupted while internal request data is only partly set up. The cleanup that follows can then treat that broken data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state.” Some internal state can outlive the memory it points to, and a later request handled by the same worker can use that stale state before it gets reset.

In plain terms, both can let an attacker run their own code on a web server without logging in. PHP says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers mod_php the highest risk, with a demonstrated exploit where a single unauthenticated request triggers the attack before any site code runs. Both CVE records are on NVD (second record), still awaiting NVD’s own analysis.

Which versions are fixed

PHP branch	Fixed in
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Every version before those on each branch is affected. PHP 8.1 and older no longer get official releases. Because these bugs are so serious, the PHP team did publish minimal source patches for 7.4, 8.0, and 8.1, and some Linux distributions backport fixes, but the real answer for an old version is to move to a supported one. Also note that PHP 8.2 reaches end of life on December 31, 2026, so if you are on 8.2, plan that move now.

The PHP team’s own words are blunt: “There are no complete mitigations, updating is the only safe choice.” I agree. The workarounds on php.net are for server admins buying time, not a fix.

If you have a personal WordPress site or a hosting account

Most people with a blog, a portfolio, or a family site are on shared or managed hosting. In that setup your host runs PHP, not you. Here is what I would do today:

1. Find your PHP version. In WordPress, go to Tools > Site Health > Info and open the Server section. Most hosting control panels (cPanel, Plesk, and the custom dashboards) also show it, often under a “PHP version” or “PHP settings” page.
2. Check that it is on a fixed release. You want 8.5.12, 8.4.27, 8.3.36, 8.2.35, or newer. Some hosts run distribution packages with backported fixes and a different version number, so if the number looks old, ask.
3. Ask your host directly. Open a support chat and ask whether they have patched CVE-2026-109618 and CVE-2026-109619. A good host will have a status post up today. If they shrug, that tells you something about who you are trusting with your site.
4. Get off old PHP. If your site is on 8.1, 7.4, or older, switch to a supported version in your host’s panel. Update WordPress, your theme, and your plugins first, and take a backup before you change anything.
5. If you run your own server or VPS, install your distribution’s updated PHP packages and restart PHP-FPM or Apache so the new code is actually loaded.

The stopgaps while patches roll out

Two kinds of temporary protection showed up on October 21. Neither one is a fix, but both explain some of what you may notice this week.

Web application firewalls

A web application firewall, or WAF, is a filter that sits in front of a website and blocks requests that look like known attacks before they ever reach PHP. Here is what the vendors I could confirm say they did:

• Cloudflare. Its blog post says customers using its free or paid WAF were protected by default starting at 3:02 a.m. UTC on October 21 (11:02 p.m. Eastern on October 20), about nine hours before public disclosure, and that it saw attack traffic aimed at its customers. Its WAF changelog lists an emergency release adding seven rules. Cloudflare CTO Dane Knecht called it “a STOPGAP only,” and Cloudflare’s own post still tells people to patch.
• Imunify360. This security suite is common on shared hosting. Its blog post says WAF ruleset 8.83 blocks the publicly circulating exploit pattern on servers using ModSecurity or Coraza. On LiteSpeed servers that rule cannot run, so a second rule only logs matching requests. Imunify calls it a virtual patch and warns that a request that differs from the known pattern may still get through.

The catch is the same for both: a WAF blocks the attacks people already know about. PHP itself says only an update is a complete solution. A firewall buys your host time; it does not let you skip the update.

Hosts that pulled sites offline

Some providers decided a few hours of downtime beat the risk of a break-in, and switched PHP sites off until patched PHP was installed:

• Scaleway (France) posted on its status page that it had taken its Webhosting websites offline as a precaution while it applied the patched PHP versions, and did the same for its BookMyName services.
• Mijndomein (Netherlands) said on its support page that it took all customer websites offline preventively, including its webhosting and managed WordPress plans and webmail, and started bringing them back at 18:05 local time (12:05 p.m. Eastern) after rolling out the new PHP versions.
• Passbolt, the password manager, took Passbolt Cloud offline until the patch was deployed, even though it said it saw no sign of exploitation, and has since marked the issue resolved.

So if your own site, your webmail, or a site you use was briefly unreachable on October 21, this may be why. That is a host doing the careful thing. Once it is back, it is still worth confirming the PHP version yourself.

For everyone else

If you do not own a website, there is nothing for you to install. This is a server problem, and the fix belongs to the people running the sites you use. The NSA’s cybersecurity account urged organizations running PHP to be ready to update and, if they cannot update right away, to take systems offline until they can. That is a strong signal of how seriously this is being taken.

What it means for you in practice: if a site you use announces a breach in the coming weeks, take it seriously. Change that password, make sure you are not reusing it anywhere, and turn on two-factor sign-in where it is offered. A password manager makes that painless.

The bottom line

This is the kind of bug that gets exploited fast. If you have a website, spend five minutes today confirming your PHP version and asking your host about these two CVEs. If you do not, keep your passwords unique and let the site owners do their part.

Image: PHP logo by Colin Viebrock (php.net), CC BY-SA 4.0, on a plain gradient background.