Zwei Lücken mit 9,2 von 10. Eine Laufzeitumgebung. Fast das ganze Web.
Wenn Sie aratech-Kunde sind oder Ihre Website bei uns gehostet wird, schreiben Sie sofort an [email protected]. Wir bestätigen Ihnen Ihre PHP-Version, den Patch-Status und was wir dagegen unternehmen. Warten Sie nicht auf einen Newsletter, der Ihnen das erklärt.
Das ist kein Plugin-Problem. Kein Theme-Problem. Kein WordPress-Bug, kein Magento-Bug, kein Laravel-Bug.
Das ist PHP selbst.
Zwei kritische Schwachstellen im PHP-Kern, geführt als CVE-2026-109618 und CVE-2026-109619, erlauben einem nicht authentifizierten Angreifer, beliebigen Code auf einem Webserver auszuführen. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 nach CVSS v4.0. Die Notfall-Patches wurden heute, am 21. Oktober 2026, um 14:00 UTC (18:00 Uhr Dubai) veröffentlicht. Die korrigierten Zweige sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Der Punkt, bei dem Sie aufhorchen sollten: Diese Lücken sind am 20. Oktober öffentlich durchgesickert, rund einen Tag vor der koordinierten Offenlegung. Das Leck enthielt die CVE-Nummern, eine Schweregradbewertung und ein Datum, und dazu kursierte ein Screenshot eines Exploit-Tools namens PHP2Shell, das Calif.IO zugeschrieben wird, mit einem Banner, das behauptet, es funktioniere gegen jede PHP-Version ab 5.4.0. Die technischen Details blieben bis 14:00 UTC heute unter Embargo. Das heißt: Das gesamte Internet bekommt den Patch und das Material zum Nachbauen im selben Moment.
Was die beiden Schwachstellen wirklich sind
Beide sind Speichersicherheitsfehler im Lebenszyklus einer Anfrage. Keine erfordert ein Login, ein Plugin oder eine schlecht programmierte Seite.
CVE-2026-109618, Codeausführung über OOM-Korruption. Wenn PHP an eine Speichergrenze stößt, kann der Prozess unterbrochen werden, während interne Anfragedaten erst teilweise initialisiert sind. Die anschließende Bereinigung behandelt diese ungültigen Daten als gültig, und wer den Speicherfehler auslösen kann, bestimmt, was danach passiert.
CVE-2026-109619, Codeausführung über veralteten globalen Zustand. Interner Zustand, der zu einer Anfrage gehört, kann überleben, nachdem der zugrunde liegende Speicher freigegeben wurde. Eine spätere Anfrage, die derselbe Worker verarbeitet, kann diesen veralteten Zustand nutzen, bevor die normale Initialisierung ihn zurücksetzt. Die Wiederverwendung von Workern wird hier zur Angriffsfläche.
Das Advisory des PHP-Projekts sagt, das Risiko sei bei mod_php am höchsten, wo ein nachgewiesener Exploit eine nicht authentifizierte Anfrage erlaubt, den Angriff auszulösen, bevor überhaupt Anwendungscode läuft. Das ist der wichtigste Satz in diesem Artikel: Ihr Framework, Ihre Firewall-Regeln und Ihre Anwendungslogik liegen nicht auf dem Angriffspfad.
Wer betroffen ist
Jeder, der PHP über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed ausliefert, ist im Scope. Mit anderen Worten: die Standardkonfiguration eines sehr großen Teils des Internets.
PHP läuft auf rund sieben von zehn Websites, die eine bekannte serverseitige Sprache verwenden. WordPress, Drupal, Joomla, Magento, Laravel, Symfony, individuelle Anwendungen und ein langer Schwanz von Geräten und Tools, die PHP still mitbringen. Berichte deuten darauf hin, dass der betroffene Bereich bis in die PHP-5-Ära von 2004 zurückreicht. Der genaue Umfang pro Version wird sich klären, sobald die Anbieter ihre eigenen Advisories veröffentlichen. Mallory zählte am 20. Oktober rund 884.000 internetseitig erreichbare Hosts, die gegenüber Shodan noch PHP 8.1 oder älter meldeten: 59 % aller Hosts, die überhaupt eine Version meldeten.
Und hier der Teil, den die meisten überlesen: PHP 8.1 und älter erhalten keine Updates mehr vom PHP-Projekt. Das Team hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht, aber wenn Sie auf einem End-of-Life-Zweig sind und Ihren Build nicht selbst kontrollieren, sind Sie nicht gepatcht. Sie warten auf den Zeitplan von jemand anderem.
Warum die nächsten 48 Stunden wichtiger sind als die Lücke
Eine bekannte, aber nicht öffentliche Schwachstelle ist ein Rennen zwischen Forschern und Verteidigern. Eine Schwachstelle mit öffentlichem Patch ist ein Rennen zwischen Angreifern und allen anderen.
Sobald die korrigierten Versionen herunterladbar sind, kann jeder sie mit dem verwundbaren Code vergleichen und den Auslöser zurückentwickeln. Das ist keine theoretische Sorge, sondern das übliche Drehbuch, und es dauert Stunden, nicht Wochen. Sansec erwartet massenhafte Angriffe etwa fünfzehn Minuten nach der Veröffentlichung. Patchstack meldet bereits aktive Ausnutzung bei Hosting-Partnern, und Cloudflare hat frühe Angriffsversuche verzeichnet. Dieser Vorsprung wird schon genutzt.
Auch die Reaktion der Institutionen ist ein Signal. Niederländische Dienste wie DigiD, MijnOverheid, die Website des Repräsentantenhauses und Tweakers gingen vorsorglich offline. Mehrere große japanische Plattformen wechselten in den Notfallwartungsmodus. The SEO Framework hat seine Server abgeschaltet. CERT-EU hat das Advisory 2026-018 veröffentlicht, und das britische NCSC rät, sofort zu patchen oder Systeme abzuschalten, wo eine Behebung nicht möglich ist.
Wenn Regierungen Ausfallzeiten der Exposition vorziehen, ist das die ehrliche Schweregradbewertung.
Tun Sie das jetzt, in dieser Reihenfolge
- Inventarisieren, bevor Sie patchen. Jede PHP-Installation, die Sie betreiben: Produktion, Staging, Container, reine Cron-Hosts sowie Geräte oder Tools von Drittanbietern mit eingebettetem PHP. Sie können nicht patchen, was Sie vergessen haben.
- Aktualisieren Sie auf eine korrigierte Version. 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Bei Managed Hosting: Fordern Sie das genaue Wartungsfenster schriftlich an und lassen Sie die tatsächliche Version danach bestätigen. Eine Wartungsankündigung heißt nicht, dass Ihre Websites erledigt sind.
- Bei PHP 8.1 oder älter: entscheiden Sie heute. Entweder bauen Sie mit den Backports des PHP-Sicherheitsteams, oder Sie steigen auf einen unterstützten Zweig um. Es gibt keine dritte Option, die "sicher" heißt.
- Starten Sie jeden Worker neu. PHP-FPM, Apache, LiteSpeed, FrankenPHP und alle langlebigen CLI-Worker. Ein installierter, aber nicht neu geladener Patch läuft nicht.
- Setzen Sie die vorläufige Härtung auch nach dem Patch. Sie kostet in
php.inioder der Pool-Konfiguration fast nichts und schadet nicht:session.upload_progress.enabled = 0, auf Pool- oder Server-Ebene, niemals perini_set()oder.user.inimemory_limit = -1, dort erzwungen, wo Anwendungen es nicht überschreiben könnenpost_max_size = 8Mohne Uploads,32Mmit Uploads,upload_max_filesizedarunter- bei PHP 8.5:
fatal_error_backtraces = 0
- Suchen Sie, statt nur zu patchen. Wenn Ihre Website erreichbar und ungepatcht war, prüfen Sie auf unerwartete Dateien, verändertes PHP in Upload-Verzeichnissen, neue Admin-Benutzer, ausgehende Verbindungen, die Sie nicht eingerichtet haben, und Cron-Einträge, die Sie nicht angelegt haben. Ein Patch schließt die Tür, er entfernt keinen Gast, der schon drinnen ist.
- Ignorieren Sie die Wunder-Plugins. Kopierte Codeschnipsel und unbestätigte "PHP2Shell-Fix"-Plugins kursieren. Sie sind nicht verifiziert, sie funktionieren nicht, und manche sind der Angriff selbst.
Die unbequeme Lektion
Alle paar Jahre erinnert uns das Web daran, dass die Laufzeitumgebung unter allem eine Software mit eigenen Fehlern ist. Die Rechnung ist meist teuer.
Das Muster, das wir bei aratech immer wieder sehen: Die Anwendung wurde aktualisiert, die Frameworks blieben aktuell, und die PHP-Version darunter blieb jahrelang unangetastet, weil sie funktionierte. PHP 7.4 ist seit November 2022 End-of-Life. Das sind fast vier Jahre ohne offizielle Sicherheitsupdates, auf einem Zweig, der jetzt Anbieter-Backports braucht, um eine Lücke wie diese zu überleben.
End-of-Life ist keine Wartungsvorliebe. Es ist ein ungesteuertes Risiko mit Datum, und heute ist das Datum fällig geworden.
Wenn Sie auf einem alten Zweig laufen, planen Sie das Upgrade als echtes Projekt: ein sauberer Server, aktuelle PHP- und Framework-Version, vollständige Tests, dann Umschaltung mit der alten Umgebung als Fallback. Das sind ein paar Tage unbequeme Arbeit, alle paar Jahre wiederholt, gegen die Alternative, zu hoffen, dass die nächste 9,2 Sie nicht findet.
Wenn Sie unsicher sind, fragen Sie uns heute
Wenn Sie aratech-Kunde sind oder Ihre Website bei uns gehostet wird, schreiben Sie sofort an [email protected]. Wir sagen Ihnen genau, wo Sie stehen: Ihre PHP-Version, ob sie gepatcht ist, ob wir Auffälligkeiten in Ihrer Infrastruktur gesehen haben und was als Nächstes passieren muss.
Wenn Sie kein Kunde sind und nicht wissen, welche PHP-Version Ihre Website ausführt, ist das Ihre Antwort. Schreiben Sie uns trotzdem. Diese Woche ist die richtige, um es herauszufinden.