PHP critical vulnerability, October 2026

What we know, and what we do not

The facts, as published:

1. Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both with a CVSS v4.0 score of 9.2, which puts them in the range where unauthenticated remote code execution is the expected impact.
2. The fix is a security release scheduled for Wednesday, 21 October 2026 at 14:00 UTC (16:00 CEST) according to php.net. The PHP team reserved the right to publish earlier if details leaked or exploitation appeared.
3. No technical details are public: no root cause, no affected function, no proof of concept. CERT-EU says so explicitly in advisory 2026-018.
4. CERT-EU's assessment is that the vulnerabilities could affect all PHP versions from PHP 5 onwards, and recommends immediate patching, or isolating internet-facing applications from public networks where that is not feasible.

What that means in practice: nothing can be tested yet, and anyone publishing "the exploit" or "the exact mitigation" before 14:00 UTC today is guessing. The one thing that can be decided today, with certainty, is whether your installation is capable of receiving the fix at all. That is the part this article is about.

Why a PHP vulnerability is a Moodle vulnerability

Moodle is a PHP application. Its front page, login form, course pages and web service endpoints are all PHP code executed by the web server, most of them reachable without any authentication. A pre-authentication code execution bug in the language runtime does not need a Moodle bug, a vulnerable plugin or a misconfigured permission to reach: it needs one request, and the runtime does the rest. From PHP you read config.php, and config.php holds the database credentials.

Moodle sites make this worse in two specific ways:

1. They are usually exposed to the internet by design (students and teachers log in from anywhere, and often the whole site is open, including the login page and the web service layer).
2. They age badly. A Moodle site is upgraded every two or three years in the best case, often later, and the PHP version underneath is upgraded even more rarely because the hosting is part of a package, or because "it works, don't touch it".

Those two habits collide exactly today.

The trap: patches only exist for supported PHP branches

PHP does not backport security fixes to end-of-life branches. The support policy is two years of active support plus two years of security-only support, after which the branch is closed per php.net. Today, four branches are alive:

So the patch will land on PHP 8.2, 8.3, 8.4 and 8.5. If a server runs PHP 8.1, 8.0, 7.4 or anything older, the answer to "when will the fix arrive" is never. That is the "only for PHP 8" reading of the news that is circulating, and it is accurate as far as it goes.

Which Moodle versions can run a patched PHP

A Moodle branch supports a range of PHP versions: a minimum, and a maximum that is fixed for the life of the branch and rarely moves. You cannot simply put any PHP under it. The authoritative source is the PHP and Moodle supported versions policy, and the resulting picture today is this:

Release and support dates for the Moodle side come from the official release list: 4.5 is the current LTS until October 2027, 5.3 took over as LTS on 5 October 2026, and 5.0 and everything from 4.4 down are no longer supported by Moodle either.

Three readings of that table matter more than the rest.

The Moodle 4.1 wall

Moodle 4.1 was the previous LTS, the version a great many institutions standardised on, and its maximum PHP is 8.1. PHP 8.1 is end of life. There is no combination of PHP and Moodle that makes a 4.1 site patchable today: to receive the fix, the site must first be upgraded to Moodle 4.5 or later so it can move to PHP 8.2 or higher. That is not a one-hour job, and it cannot be done safely in the same window as an emergency patch. If you are there, the answer for today is isolate, and plan the upgrade.

The Moodle 4.5 LTS on PHP 8.1 case

Moodle 4.5 supports PHP 8.1 as its minimum, so a perfectly supported, perfectly up-to-date 4.5 LTS site can be running a PHP branch that will never see this fix. This is the most misleading configuration of all, because the Moodle side looks healthy. The check is on the PHP version, not on the Moodle version:

1. If your 4.5 site runs PHP 8.1, you are not patchable until you move to 8.2 or 8.3. That is a PHP upgrade only, no Moodle upgrade required.
2. If your 4.5 site runs PHP 8.2 or 8.3, you are patchable as soon as the fixed packages exist.

The bridge that ends on 31 December 2026

Moodle 4.3 and 4.2 cap at PHP 8.2, and PHP 8.2 reaches end of life in 71 days. Patching there buys weeks, not years, and the next vulnerability of this class will leave those sites without a fix. Two EOL layers stacked on each other is not a hosting situation to stay in.

What to do today, in order

1. Inventory before anything else. For every Moodle site: the exact Moodle release (grep -E '\$release' version.php in the Moodle root, or Site administration → Notifications) and the exact PHP version the web server actually executes (php -v, or Site administration → Server → Environment). The PHP version on the command line is not always the one the web server uses: on a per-site pool (php-fpm), check the pool, not the default binary.
2. Back up before touching PHP. A PHP minor jump can expose a plugin that was already incompatible, and the rollback path is the backup, not the package manager. Code and database.
3. Patch PHP, not Moodle. The fixed packages will be PHP point releases on 8.2, 8.3, 8.4 and 8.5. Install the latest point release on the branch you already run, restart PHP-FPM (or Apache), and verify the version the site is actually serving.
4. Respect the maximum. Do not jump to 8.4 on Moodle 4.5 or 4.4 to "get further ahead": those branches stop at 8.3, and you would be trading a security fix for a broken site. Check the maximum in the table above before the upgrade, not after.
5. If no patched PHP is supported by your Moodle, isolate the site. CERT-EU's explicit recommendation. In descending order of preference: put the whole site behind a VPN or an allow-list at the reverse proxy or firewall, and if that is impossible, restrict it at least to the networks that really need it and keep an eye on the access log. Isolation is not a fix, it is time.
6. Then plan the real move. Moodle 4.1 LTS (and anything older) needs to go to 5.3 LTS or 4.5 LTS, which is a multi-step upgrade with a PHP jump in the middle. That sequencing is its own project: it is not a single jump.
7. Watch for the details, not the headlines. Once php.net publishes, read which function is affected. If a virtual patch becomes available for your WAF or your host's runtime, that is a legitimate stopgap for the sites you cannot patch.

What happens next

The fixed version numbers are not public yet: they will be on the php.net releases page at 14:00 UTC. This article will be updated with the exact versions as soon as they exist, and with anything the release notes add about the affected code paths.

If you host Moodle on shared hosting, ask your provider today which PHP branch your plan uses and whether they will apply the update automatically. In our experience the answer arrives after the update was needed, and "the panel says 8.1" is a conversation you want to have before the patch, not after.

If you would rather have someone check the whole estate, that is what we do: version inventory, patch order, and the upgrade plan for the sites that cannot be patched in place.