Outdated PHP under Moodle is a security hole, not a detail

If your Moodle site runs on PHP 8.1 or older, it is running on a language version that no longer gets security fixes from the PHP project. That was a theoretical problem until 21 October 2026. On that day PHP shipped fixes for two critical remote code execution bugs, and the fixes went only to PHP 8.2 and newer.

Most training managers never see the PHP version. It sits under Moodle, set up once by whoever built the server. That is exactly why it gets old.

What happened in October 2026

On 21 October 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, a pair of bugs that got the nickname “php2shell”. Both were announced a day ahead with a CVSS v4.0 score of 9.2. PHP’s advisory describes them like this:

• CVE-2026-109618: an out-of-memory condition can leave request data half set up, and the cleanup code then treats it as valid.
• CVE-2026-109619: a fatal error can leave state pointing at freed memory, and a later request on the same worker uses it.

The sentence that should worry anyone running Moodle is this one from the PHP team: “We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

Before any application code runs means before Moodle runs. Moodle’s login page, its capability checks and its input cleaning never get a chance to act. A well-maintained Moodle on top of a vulnerable PHP is still a vulnerable site.

Canada’s Cyber Centre published an alert the same day. It notes that proof of concept code is public, and that the Cyber Centre had not seen active exploitation. On 23 October PHP added a separate note about a third issue, CVE-2026-115560, and recommended setting session.upload_progress.enabled=0 until the next regular release.

Which PHP versions still get fixes

PHP gives every release two years of bug fixes, then two years of security fixes only, then nothing. The official table as of today:

Three things stand out:

1. PHP 8.1 ended on 31 December 2025. Its last release is 8.1.34, according to php.net’s end of life page. It did not get the php2shell fix.
2. PHP 8.2 ends on 31 December 2026. That is about two months from now. The php2shell fix (8.2.35) may be one of the last it gets.
3. PHP 7.4 and 8.0 have been dead for years. 7.4 ended in November 2022 and 8.0 in November 2023.

For PHP 7.4, 8.0 and 8.1, the PHP security team did something unusual: it pushed minimal source backports of the php2shell fix to separate branches. That helps people who compile PHP themselves. It is not a release, there are no packages, and nobody promises it for the next bug. The PHP team’s own advice is to “contact your vendor for details, or upgrade to a supported version.”

Why Moodle sites end up on old PHP

PHP and Moodle versions are tied together. Every Moodle release lists the PHP versions it supports, and you can’t move one without checking the other.

Data from Moodle’s release table and each version’s release notes.

Look at Moodle 4.1 LTS. Its newest supported PHP is 8.1. Both lost security support in the same month, December 2025. A lot of organisations picked 4.1 because “LTS” sounded safe, and many of them are still on it. Those sites now sit on an unsupported Moodle, on an unsupported PHP, and they missed the php2shell fix twice over.

The usual chain of events looks like this. The site was built on Ubuntu with the distribution’s PHP. Nobody wanted to touch it while courses were running. The one custom plugin from 2021 throws warnings on newer PHP, so the PHP upgrade got pushed back. Then the Moodle upgrade got pushed back because it needs newer PHP. Each delay makes the next step bigger.

Moodle has its own steady stream of fixes

Moodle publishes security advisories with every point release. Just in September and October 2026, moodle.org/security lists ten of them. Two are rated Serious:

• MSA-26-0042: blind SQL injection risk in the profile availability condition check. Fixed in 5.2.3, 5.1.7, 5.0.10 and 4.5.14.
• MSA-26-0044: missing access checks on H5P content files, so users who were not logged in could view H5P content they should not see. Fixed in 5.2.4, 5.1.8, 5.0.11 and 4.5.15.

Note what is missing from those fix lists: 4.1, 4.4 and everything older. If you are on those versions, you will not get these patches.

An older case shows how bad it can get. In August 2024, RedTeam Pentesting disclosed CVE-2024-43425: Moodle’s calculated questions passed formulas to PHP’s eval() with incomplete filtering. Any user allowed to add or edit questions, a normal teacher for example, could run commands on the server. It was fixed in 4.1.12, 4.2.9, 4.3.6 and 4.4.2. Sites on releases that were already unsupported never got a fix, and the details and test scripts are public.

What running unsupported versions costs

Nobody sends you an invoice for running old software. The cost shows up in other places:

• Your incident response gets harder. When a fix exists only for newer versions, you are left to backport it yourself or to accept the risk in writing.
• Data protection gets awkward. Moodle holds names, emails, grades and sometimes ID documents. Telling a regulator that the server ran software its vendor stopped patching is a bad position to be in.
• The upgrade gets more expensive every month. Going from 4.1 to 5.3 is not one step. Moodle 5.3 only upgrades from 4.4 or later, so a 4.1 site needs an intermediate stop, plus a new PHP, plus a new database version.
• Custom plugins rot. Code written for PHP 7.4 often hits deprecations and removed functions on PHP 8.3. The longer it waits, the more there is to fix at once.

What to do this month

If you are a training manager or IT lead, ask your hosting team three questions:

1. Which PHP version does the Moodle server run, exactly? Ask for the full number, like 8.3.36, not “PHP 8”. If the server runs a distribution’s PHP package, ask whether that package includes the 21 October fixes. Distributions often backport fixes under older version numbers.
2. Which Moodle version and point release? Site administration shows it under Notifications. Compare it with the release table above.
3. Which plugins are installed that did not come with Moodle? These are the usual reason upgrades get delayed.

If you are on Moodle 4.5 with PHP 8.1, move PHP to 8.3 now. Moodle 4.5 supports it, and it gets security fixes until the end of 2027. If you are on 4.5 with PHP 8.2, you have until 31 December 2026. Use that time.

If you are on Moodle 4.1 or older, you need a real upgrade plan, not a patch. Plan it as a project with a staging copy and a list of every custom plugin.

The part where we come in

Most of the upgrade projects we see are not blocked by Moodle itself. They are blocked by one or two custom plugins that nobody wants to touch, because the person who wrote them left. We fix those plugins, or rewrite them, so they pass moodle-plugin-ci on the PHP and Moodle versions you are moving to. Small fixes often take two or three days.

For sites that want to stop worrying about this, our care plan keeps your plugins working through Moodle and PHP upgrades.

Sources

1. PHP Group, Supported versions and Unsupported branches.
2. PHP Group, News archive 2026: security releases and advisory of 21 October 2026, informational advisory of 23 October 2026.
3. Canadian Centre for Cyber Security, AL26-026: Critical vulnerabilities impacting PHP.
4. Moodle HQ, Releases and support dates, Moodle 4.1 and Moodle 4.5 release notes.
5. Moodle HQ, Security announcements.
6. RedTeam Pentesting, RT-SA-2024-009: Remote code execution via calculated questions.