PHP2Shell: two critical PHP flaws mean Moodle and every PHP site must update today

What happened on October 21

The PHP security team published a security advisory together with four emergency releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All four fix two critical vulnerabilities, scored 9.2 on CVSS 4.0, that the security press groups under the name PHP2Shell:

• CVE-2026-109618: an out-of-memory condition interrupts PHP while request data is only partially initialized; the cleanup that follows treats that corrupted data as valid and opens the door to code execution.
• CVE-2026-109619: request-owned internal state survives after its memory is freed, and the next request handled by the same worker can use that stale state before it is reset.

The advisory itself is blunt: "there are no complete mitigations, updating is the only safe choice." Details leaked on October 20, one day before the coordinated release, and Amazon, watchTowr and Cloudflare already report exploitation attempts in the wild.

Who is affected by PHP2Shell?

Every server that serves web requests with PHP: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The most exposed setup is Apache with mod_php, where an unauthenticated request triggers the flaw before a single line of application code runs. Researchers confirmed unauthenticated remote code execution on WordPress, Drupal, Joomla and Magento installs; estimates collected by Tenable put more than 1.3 million internet-facing hosts at risk.

Moodle is not named in the advisories. That is no relief: Moodle is a PHP application and the vulnerability lives in the interpreter, not in the application. An internet-facing training platform on unpatched PHP is in the same position as an online store or a blog.

Why Moodle deserves priority

A corporate LMS holds more than it seems: names, emails and job titles of the whole workforce, grades, DC-3 certificates and the training evidence that Mexico's STPS or an ISO auditor may request. An attacker in control of the server can extract that data, alter records or use the server to pivot into other company systems. Many Moodle installs also run on shared hosting or on servers nobody has touched since go-live, exactly the profile that takes longest to get the patch.

Which PHP version does your Moodle need?

The good news: every supported Moodle branch has a patched PHP version inside its supported range. The table uses the official ranges from the Moodle documentation.

Two warnings that fall outside the table. First: PHP 8.1 and older no longer receive patches from the project; the security team published only "minimal source backports" for 7.4, 8.0 and 8.1 that each team would have to compile. If your Moodle is 4.1 or older, the PHP patch does not reach you: the way out is migrating Moodle. Second: PHP 8.2 reaches end of life on December 31, 2026; patching to 8.2.35 today solves the emergency, but plan the jump to 8.3 or 8.4 before year end.

What to do today? Six steps in order

1. Inventory. List every server running PHP, starting with the internet-facing ones: Moodle, the corporate site, intranets, APIs. In Moodle the PHP version shows under Site administration → Server → Environment.
2. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 according to your Moodle's range. Linux distributions received the patches in advance: check your vendor's package changelog. On shared hosting, ask in writing for the exact version installed.
3. Restart PHP-FPM, Apache or the relevant service. Until it restarts, the vulnerable process stays in memory even though the package is already updated.
4. If you cannot update within hours, apply the mitigations PHP published, knowing they are partial: memory_limit = -1 set with php_admin_value so the application cannot override it, post_max_size of 8 MB (32 MB if Moodle needs file uploads), session.upload_progress.enabled = 0 in php.ini or the FPM pool, and on PHP 8.5 fatal_error_backtraces = 0. Avoid RLIMIT_AS or RLIMIT_DATA limits: they cause the very allocation failure the attack exploits. A WAF or reverse proxy in front of PHP helps, but only covers traffic that goes through it.
5. Look for signs of compromise: unusualland therge form submissions, out-of-memory errors during request initialization in the PHP logs, and shell processes that should not exist on the server.
6. Check your plugins. If the patch forces you up a PHP branch (for example from 8.1 to 8.3), confirm first that your Moodle plugins have a compatible version; it is the most common reason an urgent update gets postponed. If whoever runs the platform needs more confidence with these tasks, the Moodle for administrators course covers environment, upgrades and backups.

What we are doing on the Moodle sites we manage

Since the early hours of October 22 we have been applying the PHP patch and restarting processes on the platforms under Geedle maintenance, with a prior backup and an environment check on each one. If you run your Moodle yourself and need a second pair of hands to do it without taking the platform down, or if your install is on a version that no longer supports a patched PHP, the services below are the path: a review today costs far less than an incident next week.

Transparency: Geedle sells LMS maintenance services. The facts in this item come from the linked sources, not from our offer; if you spot an error, write to [email protected] and we will correct it with a dated note.

Sources

• PHP Group: security advisory and releases 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (October 21, 2026)
• Tenable: php2shell frequently asked questions
• CERT-EU: advisory 2026-018
• MoodleDocs: PHP versions supported by each Moodle release and Moodle support calendar