Warum die PHP-Zero-Day-Lücke unsere Plattformen nicht getroffen hat

Heute patcht ein großer Teil des Internets PHP im Notfallmodus. Keine einzige Kundin und kein einziger Kunde von Abstract-Technology musste reagieren. Das ist kein Glück, sondern das Ergebnis schneller Reaktion und der Stärke und Geschwindigkeit unseres Teams. Als Europa heute Morgen aufwachte, war jede Plattform, die wir betreiben, bereits gepatcht, geprüft und online.

Am Morgen des 22. Oktober 2026 begannen Administrator:innen in einem sehr großen Teil des Internets einen Wettlauf gegen die Zeit. Sowohl die US National Security Agency als auch die europäische Cybersicherheitsagentur riefen Unternehmen dazu auf, sofort auf zwei kritische Lücken in PHP zu reagieren. PHP ist die Programmiersprache, auf der rund 70 % aller Websites weltweit laufen, darunter WordPress, Drupal und Moodle. Einige Websites gingen kurzzeitig offline, während die Teams die Patches einspielten (ABC7 News).

Die NSA beschrieb das Risiko unmissverständlich: Über PHP2Shell könnten Angreifer ohne vorherigen Zugang und ohne Authentifizierung die Kontrolle über betroffene Webserver übernehmen. Die Behörde stufte die Schwachstellen als so gravierend ein, dass alle Ministerien und Behörden der US-Regierung sie umgehend patchen mussten.

Für unsere Kund:innen, die Open edX® mit Abstract-Technology betreiben, ist nichts passiert. Keine Hektik, keine Sicherheitswarnung zum Weiterleiten, keine Ausfallzeit. Das ist kein Zufall, und es lohnt sich zu erklären, warum.

Was passiert ist: PHP2Shell

Die beiden Schwachstellen, inzwischen unter dem Namen PHP2Shell bekannt, werden als CVE-2026-109618 und CVE-2026-109619 geführt. Sie ermöglichen die Ausführung von Code aus der Ferne ohne Authentifizierung auf betroffenen Webservern (Help Net Security). Betroffen sind fast alle PHP-Versionen bis zurück zu PHP 5.4, und jede Installation, die Webanfragen verarbeitet, ist gefährdet: von PHP-FPM und Apache mod_php bis zu php-cgi, FrankenPHP und LiteSpeed (The Hacker News).

Der Schweregrad liegt ganz oben auf der Skala. Das PHP-Sicherheitsteam bewertet beide Lücken mit einem CVSS-v4.0-Score von 9,2, die NVD mit 9,8 nach CVSS v3.1 (Rescana). Die zugrunde liegenden Fehler gehören zu der Sorte, die Sicherheitsexpert:innen den Schlaf rauben: CVE-2026-109618 ist eine Speicherbeschädigung durch Out-of-Memory, die PHP unterbrechen kann, während interne Anfragedaten nur teilweise initialisiert sind. CVE-2026-109619 sorgt dafür, dass anfragebezogene interne Zustände weiterbestehen, obwohl der zugehörige Speicher bereits freigegeben wurde (Help Net Security).

Der Zeitpunkt erhöhte den Druck zusätzlich. Die koordinierte Veröffentlichung war für den 21. Oktober um 14 Uhr GMT geplant, doch ein Nutzer auf Hacker News machte die CVE-Kennungen bereits einen Tag vorher publik (Infosecurity Magazine). Das PHP-Team zog die Veröffentlichung vor und lieferte die Patches als PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 aus.

Schon die Entdeckung zeigt, wohin sich die IT-Sicherheit entwickelt. Gefunden und gemeldet wurden die Lücken von Forschenden bei Wiz, Calif und OpenAI (The Hacker News). Wiz bezeichnete die Funde als einige der schwerwiegendsten, die es je in PHP gab, vielleicht sogar in der Geschichte der Software. Dabei betonte Wiz, dass moderne KI-Modelle die Hürde drastisch gesenkt haben, aus einer seit Langem bestehenden Lücke einen funktionierenden Exploit zu machen (Help Net Security). Einfach gesagt: Fehler, die über ein Jahrzehnt unbemerkt im Code lagen, sind mit KI-gestützter Analyse jetzt in Reichweite.

Warum keine unserer Kund:innen reagieren musste

Unsere zentrale Lernplattform ist Open edX®, und Open edX® ist nicht in PHP geschrieben.

Nahezu der gesamte serverseitige Code des Open-edX®-Projekts ist in Python geschrieben, mit Django als Web-Framework (Open edX Architecture). Der moderne Open-edX®-Stack nutzt Django im Backend und React im Frontend, aufgeteilt auf mehrere Micro-Frontend-Apps (MFEs) im gesamten Ökosystem (Open edX Platform Overview).

Das ist eine bewusste Architekturentscheidung, keine Eigenheit. Python und Django sind das Rückgrat von edx.org und jeder Open-edX®-Instanz, die Abstract-Technology betreibt. Unsere über 150 umgesetzten Projekte mit mehr als einer Million Lernenden laufen auf einer Architektur, die nie im Wirkungsbereich des PHP-Vorfalls dieser Woche lag. Keine Instanz musste gepatcht werden, keine Lernsitzung wurde unterbrochen, kein Partner musste um Mitternacht angerufen werden.

Das war kein Glück, sondern eine bewusste Auswahl

Wenn Kund:innen uns fragen: „Auf welchem LMS sollen wir aufbauen?“, steckt mehr hinter der Frage, als es scheint. Eine Lernplattform ist eine Entscheidung für zehn Jahre. Sie enthält Daten von Studierenden, Prüfungsergebnisse, Zertifikatshistorien, Integrationen mit HR- und Finanzsystemen und zunehmend auch die KI-Tools, die darauf aufsetzen. Wie sicher Sie an Tagen wie heute aufgestellt sind, entscheidet sich am Stack unter der Plattform.

Deshalb wählen wir die vier Produkte, mit denen wir arbeiten, ganz bewusst aus:

• Open edX®: Python/Django, Open Source, gepflegt von einer weltweiten Community mit einer aktiven Security-Arbeitsgruppe. Das Produkt, das wir den meisten unserer Kund:innen in erster Linie empfehlen.
• Canvas by Instructure: ein ausgereiftes LMS auf Enterprise-Niveau mit eigener, gehärteter Auslieferungspipeline.
• 360Learning: eine Managed-SaaS-Lösung für kollaboratives Lernen, bei der Patching und Infrastruktur von vornherein beim Anbieter liegen.
• Payload CMS: ein modernes Headless CMS auf Basis von TypeScript/Node.js, das wir für inhaltsstarke Lernwebsites einsetzen.

Darauf setzen unsere eigenen Tools auf: AI Studio für die Kurserstellung und unser AI Administrative Assistant für wiederkehrende Aufgaben von Lehrenden und Administration, beide auf Basis moderner Python- und JavaScript-Technologien.

Jede dieser Entscheidungen treffen wir mit Blick auf langfristige Wartbarkeit, die Reaktionsfähigkeit der Anbieter und die Sicherheit. Diese Grundlagen spüren unsere Kund:innen an ruhigen Tagen genauso wie an turbulenten.

So haben wir über Nacht reagiert

Die zentralen Lernplattformen unserer Kund:innen laufen auf Open edX®, das in Python und Django geschrieben ist (Open edX Architecture). Der LMS-Kern selbst war PHP2Shell also nie ausgesetzt. Eine echte produktive Lernumgebung besteht aber aus mehr als dem LMS. Sie umfasst unterstützende Dienste, Zusatztools, Integrationen und Infrastruktur, die über die Jahre wachsen und in der einen oder anderen Komponente auch PHP nutzen können. Genau darum hat sich unser Team während des Vorfalls gekümmert.

So sind wir vorgegangen:

• Innerhalb der ersten Stunde nach Veröffentlichung. In unserem Ops-Channel wurde der Vorfall eröffnet, die offizielle PHP-Sicherheitswarnung abgerufen und begonnen, die korrigierten Versionen (8.5.12, 8.4.27, 8.3.36, 8.2.35) mit jeder von uns betriebenen Umgebung abzugleichen.
• Vollständige Bestandsaufnahme. Jede Kundenumgebung, jeder unterstützende Dienst und jedes Zusatztool wurde auf PHP-Spuren geprüft: direkt installiert, in einem Container oder hinter einer Integration.
• Patchen und neu starten. Wo PHP in irgendeiner Form im Stack vorkam, haben wir den Patch des Herstellers eingespielt, die Worker neu gestartet und die Health Checks erneut ausgeführt. Wo zwischenzeitlich Schutzmaßnahmen nötig waren, haben wir sie gemäß den Empfehlungen des PHP-Sicherheitsteams umgesetzt.
• Prüfen und überwachen. Jede gepatchte Komponente wurde auf ihren Normalbetrieb geprüft. Für die folgenden 72 Stunden haben wir das Monitoring verstärkt, wie es auch die NSA empfiehlt.
• Kommunizieren. Zu Geschäftsbeginn heute Morgen hatten alle Kund:innen ein kurzes, klares Update: was wir in ihrem Auftrag tun und bereits erledigt haben und was sie gegebenenfalls selbst tun müssen.

In den meisten Fällen lautete die Antwort auf die letzte Frage: nichts. Die Arbeit war bereits erledigt.

Warum wir so schnell handeln konnten

Dass wir so schnell reagieren konnten, hat nichts mit Magie zu tun. Es ist derselbe Grund, aus dem sich Kund:innen überhaupt für uns entscheiden: Wir betreiben Lernplattformen als Kerngeschäft, nicht als Nebenaufgabe.

In über 150 umgesetzten Projekten mit mehr als einer Million Lernenden hat unser Team genau für dieses Szenario die nötige Routine entwickelt. Eine Sicherheitswarnung kommt herein, die Uhr läuft, und der Zyklus aus Bestandsaufnahme, Patchen, Prüfen und Kommunizieren beginnt ohne Zögern. Wir kennen jede Komponente in jeder Umgebung, die wir betreiben, wir wissen, wen wir anrufen müssen, und die Runbooks für eine CVSS-9,8-Lücke, die um 14 Uhr GMT veröffentlicht wird, lagen lange vor gestern bereit.

Auch das PHP-Sicherheitsteam verdient große Anerkennung. Es hat eine schnelle, koordinierte Reaktion wie aus dem Lehrbuch geliefert, und dank ihr werden Millionen Websites weltweit sicher gepatcht (Help Net Security). Unsere Aufgabe war es, diesen Patch für alle unsere Kund:innen so schnell ins Ziel zu bringen, wie es die Situation erforderte.

Auf die ruhigen Tage kommt es an

Das beste Ergebnis in der IT-Sicherheit ist Langeweile. Kein Incident-Ticket, kein nächtlicher Slack-Thread, keine „Wir müssen sofort patchen“-Mail an eine nervöse IT-Leitung. Für unsere Open-edX®-Kund:innen war heute ein langweiliger Tag, und genau das haben wir versprochen, als sie uns ihr Vertrauen geschenkt haben.

Wir werden diese Entscheidungen auch weiterhin bewusst treffen. Die nächste Zero-Day-Lücke, in welchem Ökosystem auch immer, kommt ohne Vorwarnung. Die Plattformen, die wir empfehlen, betreiben und erweitern, wählen wir mit Blick auf genau diese Realität aus. Und wir danken allen Kund:innen, die uns weiterhin vertrauen, diese Entscheidungen für sie zu treffen.

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.