PHP2Shell: How We Secured Our Clients’ Moodle Platforms in Less Than 24 Hours

Wednesday, October 21, 2026, will go down in cybersecurity history. Two critical vulnerabilities in PHP, collectively known as PHP2Shell, were disclosed along with their patches late this afternoon. Even before their official release, working prototypes were circulating on social media. Some government websites have been taken offline as a precaution. The media, too. ANSSI has issued an emergency alert. CISA, the NSA, and CERT-EU as well.

It wasn’t a routine alert.

We manage dozens of Moodle platforms and servers for our clients. Here’s what happened, what we did, and what this means for the future.

To understand why this vulnerability was so serious, it is important to understand a key distinction: Moodle is not a standalone application. It is a web application that runs on PHP, a programming language that serves as the server-side engine. PHP is used on approximately 70% of websites worldwide, which amounts to more than 600,000 servers in France, according to ANSSI.

Updating Moodle wasn’t enough. It was PHP itself—installed on the server running Moodle—that needed to be updated. A subtle difference that completely changes how we react.

PHP2Shell encompasses two distinct vulnerabilities (CVE-2026-109618 and CVE-2026-109619), both of which allow remote code execution on a server without any prior authentication. In practice: reading all data, accessing databases, retrieving API keys, and taking control of the machine. Moodle, WordPress, Drupal, Nextcloud, phpMyAdmin… any application running on PHP was affected.

The only real protection: update PHP on the server. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Any older server remained vulnerable, regardless of the quality of the application code running on it.

Moodle HQ explicitly stated in its official announcement to the entire global community: PHP2Shell is not a vulnerability in Moodle, but in PHP, on which it runs. No version of Moodle was immune. The decisive factor was not the version of Moodle that was installed. It was the responsiveness of the team that manages the server.

Moodle HQ updated its own infrastructure as soon as the patch was released. For everyone else, the responsibility fell to those who operate the servers: a specialized hosting provider, an in-house IT department, or an external service provider.

We have been following the case closely since Wednesday morning. The announcement of a release late in the afternoon, combined with the exploits that were circulating before the official release time, led us to switch to response mode as soon as the patches became available.

For platforms hosted directly by Pimenko, on our Scaleway infrastructure in France or elsewhere in Europe, we deployed the PHP updates across our entire infrastructure starting Wednesday evening. Our customers did not have to take any action. Some people had contacted us earlier that day to request that their websites be taken offline as a precaution: we did so immediately.

For platforms hosted by our clients, the work required more coordination. Each infrastructure has its own constraints: different OS versions, different distributions (Ubuntu, Debian, RedHat), and, depending on the environment, the procedures for applying the PHP patch vary. There’s no one-size-fits-all solution. We worked on a case-by-case basis, in direct collaboration with the technical teams at each organization.

All of our work was completed by Thursday. Less than 24 hours after the patches were released, our entire infrastructure was secured.

PHP2Shell was not discovered in the usual way. This is part of the Patch the Planet program, launched in June 2026, that Calif, a cybersecurity company partnering with the program, identified the first vulnerability. The researchers used GPT-5.6 Sol to audit the PHP source code. Separately, the team at Wiz (which was acquired by Google) reached the same conclusions with Gemini 4 Argon a few weeks later. Both teams reported their findings to the PHP team in August, allowing for two months of coordination prior to public disclosure with the PHP Foundation, Cloudflare, AWS, and several government agencies, including ANSSI, CISA, and the NSA.

Where opinions differ is on the exact role of AI. OpenAI and Wiz highlight the contribution of the models. But Calif, despite having made the discovery, qualifies this strongly: “No special tools or models that aren’t accessible to everyone were used during the initial discovery. I focused on something I had experience with; I was very familiar with the history of these vulnerabilities. Knowing your target remains as relevant as ever.”

The truth probably lies somewhere in between: AI has been a useful tool, available to everyone, but it was human expertise and a detailed understanding of the history of PHP vulnerabilities since 2004 that made the discovery possible.

What this story reveals more broadly, however, is clear. Heartbleed in 2014, Log4Shell in 2021, PHP2Shell in 2026: crises of this magnitude are recurring and accelerating. OpenAI puts it bluntly: “We expect a sharp increase in similar discoveries in the coming months.” The same tools that help identify vulnerabilities also make it possible to exploit them more quickly. The time between the discovery of a vulnerability and its active exploitation is shrinking.

It’s no coincidence that PHP2Shell wasn’t quickly absorbed. This is the result of a maintenance culture that was established well before the crises: regular update cycles for both the server and Moodle, established procedures, and access rights already in place. When a critical vulnerability is disclosed, we don’t start from scratch. The question isn’t “How do we do it?”, but “In what order?”. It is this culture of foresight and technical rigor that helped us earn the Newcomer of the Year award at the 2026 Moodle Partner Awards.

If this week has confirmed anything, it’s that maintaining a Moodle platform isn’t just about the Moodle code. It involves the entire infrastructure: OS, PHP, web server, and network configuration. Updating Moodle without updating the server leaves security vulnerabilities. And with forwards becoming increasingly skilled, responsiveness is becoming a decisive advantage.

We have already begun work to speed up these types of interventions even further, particularly by automating the deployment of urgent patches. PHP2Shell has confirmed that this is the right direction.

The vulnerability has been fixed, but servers that haven’t been updated remain vulnerable. The Moodle platforms used by training organizations, public institutions, and universities are not insignificant targets: they host learners’ personal data, training records, and, in some cases, sensitive information. Many of these organizations manage their Moodle without a dedicated technical staff. These are the ones who have the hardest time reacting quickly and who remain vulnerable the longest.

If you manage your platform on your own or with a hosting provider that hasn’t yet issued a statement about PHP2Shell, the first question to ask is simple: Which version of PHP is running on your server?

As a certified Moodle partner in France, we can audit your infrastructure and help you address any security concerns.