PHP2Shell erklärt: Was es mit der PHP-Sicherheitslücke auf sich hatte
Am Mittwoch, dem 21. Oktober 2026, erschien ein dringendes Sicherheitsupdate für PHP. Es schloss zwei schwere Sicherheitslücken, die schnell den Namen PHP2Shell erhielten. Niederländische Behördenwebsites wie DigiD (das staatliche Login-System der Niederlande) und Overheid.nl sowie mehrere Hosting-Unternehmen gingen an diesem Tag vorsorglich offline. In diesem Artikel erklären wir, was los war, auch wenn Sie mit Technik wenig am Hut haben. Und wir sagen Ihnen offen, was wir getan haben.
Haben Sie eine Website bei Theory7? Dann müssen Sie selbst nichts tun. Wir haben die Updates auf allen unseren Webhosting-Servern installiert und jeden Server einzeln überprüft. Dafür mussten wir keine einzige Website vorsorglich offline nehmen. Wenn Sie es selbst prüfen möchten, lesen Sie in diesem Artikel (auf Niederländisch), wie das geht.
PHP2Shell in Kürze
- Was: zwei schwere Sicherheitslücken in PHP, CVE-2026-109618 und CVE-2026-109619, zusammen PHP2Shell genannt.
- Schweregrad: 9,2 auf einer Skala von 10. Ein Angreifer konnte ohne Passwort einen Webserver übernehmen.
- Wer: nahezu jede Website, die mit PHP läuft. Das sind etwa 70 Prozent des Webs.
- Lösung: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12, veröffentlicht am 21. Oktober 2026.
- Bei Theory7: bekannter Angriffsweg am Mittwochmorgen geschlossen, alle Server in der Nacht vom 21. auf den 22. Oktober aktualisiert.
Was ist PHP eigentlich?
Eine Website hat zwei Seiten. Die Vorderseite sehen Sie in Ihrem Browser: Texte, Fotos, Schaltflächen. Die Rückseite läuft auf einem Server und sorgt dafür, dass auf der Vorderseite im richtigen Moment das Richtige steht. Wenn Sie ein Kontaktformular ausfüllen, sich in einem Onlineshop anmelden oder etwas in den Warenkorb legen, erledigt das die Rückseite.
Vergleichen Sie es mit einem Restaurant. Der Gastraum ist das, was der Gast sieht. In der Küche passiert die eigentliche Arbeit. PHP ist die Sprache, in der diese Küche bei sehr vielen Websites eingerichtet ist.
Und das ist nicht übertrieben. Laut dem Analyseunternehmen W3Techs laufen rund 70 Prozent aller Websites, deren Technik bekannt ist, mit PHP. WordPress ist in PHP geschrieben, ebenso WooCommerce, Joomla, Drupal und Magento, dazu unzählige Onlineshops, Buchungssysteme und Kundenportale. Ein Fehler in PHP selbst ist also kein Fehler in einer einzelnen Website. Es ist ein Fehler im Fundament unter einem großen Teil des Internets.
Was genau ist PHP2Shell?
Forscher fanden zwei Fehler in der Art, wie PHP mit dem Arbeitsspeicher eines Servers umgeht. Ein Server merkt sich während seiner Arbeit alles Mögliche in diesem Speicher. Geht bei einer Anfrage etwas schief, soll PHP alles ordentlich aufräumen. In bestimmten Situationen passierte das nicht richtig.
Man kann es mit einem Hotel vergleichen, das ein Zimmer neu vermietet, während der vorherige Gast noch eine funktionierende Schlüsselkarte hat. Wer weiß, wie man diese Karte benutzt, gelangt an einen Ort, an dem er nichts zu suchen hat. Bei PHP2Shell konnte ein Angreifer den Server auf diese Weise seine eigenen Befehle ausführen lassen.
Drei Dinge machten PHP2Shell so gefährlich:
- Es war kein Passwort nötig. Ein Angreifer konnte es von außen versuchen, mit einer ganz normalen Anfrage an eine Website.
- Der Angreifer bekam die Kontrolle. Fachleute nennen das Remote Code Execution: Der Server tut, was der Angreifer sagt.
- Der Fehler steckte in PHP selbst. Nicht in einem Plug-in oder Theme, sondern in der Basis. Nahezu alle PHP-Versionen seit 2012 waren verwundbar.
Beide Lücken erhielten einen Schweregrad von 9,2 auf einer Skala von 10. Die offiziellen Beschreibungen finden Sie in den Sicherheitshinweisen von PHP zu CVE-2026-109618 und CVE-2026-109619.
Wie konnte das passieren?
PHP gibt es seit 1995, und es wird von einer großen Gruppe aus Freiwilligen und Unternehmen gepflegt. In so viel Code stecken immer Fehler, das gilt für jede Software. Diese beiden lagen in einer Ecke, auf die man selten stößt: dem Moment, in dem einem Server mitten in einer Anfrage der Speicher ausgeht. Solche Ausnahmefälle sind schwer zu testen, und deshalb blieben die Fehler jahrelang unentdeckt.
Normalerweise wird eine solche Lücke im Stillen geschlossen. Forscher melden sie den Entwicklern, diese bauen eine Lösung, und an einem vereinbarten Tag erscheinen Update und Erklärung gleichzeitig. So haben Administratoren einen Vorsprung vor Angreifern. Die Forscher fanden diese Lücken im August und meldeten sie an PHP. Das Update war für Donnerstag, den 22. Oktober, geplant.
Es kam anders. Am Dienstag, dem 20. Oktober, gelangten die ersten Details ins Internet. PHP zog das Update deshalb um einen Tag vor, auf Mittwochnachmittag. Laut dem Sicherheitsunternehmen Sansec sah Cloudflare bereits am Mittwochmorgen die ersten Angriffsversuche, noch bevor das Update verfügbar war. Amazon meldet sogar einen Versuch vom 17. Oktober, vier Tage vor der Bekanntgabe.
Das sorgte in den Niederlanden für einen besonderen Mittwoch. DigiD, MijnOverheid und Overheid.nl, zentrale Online-Dienste der niederländischen Behörden, gingen vorsorglich vorübergehend vom Netz. Auch mehrere Hosting-Unternehmen nahmen die Websites ihrer Kunden offline, bis das Update da war.
Was hat KI mit PHP2Shell zu tun?
KI spielte in dieser Geschichte auf zwei Seiten eine Rolle.
Beim Finden. Die Forscher, die PHP2Shell entdeckten, arbeiteten unter anderem mit KI-Modellen von OpenAI und Google. Google schreibt, dass sein Modell Gemini einen großen Beitrag geleistet hat, vom Finden der Lücke bis zur Prüfung der Lösung. KI kann in kurzer Zeit riesige Mengen Code durchlesen und Muster erkennen, die Menschen übersehen. Das ist eine gute Nachricht: Alte, versteckte Fehler kommen schneller ans Licht.
Auf der anderen Seite. Dieselbe Technologie steht auch Menschen mit schlechten Absichten zur Verfügung. Aus der Beschreibung einer Lücke einen funktionierenden Angriff zu bauen, kostete früher Tage oder Wochen Recherche. Mit KI geht das viel schneller. Die Zeit zwischen „eine Lücke ist bekannt“ und „die ersten Angriffe“ wird dadurch immer kürzer. Bei PHP2Shell war es weniger als ein Tag.
Für ein Hosting-Unternehmen bedeutet das: Ein Update „irgendwann diese Woche“ zu installieren, reicht nicht mehr. Man muss vorher genau wissen, was auf welchem Server läuft, und sofort handeln können, sobald das Update da ist. Wir setzen dafür selbst auch Automatisierung und KI ein, zum Beispiel um alle unsere Server gleichzeitig zu überprüfen, damit nirgendwo eine vergessene PHP-Version zurückbleibt. Jeder Eingriff auf einem Server erfolgte erst nach Freigabe durch einen unserer Administratoren.
Was haben wir gegen PHP2Shell unternommen?
Bei uns wählen Sie selbst, welche PHP-Version Ihre Website nutzt, von älteren Versionen bis zur neuesten. Das bedeutet, dass auf unseren Servern viele verschiedene PHP-Versionen nebeneinander laufen, und alle mussten aktualisiert werden.
Die wichtigste Entscheidung trafen wir am Mittwochmorgen. Der Angriff funktionierte über einen bekannten Zugang: einen Teil von PHP, den fast keine Website nutzt. Diesen Teil haben wir auf allen unseren Webhosting-Servern und verwalteten Servern abgeschaltet, noch bevor das Update verfügbar war. Dadurch konnten wir Websites online lassen, statt sie vorsorglich abzuschalten. Außerdem haben wir alle PHP-Versionen schon vorab auf die neueste verfügbare Version gebracht, damit das eigentliche Update danach schneller gehen konnte.
| Wann | Was geschah |
|---|---|
| August 2026 | Forscher finden die Lücken, unter anderem mit KI, und melden sie an PHP. |
| Dienstag, 20. Oktober | Details sickern durch, und PHP zieht das Update vor. Wir erfassen alle PHP-Versionen auf allen unseren Servern, auch auf unseren internen Systemen. |
| Mittwoch, 21. Oktober, morgens | Wir schließen den bekannten Zugang für den Angriff auf allen unseren Servern. Cloudflare sieht die ersten Angriffsversuche. |
| Mittwoch, 21. Oktober, tagsüber | Behördenwebsites und mehrere Hosting-Unternehmen gehen vorsorglich offline. Wir müssen keine Websites offline nehmen. |
| Mittwoch, 21. Oktober, 15:38 Uhr | PHP veröffentlicht das Update. Innerhalb einer Stunde ist unser erster Server aktualisiert. |
| Mittwochabend | Das Standard-PHP aller unserer Server läuft mit der neuen Version. CloudLinux liefert aktualisierte Versionen, auch für ältere PHP-Versionen. |
| Nacht auf Donnerstag, 22. Oktober | Alle PHP-Versionen auf allen unseren Webhosting-Servern sind aktualisiert. |
| Donnerstag, 22. Oktober, morgens | Abschlusskontrolle aller Server und internen Systeme: nichts vergessen. |
Die PHP-Versionen, die Sie für Ihre Website wählen, stammen von CloudLinux, dem Betriebssystem auf unseren Servern. CloudLinux liefert auch Korrekturen für ältere PHP-Versionen, für die PHP selbst keine Updates mehr herausbringt. Nach dem Update haben wir auf jedem Server geprüft, ob die Korrektur wirklich enthalten war, und Websites vorher und nachher getestet.
Was hätte PHP2Shell anrichten können?
Angenommen, ein Server wäre nicht rechtzeitig aktualisiert worden. Was könnte ein Angreifer dann mit einer Website anstellen?
- Daten stehlen. Die Datenbank einer Website enthält oft Namen, Adressen, Bestellungen und Zugangsdaten von Kunden.
- Zahlungen abgreifen. In einem Onlineshop kann heimlich Code platziert werden, der die Zahlungsdaten von Besuchern abfängt, ohne dass der Betreiber etwas merkt.
- Geheimnisse auslesen. Über den Arbeitsspeicher des Servers können Passwörter und Schlüssel nach außen gelangen, zum Beispiel die für die Anbindung an Ihren Zahlungsanbieter oder Ihre Buchhaltungssoftware.
- Ihre Website missbrauchen. Für gefälschte Login-Seiten, Spam oder die Weiterleitung von Besuchern auf Betrugsseiten. Die Folge: Google warnt Besucher, dass Ihre Website möglicherweise gehackt wurde, und Ihre E-Mails landen auf schwarzen Listen.
Vielleicht denken Sie: Meine Website ist zu klein, um interessant zu sein. Leider funktioniert das so nicht. Angreifer suchen nicht von Hand nach Opfern. Sie lassen Programme das gesamte Internet nach verwundbaren Websites durchsuchen, innerhalb weniger Stunden nach einer solchen Bekanntgabe. Jede Website mit einer verwundbaren PHP-Version ist dann ein Ziel, ob groß oder klein.
Und der Schaden bleibt nicht bei der Technik. Gelangen personenbezogene Daten nach außen, müssen Sie das als Unternehmer bei der Datenschutzbehörde melden, in den Niederlanden ist das die Autoriteit Persoonsgegevens. Hinzu kommen Wiederherstellungskosten, Umsatzeinbußen und ein Kratzer im Vertrauen Ihrer Kunden.
Bei uns läuft jede Website in einer eigenen, abgeschirmten Umgebung. Geht irgendwo doch etwas schief, gelangt ein Einbruch in eine Website nicht ohne Weiteres zu den Nachbarn. Das ist eine zusätzliche Sicherheitsebene, aber kein Ersatz für rechtzeitige Updates.
Müssen Sie nach PHP2Shell selbst etwas tun?
Für das PHP-Update selbst nicht. Ein paar Tipps haben wir trotzdem:
- Prüfen Sie es, wenn Sie möchten. In unserem Wissensdatenbank-Artikel (auf Niederländisch) lesen Sie, wie Sie erkennen, dass das Update installiert ist, und warum Ihre Versionsnummer manchmal gleich bleibt.
- Nutzen Sie PHP 8.1 oder älter? Diesmal gab es auch für diese Versionen eine Lösung, aber das ist nicht immer so. Wechseln Sie auf PHP 8.2 oder höher. In diesem Artikel lesen Sie, wie Sie die richtige Version wählen.
- Halten Sie Ihre Website selbst aktuell. Wir kümmern uns um den Server und PHP. WordPress, Plug-ins und Themes aktualisieren Sie selbst. Weitere Tipps finden Sie in Website absichern: 8 Tipps gegen Hacker.
- Haben Sie anderswo eine Website oder einen eigenen Server? Dann prüfen Sie, ob PHP auf Version 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder neuer aktualisiert wurde.
Den aktuellen Stand bei Störungen und Wartungsarbeiten finden Sie immer auf status.theory7.net. Sind Sie sich bei Ihrer eigenen Website unsicher? Erstellen Sie ein Ticket mit Ihrem Domainnamen. Wir sehen gern für Sie nach.
Sicherheitslücken in Software wird es immer geben, auch im Fundament des Internets. Entscheidend ist, wie schnell sie geschlossen werden. Damit waren wir diese Woche beschäftigt, und so machen wir es auch weiterhin.
Häufig gestellte Fragen
Was ist PHP2Shell?
PHP2Shell ist der Spitzname für zwei schwere Sicherheitslücken in PHP (CVE-2026-109618 und CVE-2026-109619), die am 21. Oktober 2026 bekannt gegeben wurden. Ein Angreifer konnte damit ohne Passwort einen Webserver übernehmen. PHP hat sie in den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 behoben.
War meine Website bei Theory7 verwundbar?
Jede Website, die mit PHP läuft, war bis zum Update grundsätzlich verwundbar. Wir haben schon am Mittwochmorgen, dem 21. Oktober, einen bekannten Zugang für den Angriff geschlossen und die Updates danach auf allen unseren Webhosting-Servern installiert, die letzten in der Nacht vom 21. auf den 22. Oktober.
Warum gingen andere Websites offline, die von Theory7 aber nicht?
Wer das Update nicht ohne Risiko abwarten konnte, nahm Websites vorsorglich offline. Wir hatten den bekannten Zugang für den Angriff schon am Mittwochmorgen geschlossen, noch bevor das Update verfügbar war. Dadurch konnten Websites bei uns online bleiben, während wir das Update installierten.
Muss ich selbst etwas tun?
Für das PHP-Update nicht, das haben wir installiert. Wenn Sie PHP 8.1 oder älter nutzen, empfehlen wir den Wechsel auf PHP 8.2 oder höher. Halten Sie außerdem Ihre Website selbst aktuell, etwa WordPress und Plug-ins.
Wie prüfe ich, ob mein PHP aktualisiert ist?
Sehen Sie sich das Build-Datum Ihrer PHP-Version an. Steht dort der 21. Oktober 2026 oder ein späteres Datum, ist das Update enthalten. In unserem Wissensdatenbank-Artikel zum PHP-Sicherheitsupdate (auf Niederländisch) lesen Sie Schritt für Schritt, wie Sie das prüfen.
