Moodle and PHP2Shell: what schools should do now

Your school or college runs its learning on Moodle. Students submit work there, teachers post grades, and the login page is open to the internet. Then you hear that a flaw affecting nearly every PHP website was published on 21 October 2026. Does it touch your Moodle?

Short answer: yes, it can, and Moodle’s own checks will not tell you. The flaw is in PHP, the language Moodle is written in. Here is what that means, what to ask whoever looks after your server, and what to check this week.

What PHP2Shell is, and why Moodle is in it

PHP2Shell is a pair of flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project says both can let an attacker run their own code on a server without logging in. We explain the full story in our post on what the PHP flaw means for your website.

Moodle is not at fault here. But every Moodle site is a PHP site, so every Moodle site sits on top of the flaw until the PHP underneath is updated. A strong admin password, role settings and a tidy list of plugins do not help, because the attack happens in PHP before Moodle’s own code decides anything.

Moodle’s own check will not warn you

This is the part that catches people out. Moodle has an environment check that tells an administrator whether the server’s PHP is new enough to run Moodle. It checks a minimum version. It does not know about this flaw, so it can show a green tick on a server that is still open.

Mindfield Consulting, a Moodle consultancy, gives an example: a site on PHP 8.3.30 passed the Moodle check, yet the fixed release for that line is 8.3.36. Green in Moodle did not mean safe.

Which PHP version should a Moodle site be on?

The PHP project released fixes on 21 October 2026. The first safe release in each line is 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older in those lines is exposed. PHP 8.1 and older have no official fix at all, although some hosting providers have copied the fix into their own builds without changing the version number.

Moodle only runs on certain PHP versions, so you cannot simply jump to the newest. Moodle’s documentation lists PHP 8.1 to 8.3 for Moodle 4.5 and PHP 8.2 to 8.4 for Moodle 5.0. For other versions, check the requirements page for your exact Moodle release. In practice that gives three situations:

• Your PHP is on a supported line but one release behind. This is the easy one. A same-line update, for example 8.3.30 to 8.3.36, is a small step for a host.
• Your PHP is on 8.1. There is no official fix. Ask whether your host’s build carries a copied fix, who supplied it, and plan a move to a newer line.
• Your Moodle is old. Moodle’s release page shows 4.5 as a long-term release with security support until 4 October 2027, and 5.3 as the newest long-term release. A version outside security support, such as 4.1, tops out at PHP 8.1, so a lasting fix means upgrading Moodle first.

What to ask your host or IT person

If someone else runs your server, send these questions today. A good answer has a version number and a date.

1. Which PHP version is serving our Moodle site right now, and does it include the 21 October fix?
2. If it is PHP 8.1 or older, is it a patched package, and who supplied it?
3. Were all the PHP processes restarted after the update? (Old ones keep running the old code until restarted.)
4. Was our server reachable from the internet while it was unpatched, and are the logs kept?
5. How fast does your agreement promise to apply critical fixes?

A host who cannot say when PHP will be patched has given you an answer too. Mindfield suggests that is a reason to consider moving.

You can also look yourself. Moodle’s PHP information page, at /admin/phpinfo.php when you are logged in as an administrator, shows the build actually serving the site. The command line can report a different PHP, so trust that page over what a technician sees in a terminal.

If you cannot update this week

Updating PHP is the only complete fix. PHP’s own guidance says settings and firewall rules are stopgaps. If you truly cannot update straight away:

• Ask your host or developer about the temporary setting PHP suggested, which turns off a feature called session upload progress in the server’s main PHP settings. Krestomatio, a Moodle hosting company, says neither Moodle’s core nor its own plugins use that feature. Check any other plugins you run first.
• Think about taking the site offline until it is patched, and weigh that against exams, deadlines and enrolment. Moodle’s own public sites went offline briefly as a precaution, according to Krestomatio and Mindfield, so you would not be alone.
• Do not rebuild the server before someone has looked at it. Keep the logs.

Signs your Moodle site was already broken into

Mindfield’s timeline has a first attack attempt on 17 October, four days before the fix was public, so patching shuts the door but does not prove nobody got in. Look for:

• Administrator accounts or plugins nobody on your team created.
• PHP files in places that should only hold course files and images, in the Moodle code folder or the folder where uploaded files live.
• Memory errors or crashing PHP processes in the server logs.
• Strange outgoing connections or a server that is suddenly slow.
• Pages or redirects you did not make, or a warning from Google or your host.

If you find any of these, do not just delete the odd file. Isolate the site, keep the logs, and change the administrator passwords and the database password. Attackers usually leave more than one way back in.

A word on student and staff data

A Moodle site holds names, emails, grades and sometimes more. If the server was open and you cannot show it was clean, treat it as a possible data incident and ask whoever advises you on data protection law in your country what you must report and by when. We are not lawyers, and we will not guess which rules apply to you.

Want us to check yours?

We run security checks on websites for a living, and we are happy to look at yours, including Moodle.

• Free: run the PHP2Shell checker. If your server announces its PHP version it tells you whether that version is exposed. If your server hides the version, it says so, which is good practice but means you must ask your host. No outside tool can safely test for the flaw itself, so a good result is one part of the picture.
• Done for you: our website security service checks the server, looks for signs of a break-in, moves a site to a safe PHP version and helps bring it back if it is down.

Then reach us:

• Email hello@wpfoss.com
• WhatsApp +254 118 271 160
• Tell us what you need

If your Moodle site is down or you think it has been hacked, say so in the first line and we will look at it first.

Sources and further reading

• Krestomatio: PHP2Shell and Moodle LMS, patch and admin steps
• Mindfield Consulting: PHP2Shell and Moodle, what it means for your LMS
• Moodle docs: PHP versions required by each Moodle version
• Moodle developer docs: release and support dates
• Tenable: PHP2Shell frequently asked questions
• Qualys: PHP2Shell, find, mitigate and patch now
• Sansec: PHP2Shell research