Why Today's PHP Zero-Day Didn't Touch Our Platforms

Today, a huge share of the internet is patching PHP in an emergency. None of Abstract Technology's customers had to react. That is not luck - it is the result of a quick response and the strength and speed of our team. By the time most of Europe woke up this morning, every platform we operate was patched, verified, and online.

On the morning of 22 October 2026, administrators of a very large share of the internet began an emergency scramble. Both the US National Security Agency and Europe's cybersecurity agency urged companies to act immediately on two critical flaws in PHP - the programming language that runs roughly 70% of the world's websites, including WordPress, Drupal and Moodle - and some sites went briefly offline while teams patched (ABC7 News).

The NSA described the risk starkly: PHP2Shell could let attackers take control of affected web servers without prior access or authentication, and the agency judged the vulnerabilities serious enough to require immediate patching across US Government departments and agencies.

For our customers running Open edX® with Abstract Technology, nothing happened. No scramble, no advisory to forward, no downtime. That is not an accident, and it is worth taking a moment to explain why.

What happened: PHP2Shell

The two vulnerabilities, now known collectively as PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. They allow unauthenticated remote code execution on affected web servers (Help Net Security). They affect nearly every PHP version back to PHP 5.4, and every installation that serves web requests is at risk - from PHP-FPM and Apache mod_php to php-cgi, FrankenPHP and LiteSpeed (The Hacker News).

The severity sits at the top end of the scale. Both carry a CVSS v4.0 score of 9.2 from the PHP security team, with NVD scoring them 9.8 on CVSS v3.1 (Rescana). The underlying bugs are the kind that make security engineers lose sleep: CVE-2026-109618 is an out-of-memory corruption that can interrupt PHP while internal request data is only partially initialised, while CVE-2026-109619 lets request-owned internal state survive after its backing memory has been freed (Help Net Security).

The timing added pressure. The flaws were due for coordinated disclosure on 21 October at 2 pm GMT, but a Hacker News user leaked the CVE identifiers a day earlier (Infosecurity Magazine). The PHP team moved the release forward and shipped patches as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The discovery itself is a sign of where security is heading. The flaws were found and reported by researchers at Wiz, Calif and OpenAI (The Hacker News). Wiz described these findings as among the most severe ever seen in PHP, and perhaps in the history of software, noting that frontier AI models dramatically lowered the barrier to turning a longstanding flaw into a working exploit (Help Net Security). Put plainly: bugs that sat quietly in the codebase for over a decade are now within reach of AI-assisted analysis.

Why none of our customers had to react

Our core learning platform is Open edX, and Open edX is not written in PHP.

Almost all of the server-side code in the Open edX project is written in Python, with Django as the web application framework (Open edX Architecture). The modern Open edX stack uses Django on the backend and React on the frontend, split across multiple micro-frontend apps (MFEs) across the ecosystem (Open edX Platform Overview).

This is a design choice, not a quirk. Python and Django are the backbone of edx.org and of every Open edX instance Abstract Technology operates. Our 150+ delivered projects and more than one million learners sit on an architecture that was never in the blast radius of this week's PHP incident. No instance patched, no learner session interrupted, no partner call we had to make at midnight.

This was not luck. It was selection.

When a client asks us "which LMS should we build on?", they are asking something bigger than it looks. A learning platform is a ten-year decision. It carries student records, assessment data, certification history, integrations with HR and finance systems, and - increasingly - the AI tooling that will live on top of it. The stack beneath the platform is what your security posture looks like on days like today.

That is why we are deliberate about the four products we work with:

• Open edX - Python/Django, open source, maintained by a global community with an active security working group. The product we lead with for most of our customers.
• Canvas by Instructure - a mature, enterprise-grade LMS with its own hardened delivery pipeline.
• 360Learning - a managed collaborative-learning SaaS where patching and infrastructure sit with the vendor by design.
• Payload CMS - a modern TypeScript/Node.js headless CMS we implement for content-heavy learning sites.

On top of them we run in-house tooling - AI Studio for course authoring and our AI Administrative Assistant for repetitive instructor and admin work - built on modern Python and JavaScript foundations.

Every one of these choices is made with long-term maintainability, vendor responsiveness, and security posture in mind. That groundwork is what our customers feel on the quiet days as much as on the loud ones.

How we responded, overnight

Our customers' core learning platforms run on Open edX, which is written in Python and Django (Open edX Architecture), so the LMS core itself was never exposed to PHP2Shell. But a real production learning environment is more than its LMS - it includes supporting services, auxiliary tools, integrations, and infrastructure that evolve over the years and sometimes touch PHP in one component or another. That is what our team worked through the incident.

The sequence looked like this:

1. Within the hour of release. Our ops channel opened the incident, pulled the official PHP advisory, and started matching the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35) against every environment under our operation.
2. Full inventory. Every customer environment, every supporting service, every auxiliary tool was swept for any PHP footprint - directly installed, inside a container, or behind an integration.
3. Patch and restart. Where PHP touched the stack in any form, we applied the vendor fix, restarted workers, and re-ran health checks. Where mitigations were needed in the interim, we applied them in line with the PHP security team's guidance.
4. Verify and monitor. Every patched component was verified back to normal, with enhanced monitoring in place for the next 72 hours in line with the NSA's own recommendation.
5. Communicate. with the start of business this morning, every customer had a short, clear update on what we are doing and is already done on their behalf and what, if anything, they needed to do themselves.

In most cases, the answer to that last question was: nothing. The work was already done.

Why we could move this fast

The reason we could respond at this pace is not magic. It is the same reason our clients partner with us in the first place: we operate learning platforms as a full-time discipline, not as a side-task sitting next to other work.

Across 150+ delivered projects and more than one million learners, our team has built the muscle memory for exactly this scenario. An advisory lands, the clock starts, and the inventory, patch, verify, communicate cycle begins without hesitation. We know every component in every environment we operate, we know who to call, and the runbooks for a CVSS 9.8 landing at 2 pm GMT were ready long before yesterday.

The PHP security team deserves real credit here too - they shipped a textbook, fast, coordinated response, and millions of sites around the world will be safely patched because of it (Help Net Security). Our job was to carry that patch across the finish line for every customer we serve, as quickly as the moment demanded.

The quiet days are the point

The best outcome in security is boredom. No incident ticket, no late-night Slack thread, no "we need to patch now" email to a nervous head of IT. For our Open edX customers today was a boring day, and that is exactly what we signed up to deliver when they placed their trust in us.

We will keep making those choices on purpose. The next zero-day - in any ecosystem - will arrive without warning. The platforms we recommend, operate and extend are chosen with that reality in mind, and we are grateful to the clients who continue to trust us to make those calls on their behalf.

Sources

1. US National Security Agency, NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities, 21 October 2026.
2. ABC7 News, Some websites shut down globally as operators address PHP issue after AI finds critical flaw, 22 October 2026.
3. Infosecurity Magazine, Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch, 21 October 2026.
4. BleepingComputer, PHP warns admins of two critical flaws, emergency patches coming tomorrow, 20 October 2026.
5. The Hacker News, PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge, 21 October 2026.
6. Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched, update now!, 21 October 2026.
7. Rescana CVE Analysis Center, Two Critical PHP Vulnerabilities Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, 21 October 2026.
8. watchTowr Labs, PHP Remote Code Execution FAQ: CVE-2026-109618, 21 October 2026.
9. Open edX Documentation, Platform Overview.
10. Open edX Documentation, Open edX Platform Architecture.