Understanding PHP2Shell: How Open LMS Responded and Protected Client Data

When two critical flaws in PHP, the programming language that Moodle™ and a large share of the web run on, were leaked before a fix existed, Open LMS proactively took every client site offline. In this article, Craig Utley, Senior Director of Cloud Services, explains why we made that call and what it means for your data.

On Wednesday, October 21, 2026, Open LMS made one of the hardest calls a hosting provider can make: we took every client site offline at once. Two critical security flaws in PHP had been made public before a fix was available. Shutting down sites was the only way to ensure the safety of our clients’ data. Our post-event analysis found no sign of suspicious activity on any client site.

Here’s what happened, why we made that decision, and what it means for your institution or organization going forward.

What Happened: PHP2Shell Explained

Earlier this year, a security research project found two serious vulnerabilities in PHP, now tracked as CVE-2026-109618 and CVE-2026-109619 and widely known as "PHP2Shell." As is standard practice, the researchers reported the flaws privately to PHP's developers so that fixes could be prepared before anyone else learned about them.

Before those fixes were released, details of the vulnerabilities leaked publicly. Thousands of websites around the world, including Moodle™'s own public sites, went offline while they waited for patches.

Here’s a comparison: Imagine that the gasoline in every gas-powered car in the world was suddenly found to be contaminated. Electric and diesel cars are fine, but every gas car has to sit still until a treatment arrives. PHP is the fuel that runs Moodle™, WordPress, and countless other platforms. Overnight, that fuel became unsafe, and nothing could run safely on it until it was fixed.

Why the PHP Threat Was So Serious

Both flaws were remote code execution vulnerabilities, generally the most dangerous kind. They allowed anyone, with no username or password, to send commands to an affected site and have them run. An attacker could have installed ransomware or other malware, deleted a site entirely, or copied its data.

On a learning platform, that data can include personally identifiable information, financial details, assessment records and, for some public-sector clients, government identification numbers. The consequences could have ranged from a student quietly changing a grade to an attack that took an institution offline for weeks.

READ MORE | ‘How Open LMS’s Rigorous Approach to LMS Plugins Provides Security, Compliance, and Partnership’

Shutting Down and Keeping Clients Informed

Taking more than 2,000 client sites offline is not a decision we make lightly. After all, for some of these customers, this is their entire business. As my colleague Sean Tierney, Vice President of Customer Success at Open LMS observed, if we’re taking people down with little to no notice, we have to balance the notification and the shutdown time against the vulnerability.

Our leadership team weighed those factors quickly. With a public vulnerability and no patch available, the risk to client data was too high to keep sites running. We built in a short window to warn site administrators through an in-app notification, which reached them up to 30 minutes before the shutdown.

While our technical team worked on installing patches as PHP made them available, our support team focused on clear, regular communication with our clients.

We set a steady pace for updates and shared them through three channels:

• Community support portal banner: updates posted where clients already go for help.
• Status page: real-time service updates for anyone who subscribed.
• Unified problem ticket: one ticket linked to every related support ticket, so clients with open tickets received the same updates at the same time.

Clients turned to these channels in large numbers. Our status page started the day with fewer than 100 subscribers and ended it with nearly 9,000.

During the peak of the incident, we relied on these shared updates rather than individual messages so our teams could stay focused on the fix. Once service was restored, we followed up individually with every client who still had an open issue.

Getting Clients Back Online

The official PHP patches arrived within hours. As soon as they did, our team began deploying them across every client site. Approximately 50% of our clients were back online within six hours. A small number of sites needed one final patch, and we restored each of them as soon as it was available.

After restoration, we reviewed activity across our systems. That analysis showed no sign of suspicious activity on any client site, which confirms that shutting down early kept our clients and their data safe.

When things like this happen, we know it's a stressor for customers, and we’re very grateful for how our clients responded.

What This Means Going Forward

Unfortunately, security threats aren’t slowing down. AI tools are making it faster and easier for anyone, including people with no technical training, to find and exploit software vulnerabilities. That makes continuous monitoring and fast patching more important than ever.

The Open LMS security team monitors vulnerability disclosures continuously and applies patches as soon as they are available. When there is no known exploit in circulation, we patch on a normal, planned schedule. When the risk to client data is immediate, as it was on October 21, we act immediately. We thankfully don’t have to exercise our protocols for this type of situation very often, but they allow us to protect everybody’s data during unprecedented events.

RELATED READING | ‘How Open LMS Ensured Data Security for Its Clients During a Global Cyberattack’

Our Commitment to Your Security

We hope we never have to take our platform offline again. But if the safety of your data ever requires it, we will make the same decision. The best way to get real-time updates about the Open LMS platform is to subscribe to our status page.