Am Mittwoch, den 21. Oktober 2026, hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen „PHP2Shell“ bekannt geworden sind. Wenige Minuten später hat unser Hosting-Partner Mittwald vorsorglich alle Systeme abgeschaltet. Für viele Website-Betreiber in Deutschland war das ein langer Abend mit offenen Fragen. Für unsere Kunden nicht: Sie wussten noch am selben Abend Bescheid, und auf unserem eigenen Server war die Lücke bis 4:10 Uhr morgens vollständig geschlossen.
In diesem Beitrag zeigen wir offen, was passiert ist, wie wir reagiert haben und was Sie daraus mitnehmen können.
Das Wichtigste in Kürze
- Die Lücke: CVE-2026-109618 und CVE-2026-109619, jeweils mit CVSS 9.2 als kritisch bewertet. Angreifer konnten ohne Login eigenen Code auf dem Server ausführen. Betroffen war praktisch jede Website, die mit PHP läuft, also auch jede WordPress-Seite.
- Mittwald: Abschaltung aller Systeme um 16:17 Uhr. Unsere Kundenwebsites dort waren von 16:27 Uhr bis 22:42 Uhr nicht erreichbar.
- Kundeninfo: Alle betroffenen Kunden haben wir per E-Mail und direkt in ihrem Projekt in unserem Projektmanagement informiert, mit persönlicher Erwähnung der Ansprechpartner.
- Unser eigener Server: Schutzmaßnahme ab 18:50 Uhr aktiv, alle 19 PHP-Dienste in der Nacht gepatcht und einzeln geprüft. Abgeschlossen um 4:10 Uhr.
- Premium-Kunden: Websites auf unserem dedizierten Hosting hatten keinen Ausfall.
- Transparenz: Den Zustand aller Hoster zeigen wir seit diesem Abend live auf unserer Seite Hoster-Status.
Der Hintergrund: Was ist PHP2Shell?
PHP ist die Programmiersprache, auf der ein Großteil des Webs läuft. Laut W3Techs nutzen rund 69 Prozent aller Websites mit bekannter Server-Technik PHP, darunter jede WordPress-Installation. Eine Lücke direkt in PHP ist deshalb kein Problem einzelner Plugins oder Themes, sondern betrifft die Grundlage, auf der die Website läuft.
Zwei Fehler in der Speicherverwaltung
Beide Lücken stecken in der Art, wie PHP bei Fehlern während einer Anfrage mit seinem Arbeitsspeicher umgeht:
- CVE-2026-109618 („RCE via OOM corruption“): Läuft PHP bei einer Anfrage der Speicher voll, bricht es die Verarbeitung ab, bevor interne Daten fertig angelegt sind. Beim anschließenden Aufräumen behandelt PHP diese halbfertigen Daten trotzdem als gültig. Auslösen lässt sich das über speziell gebaute Formular- und Upload-Anfragen.
- CVE-2026-109619 („RCE via stale global state“): Nach einem schweren Fehler bleiben Verweise auf Speicher zurück, der bereits freigegeben wurde. Eine spätere Anfrage im selben PHP-Prozess kann diesen ungültigen Speicher dann weiterverwenden.
Im schlimmsten Fall führt beides zu einer sogenannten Remote Code Execution: Ein Angreifer bringt den Server dazu, eigenen Programmcode auszuführen. Dafür braucht er weder ein Passwort noch ein Benutzerkonto. Das PHP-Team stuft das Risiko für Apache mit mod_php am höchsten ein, weil der Angriff dort greift, bevor überhaupt die eigentliche Anwendung startet. PHP-FPM, FrankenPHP, LiteSpeed und php-cgi sind ebenfalls betroffen. Der älteste betroffene Code stammt laut den Entdeckern aus PHP 5.4, also aus dem Jahr 2012.
Ein Leak zwang zur Eile
Gefunden haben die Lücken Sicherheitsforscher von Calif, Wiz, OpenAI und Quarkslab, teils mit Unterstützung von KI-Modellen. Geplant war eine geordnete Veröffentlichung am 22. Oktober. Doch schon am 20. Oktober kursierten die CVE-Nummern auf Hacker News und in einschlägigen Foren. Das PHP-Team zog die Updates daraufhin um einen Tag vor: Am 21. Oktober gegen 16 Uhr deutscher Zeit erschienen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Cloudflare hatte bereits in der Nacht zuvor, um 5:02 Uhr unserer Zeit, Schutzregeln in seiner Web Application Firewall freigeschaltet und kurz darauf erste Angriffsversuche beobachtet. Cloudflare selbst betont aber: Diese Regeln sind nur eine Übergangslösung. Schützen kann am Ende nur das Update von PHP selbst.
Besonders heikel: Für PHP 8.1 und ältere Versionen gibt es keine offiziellen Updates mehr. Wer solche Versionen noch betreibt, ist auf Rückportierungen durch Hoster oder Linux-Distributionen angewiesen.
Warum Mittwald alle Systeme abgeschaltet hat
Mittwald hatte schon um 14:16 Uhr angekündigt, um 16 Uhr Sicherheitsupdates einzuspielen und vorsorglich Datei-Uploads zu sperren. Um 16:17 Uhr folgte dann der deutlich härtere Schritt: Weil sich eine Kompromittierung nicht ausschließen ließ, hat Mittwald alle Systeme heruntergefahren und den eingehenden Verkehr zu allen gehosteten Websites gesperrt.
Das war ein harter Einschnitt, aber aus Sicherheitssicht nachvollziehbar. Eine Website, die nicht erreichbar ist, kann auch nicht angegriffen werden. Mittwald hat anschließend Version für Version gepatcht und im Laufe des Abends mehrfach auf seiner Statusseite informiert. Um 22:52 Uhr meldete Mittwald alle Kundeninstanzen wieder erreichbar, um 0:28 Uhr wurde der Vorfall geschlossen. Nach eigener Prüfung hat Mittwald keine Hinweise darauf gefunden, dass die Lücke auf seinen Systemen ausgenutzt wurde.
Unser Monitoring hat das ganz konkret erfasst: Von 16:27 Uhr an waren 30 Kundenwebsites bei Mittwald nicht erreichbar. Um 22:42 Uhr waren sie wieder online, die letzte um 22:46 Uhr.
Wie wir unsere Kunden informiert haben
Ein Ausfall ist ärgerlich. Ein Ausfall, von dem man nichts weiß, ist schlimmer. Deshalb hatte für uns an diesem Abend eines Vorrang: Jeder betroffene Kunde sollte von uns erfahren, was los ist, bevor er selbst suchen muss.
- Per E-Mail: Alle Ansprechpartner der betroffenen Websites haben eine kurze Nachricht von uns bekommen.
- Im Projektmanagement: Um 18:11 Uhr stand die Information in jedem betroffenen Kundenprojekt in unserem Projektmanagement. Die Ansprechpartner haben wir dort persönlich erwähnt, damit die Nachricht nicht im Projekt untergeht, sondern direkt bei ihnen ankommt.
Die Nachricht war bewusst kurz gehalten:
Eure Website ist im Moment ggf. nicht erreichbar. Grund ist eine Sicherheitslücke in PHP, wegen der unser Hosting-Anbieter Mittwald heute um 16:17 Uhr vorsorglich alle Systeme heruntergefahren und den Zugriff auf alle Websites gesperrt hat. […] Eure Daten sind sicher, die Abschaltung ist eine reine Schutzmaßnahme. […] Ihr müsst nichts tun.
Drei Dinge waren uns dabei wichtig: was passiert ist, ob Daten in Gefahr sind und ob der Kunde selbst etwas tun muss. Mehr braucht es in so einem Moment nicht.
Neu: alle Hoster auf einen Blick
Noch am selben Abend haben wir unsere Seite Hoster-Status online gestellt. Sie bündelt die offiziellen Meldungen von Mittwald, Hetzner, all-inkl und STRATO und ergänzt sie um unsere eigene Messung, die jede Minute läuft. Sie sehen dort auf einen Blick, ob ein Hoster gerade Störungen, Wartungen oder Ausfälle hat, inklusive Verlauf. Den Zustand unserer eigenen Server finden Sie wie gewohnt auf unserer Serverstatus-Seite.
Unsere Nacht: was wir auf unserem eigenen Server getan haben
Neben den Websites bei Mittwald betreiben wir einen eigenen, dedizierten Server in Deutschland. Dort laufen die Websites unserer Premium-Kunden und unsere internen Werkzeuge. Hier lag die Verantwortung komplett bei uns, und wir haben sie noch in derselben Nacht erledigt.
| Uhrzeit | Was wir getan haben |
|---|---|
| 21.10., 18:30 | Server-Verwaltung auf die gepatchte Version mit PHP 8.4.27 aktualisiert |
| 21.10., 18:32 | Ein Community-Forum, dessen PHP-Version keinen Fix mehr bekommt, auf ein neues, gepatchtes System umgezogen. Ausfall: rund 10 Sekunden |
| 21.10., 18:44 bis 18:50 | Sofortmaßnahme aus der offiziellen Empfehlung in 15 PHP-Diensten aktiviert, jeden Dienst einzeln getestet |
| 21.10., 19:15 | Spurensuche: Prüfsummen aller WordPress-Installationen, Plugins, bekannte Schadcode-Muster, laufende Prozesse und Verbindungen. Ergebnis: keine Hinweise auf einen Angriff |
| 21.10., 19:48 | Erstes internes Werkzeug auf gepatchtes PHP 8.3.36 umgestellt, Daten vorher und nachher verglichen |
| 22.10., 3:13 bis 4:08 | Alle WordPress-Websites und die übrigen Dienste auf gepatchte PHP-Versionen gebracht, jede Website nach dem Update einzeln geprüft |
| 22.10., 4:10 | Abschluss: 19 von 19 PHP-Diensten gepatcht, alle 25 Domains von außen erreichbar, keine Auffälligkeiten |
Die Reihenfolge war bewusst gewählt: Zuerst die Sofortmaßnahme, die Angriffe deutlich erschwert, dann die Spurensuche, dann die eigentlichen Updates. Die großen Updates haben wir in die Nacht gelegt, weil dann kaum jemand die Websites nutzt. Nach jedem einzelnen Schritt haben wir getestet, bevor der nächste kam.
Premium-Kunden: kein Ausfall
Die Websites unserer Premium-Kunden liegen nicht auf einer geteilten Hosting-Plattform, sondern auf unserem dedizierten Server. Deshalb waren sie von der Abschaltung bei Mittwald nicht betroffen und den ganzen Abend über erreichbar. Wann und wie wir PHP aktualisieren, entscheiden wir dort selbst, ohne auf einen Anbieter warten zu müssen. Zusätzlich filtert eine vorgeschaltete Firewall bekannte Angriffsmuster, bevor sie den Server erreichen. Die Updates selbst liefen nachts zwischen 3 und 4 Uhr, je Website mit einem Neustart von wenigen Sekunden.
Sie möchten Ihre Website ebenfalls auf unser dediziertes Hosting umziehen? Sprechen Sie uns gerne an.
Was Sie jetzt tun sollten
- Sie sind Kunde bei uns: Sie müssen nichts tun. Ihre Website läuft auf gepatchtem PHP, entweder durch Mittwald oder durch uns.
- Sie betreuen Ihre Website selbst: Prüfen Sie, welche PHP-Version läuft. Sicher sind PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 und neuer. Ein Plugin-Update reicht nicht, die Lücke steckt in PHP selbst.
- Sie nutzen PHP 8.1 oder älter: Fragen Sie Ihren Hoster, ob er die Lücke für Ihre Version geschlossen hat, und planen Sie den Umstieg auf eine aktuelle PHP-Version.
- Sie wollen wissen, wie es Ihrem Hoster geht: Unsere Seite Hoster-Status zeigt es live.
Was wir daraus mitnehmen
Sicherheitslücken lassen sich nicht verhindern. Was man in der Hand hat, ist die Reaktion darauf. An diesem Abend hat sich bewährt, was wir ohnehin so handhaben: Monitoring, das einen Ausfall sofort meldet. Ein fester Kanal zu jedem Kunden, über den eine Nachricht direkt ankommt. Und ein eigener Server, auf dem wir nicht warten müssen, bis jemand anderes handelt.
Die Seite Hoster-Status bleibt dauerhaft online. Beim nächsten Vorfall, egal bei welchem Hoster, sehen Sie damit sofort, was los ist, und hören wie gewohnt direkt von uns.
