PHP2Shell and Moodle: What Schools and Training Teams Need to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and Moodle HQ has told self-hosted sites to update PHP "immediately." Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in PHP, the language and runtime Moodle is built on. It is not a Moodle bug, and no Moodle upgrade fixes it. A Moodle site is exposed if the PHP build serving it is unpatched, whatever Moodle version it runs. The fix is a patched PHP build on the server, then a restart of every PHP worker.

This guide is for school IT staff and training administrators. For the overview, read what PHP2Shell is and who it affects.

What Moodle HQ Has Said

Moodle HQ posted "Update on Moodle's Response to the PHP2SHELL vulnerability for our public facing sites" on moodle.org news on 22 October 2026. The key points, in its words:

• "As a precautionary measure in response to the PHP2SHELL vulnerability, which was made public on October 21, 2026, Moodle HQ made the decision to take our sites offline."
• "We have patched this site and brought it back online. We are continuing to deploy and validate the patches on our other public facing and client sites".
• "We strongly encourage self-hosted site holders to notify the individual(s) responsible for updating PHP for their sites and to create a plan to update your PHP with the released security patches, immediately."
• "Unpatched sites remain vulnerable to potential exploits related to PHP2SHELL."

Moodle HQ is not shipping a Moodle patch, because there is nothing in Moodle to patch. The post mentions "client sites" but does not name MoodleCloud, and as of 23 October we found no MoodleCloud-specific statement. The accurate summary is that Moodle HQ says it is patching the sites it hosts.

Taking sites offline matches CISA's advice for anyone who can't update right away or runs PHP 8.1 or earlier. If you do it, Beazley Security advises "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials."

Did Researchers Show an Attack on Moodle?

No, not publicly. Calif lists the applications where it confirmed unauthenticated remote code execution on its PHP2Shell page: WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. Moodle is not on that list. Wiz demonstrated attacks only against WordPress, Drupal and Joomla.

Moodle's name does appear on php2shell.com, but only in a strip headed "Common PHP software," separate from the demonstrations.

None of this makes Moodle safer. PHP's advisory covers "all PHP installations serving web requests," and on Apache with mod_php, CVE-2026-109618 fires "entirely before any application-specific code begins execution." Moodle's code never gets to defend itself.

Moodle PHP Requirements by Version

This table combines Moodle's official release and support table with the minimum PHP for each branch, as of 23 October 2026.

Moodle 4.5 is a fully supported long-term release, yet it can run on PHP 8.1, which reached end of life on 31 December 2025 and has only a minimal source backport from the PHP project. Our guide to PHP 8.1 and PHP2Shell lists which Linux distributions and vendors patched it.

Don't jump to PHP 8.5 for "the newest fix." Moodle lists only 8.3 and 8.4 for 5.2 and 5.3, and 8.3.36 and 8.4.27 carry the same PHP2Shell fix as 8.5.12.

Who Patches Your Moodle Site

Whoever controls the PHP on your server fixes PHP2Shell. Often that is not the Moodle administrator.

Moodle HQ's advice to "notify the individual(s) responsible for updating PHP" matters. A teacher, a central IT office and a vendor can each assume someone else has it covered.

How to Check the PHP Version in Moodle

Moodle's PHP documentation says: "An administrator can find PHP info in Settings > Site administration > Server > PHP info." That page shows the PHP version the web server is actually using, which matters because the command-line PHP can be a different build.

The number needs care. Linux distributions backport fixes without changing the upstream version, so a patched Ubuntu 24.04 server still reports PHP 8.3.6 and a patched 8.1 build still says 8.1.34. Check the package version against your distribution's advisory, or ask your host for the build date. Our guide on how to check your PHP version covers each method.

How to Patch a Self-Hosted Moodle Server

If your team runs the server, these are the steps. Use your operating system's packages or an official PHP release, never a third-party "patch script."

1. Find where PHP comes from: distribution packages, a control panel such as cPanel or Plesk, or a container image. Each has its own fixed build.
2. Take a backup first. A backup of the database and the data directory lets you roll back if an update goes wrong. See our guide to website backup and recovery.
3. Install the fixed PHP packages. On Debian or Ubuntu with PHP-FPM, for example (replace 8.3 with your version):
   sudo apt update
   sudo apt upgrade
   sudo systemctl restart php8.3-fpm
   On RHEL-family systems, sudo dnf upgrade installs the fixed packages, and sudo systemctl restart php-fpm restarts PHP-FPM.
4. Restart everything that runs PHP. If Apache runs PHP as mod_php, restart Apache (for example sudo systemctl restart apache2 on Debian or Ubuntu). Restart any long-running PHP process too. An update that isn't loaded protects nothing.
5. Confirm the fix. Reload Site administration > Server > PHP info and compare the build with your vendor's fixed version.
6. Check for earlier compromise. Review logs and files from at least 17 October 2026, the earliest date an exploitation attempt was reported. Our guide on checking whether your site was hacked through PHP2Shell lists what to look for.

Interim Settings and What They Can Break in Moodle

If you can't patch today, PHP's advisory lists settings that reduce exposure. PHP says "only an update is a complete solution" and that these measures "do not make an installation safe." Every setting and its trade-offs are in PHP2Shell interim mitigations. Three Moodle-specific cautions:

• session.upload_progress.enabled=0 should go in php.ini, the FPM pool or server configuration, followed by a restart of every worker. PHP says not to rely on ini_set() or FPM .user.ini. Keep it off after patching too, because of a separate, unlikely issue (CVE-2026-115560) that affects patched builds.
• A lower post_max_size (PHP suggests 32M if uploads are needed) caps every upload on the site. Moodle's documentation is blunt that it "cannot work outside itself": the site's Maximum uploaded file size setting, under Site administration > Security > Site security settings, can't exceed what PHP allows. Large course files and backup restores are the likely casualties. Warn teachers and test an upload afterward.
• Front-end limits on form fields need room. PHP's advisory suggests limiting input field counts at the web server or proxy. Moodle 5.3's release notes say "PHP setting max_input_vars must be >= 5000," so a tight field-count rule in front of Moodle can break large settings and grading forms.

Moving Off End-of-Life PHP

A patched vendor build of PHP 8.1 buys time, not a long-term home. Moodle's release notes set the upgrade paths:

• Moodle 5.3 can be upgraded to from "Moodle 4.4 or later."
• Moodle 4.5 can be upgraded to from "Moodle 4.1.2 or later."

So a 4.1 site reaches 5.3 in two steps, through 4.5. A 4.5 site on PHP 8.1 can first move PHP to 8.3, which 4.5 supports, and then upgrade Moodle on its normal schedule. Patch PHP first, then test any major Moodle upgrade on a copy.

Student records raise the stakes. FERPA protects personally identifiable information in education records, so treat a suspected compromise of your Moodle server as a possible records incident, follow your incident response plan and involve your privacy officer. This is general information, not legal advice. Our guide to PHP2Shell for schools, colleges and districts covers the education-specific obligations.

Conclusion

As of 23 October 2026, Moodle is exposed to PHP2Shell only through the PHP it runs on, and Moodle HQ's advice is the right one: find the person responsible for PHP and get it updated now. Confirm the build that serves your site is patched and restarted, keep upload progress off, test uploads after any setting change, and move Moodle 4.5 sites off PHP 8.1. If your team needs a server patched quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions