PHP Vulnerability 2026: Critical Security Alert for CVE-2026-109618 and CVE-2026-109619

Your hosting provider says the servers are patched. Your agency says the sites are current. Somewhere in the estate there's a Docker image, a vendor appliance, or a PHP 7.4 app nobody has opened since 2022.

Two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026. Both allow unauthenticated remote code execution before your application code runs. Updating a CMS or a plugin changes nothing.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. The PHP project states there are no complete mitigations and that updating is the only safe choice.

Why the CMS update doesn't help

The bugs sit in memory management and error handling — code paths nearly every request touches. PHP parses the request before WordPress, Drupal, or Magento sees it.

Two consequences people are getting wrong right now:

• A fully current CMS on an unpatched runtime is fully exploitable. Unauthenticated code execution has been demonstrated against current releases of all the major PHP applications.
• Maintenance mode doesn't count. PHP parses the request before the CMS checks its maintenance flag. A "down for maintenance" page on an unpatched runtime is a live target.

A WAF rule buys time against known request shapes and nothing more. Cloudflare's CTO called its own mitigations a stopgap and told people to patch.

Five steps

1. Inventory every PHP runtime — hosts, containers, build images, control panels, and vendor products that bundle PHP without advertising it.
2. Apply the update from your distribution, LTS vendor, or source.
3. Restart or redeploy. PHP-FPM pools, Apache, LiteSpeed, containers. A patched package with a running old worker is still exploitable.
4. Verify the SAPI version, not the CLI version.
5. Review logs for pre-patch activity and record what changed, when, and who verified it.

Step 4 is the one that catches people. php -v reports the CLI binary, which can be a different build from the PHP-FPM pool or mod_php module serving traffic. Put a one-line phpinfo() behind an allowlist, load it over HTTP, read the version and the Server API line, then delete the file.

Where PHP hides

Four places, in order of how often they're missed:

• Managed hosting and control panels. cPanel and Plesk let each site pick its own PHP version. Check per site, and get the patched package version from your provider in writing.
• Containers. The image tag (php:8.3-fpm) tells you the branch, not the patch level. Pull the latest digest, run php -v inside it, redeploy.
• Appliances and bundled PHP. Monitoring dashboards, VoIP admin panels, vendor products that never mention PHP anywhere in their docs.
• Your build pipeline. A CI runner on an old base image can quietly rebuild a patched image back to an unpatched one.

Sophos made the point to the BBC that the hard part isn't installing the patch — it's finding every PHP instance. If nobody on your team can say which version production serves, that gap is itself the finding.

If you can't patch today

Isolate. Several agencies advised taking internet-facing systems offline until the fix is applied and verified, and large operators took that advice: government platforms in Finland, the Netherlands, Australia, and the UK went dark as a precaution rather than because of a breach.

The pattern that worked was read-only behind a CDN. Australia's GovCMS disconnected its origin and served cached pages via Akamai overnight. Visitors kept getting pages, the exposed surface dropped to zero, and the cost was a night without content editing. Cheap caution.

The partial mitigations in PHP's advisory (memory_limit=-1, a low post_max_size, session.upload_progress.enabled=0) reduce exposure to specific paths. They do not make an installation safe.

Checking whether you were already hit

Three detection signals worth grepping for:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s.
• Oversized or malformed PHPSESSID response cookies — the first bug can leak process memory into the session cookie, Heartbleed-style.
• Unexplained PHP worker crashes or restarts.

Their absence doesn't prove you're clean. Patch regardless, then look for web shells, new cron entries, and unexpected outbound connections.

On exploitation: attempts are confirmed at scale and automated, with Cloudflare reporting millions by the evening of the 21st. Publicly confirmed successful breaches are a different question and, as of 22 October, a thinner one. Nobody can tell you your server wasn't one of the successes.

The decision that outlasts the week

Branches 8.1, 8.0, and 7.4 got minimal source backports and no binary releases. Researchers trace the affected code back as far as PHP 5.4.

So most of your fleet needs a package update and a restart. That's not a project, and anyone telling you otherwise during a 48-hour incident is selling something. The exception is the app on 8.1 or older with no vendor binary. Building PHP from patched source once is a day's work. Doing it for every future PHP CVE, across a fleet, with an extension stack that may not compile, is an ongoing tax.

Patch first. Verify the served version. File the compromise assessment. Then look at the list of runtimes that have no binary fix coming — that list, not the CVE, is what tells you whether you have a patch or a project.

Fuller write-up with the version table, UTC timeline, and what to keep for auditors: teamvoy.com/blog/php-vulnerability-2026

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.