← All resources

Critical PHP flaws: your website is affected (21/10/2026)

Published October 22, 2026 · 7 min read · CyberNovaLabs.io

Two critical vulnerabilities in PHP, the engine under most small-business websites, allow unauthenticated remote code execution. Patches shipped on 21 October 2026. What to check this week, and what will never be fixed.

In brief

On 20 October 2026 the PHP security team did something it rarely does: announce a critical release before shipping it, so that everyone could prepare. It fixes two vulnerabilities, both rated 9.2 out of 10 on CVSS v4.0^[1]. The patches landed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35^[3], and both flaws — CVE-2026-109618 and CVE-2026-109619 — allow remote code execution with no credentials at all^[3][5][6].

Why a PHP flaw is your problem even if you do not use PHP

Few small businesses ever chose PHP. It is simply the engine underneath WordPress, Drupal, Joomla, Adobe Commerce (Magento), Nextcloud, and a large share of custom intranets, extranets and customer portals. You never see PHP, but it runs on every visit to your site.

CERT-EU is blunt about the scope: every PHP installation that serves web requests is at risk, whether it runs as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed, and the PHP team considers mod_php the highest-risk setup^[3]. Here is the part that matters for a small business: the attack succeeds before any of your application code runs, in a single unauthenticated request^[3]. No login page, no security plugin and no strong password sits in the way. This is not a WordPress vulnerability; it is a vulnerability underneath WordPress.

The two flaws, in plain language

CVE-2026-109618 (RCE via OOM corruption, 9.2)^[5]: PHP aborts a request that exceeds its configured memory limit. That abort can happen while the request's internal data is only partly initialised — for example while parsing a file-upload form. Request cleanup then treats the invalid data as valid and frees memory that was never initialised, memory that may still hold data the attacker chose^[3].

CVE-2026-109619 (RCE via stale global state, 9.2)^[6]: internal state owned by one request survives after its backing memory has been freed, for instance after a fatal error. A later request handled by the same worker can then use that stale state before normal initialisation resets it^[3][4].

One point of honesty about exploitation: at the time of writing, none of the advisories we read reports confirmed exploitation in the wild. CERT-EU does note that technical details are now being discussed publicly and that proofs of concept have begun to circulate, which raises the likelihood that attackers are already exploiting the flaws, and it advises patching immediately^[3].

The trap: versions that will never get a fix

This is the genuinely bad news for smaller firms. CERT-FR lists as affected PHP all versions 5.x, 6.x, 7.x, 8.0.x and 8.1.x, branches the vendor no longer supports, and recommends isolating the affected systems and then migrating to a maintained version^[2].

PHP branch	Fixed version	Status
8.5.x	8.5.12	supported
8.4.x	8.4.27	supported
8.3.x	8.3.36	supported
8.2.x	8.2.35	supported
8.1.x and older (8.0.x, 7.x, 6.x, 5.x)	none	end of life, no fix

If your site runs PHP 7.4 or 8.1 — still common on brochure sites built a few years ago and never touched since — there is no patch to apply. This stops being a security update and becomes a migration: plugin and theme compatibility, a test environment, sometimes code changes. Budget weeks, not hours. It is also why the PHP version your provider serves is not a technical detail to leave unsupervised: see what your IT provider's remote access really exposes and the case of self-hosted tools such as Jira and Confluence, which raise exactly the same question of who is accountable.

CERT-FR's temporary workarounds, and their limit

CERT-FR offers two mitigations, while stating itself that they are not qualified by its teams^[2]:

• in php.ini, turn off upload progress tracking: session.upload_progress.enabled = Off; if PHP-FPM is running, also set php_admin_flag[session.upload_progress.enabled] = off. Read this part twice: the measure only reduces the attack surface against one of the two vulnerabilities^[2];
• block every HTTP request whose Content-Type header is multipart; where blocking is impossible, monitor those requests instead. Both measures can be applied at web application firewall (WAF) level^[2].

Mind the side effect: blocking multipart also kills legitimate file uploads — contact forms with attachments, document submission, media libraries. Test it outside production before switching it on, and watch closely if a form is how you receive enquiries.

Four countries, same versions, different authorities

The version numbers you need are identical in the Netherlands, Belgium, France and Luxembourg. What differs is who publishes the advisory and who you must notify after an incident.

• France: CERT-FR alert CERTFR-2026-ALE-014 of 21 October 2026, stated risk remote arbitrary code execution^[2].
• Netherlands: advisory NCSC-2026-0443 of 21 October 2026, rated high/high by the Dutch NCSC^[4].
• Belgium: the CCB (CERT.be) is the national authority to follow; the fixed versions are the same.
• Luxembourg: CERT-EU advisory 2026-018 of 21 October 2026 is the reference readable across all four countries^[3].

If your organisation falls within NIS2 scope, a significant compromise through this flaw can trigger your notification duties towards your national authority. Scope and deadlines depend on each country's transposition law, so check it before you need it, using our country notes on NIS2 in Belgium and NIS2 in the Netherlands, or the tools in our cybersecurity hub.

At CyberNovaLabs.io

We run this inventory for our clients: every internet-facing site, the PHP version each server actually serves, and the list of what must migrate because no fix is coming. It is often the first time a company sees the real age of its web stack on a single page. If you want that inventory for your estate, or a site rebuilt so it is no longer a stowaway on PHP 7.4, let us take twenty minutes — and start with our cybersecurity hub and our websites for small firms.

Sources

1. PHP — Upcoming Critical PHP Security Release (20/10/2026)
2. CERT-FR — CERTFR-2026-ALE-014, Multiples vulnérabilités dans PHP (21/10/2026)
3. CERT-EU — Security Advisory 2026-018, Critical Vulnerabilities in PHP (21/10/2026)
4. NCSC-NL — NCSC-2026-0443, Kwetsbaarheden verholpen in PHP (21/10/2026)
5. CVE-2026-109618 — RCE via OOM corruption (CVSS v4.0 9.2, 21/10/2026)
6. CVE-2026-109619 — RCE via stale global state (CVSS v4.0 9.2, 21/10/2026)

Read next