php2shell und TYPO3: Was die PHP-Lücke für Ihre Website bedeutet
TYPO3 müssen Sie nicht aktualisieren. PHP schon.
Am 21. Oktober 2026 wurden zwei schwere Sicherheitslücken in PHP bekannt, Spitzname php2shell. PHP ist die Programmiersprache, auf der TYPO3 läuft, gewissermaßen der Motor unter der Haube. Über die Lücken können Angreifer ohne Passwort eigene Befehle auf dem Server ausführen, auf dem Ihre Website liegt. Betroffen ist jede Website, die auf PHP läuft, TYPO3 eingeschlossen.
TYPO3 selbst müssen Sie nicht aktualisieren, PHP schon. Hier lesen Sie, wie ernst die Lage ist, woran Sie erkennen, ob Ihre Website geschützt ist, und wie wir den Tag mit den Websites unserer Kunden erlebt haben.
- php2shell
-
php2shell ist der Spitzname für zwei schwere Sicherheitslücken in PHP. Auf der üblichen Bewertungsskala erreichen beide 9,2 von 10 Punkten. Wer sie ausnutzt, kann ohne Passwort eigene Befehle auf dem Server ausführen. Der Name spielt auf „Log4Shell“ an, eine frühere Lücke ähnlicher Tragweite.
-
Abgrenzung
Der Fehler steckt nicht in TYPO3, sondern eine Ebene darunter. Ein Angriff kann deshalb greifen, bevor TYPO3 überhaupt etwas tut. Die Sicherheitsfunktionen von TYPO3 helfen dagegen nicht.
Die Lage am 22. Oktober
Am 20. Oktober gelangten erste Details zu früh an die Öffentlichkeit. Noch am selben Tag kündigte das PHP-Projekt die Reparatur für den nächsten Tag an, am 21. Oktober um 16 Uhr deutscher Zeit. Gefunden hatten die Fehler Sicherheitsforscher, unter anderem von Wiz Research, schon im August.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft die Lage als „Orange“ ein, die zweithöchste von vier Stufen. Das heißt: unverzüglich handeln. Wer die Reparatur nicht gleich einspielen kann, soll laut BSI erwägen, seine Website vorübergehend vom Netz zu nehmen, denn Notlösungen schützen nicht zuverlässig.
Werden die Lücken schon ausgenutzt? Darüber gehen die Meinungen auseinander:
- Das BSI kannte am 21. Oktober keine bestätigten Angriffe, erwartet sie aber sehr bald.
- Sicherheitsfirmen wie watchTowr und Cloudflare sehen erste Angriffsversuche. Einen bestätigten Einbruch meldet bisher keine von ihnen.
- Amazon meldet einen ersten Angriffsversuch schon am 17. Oktober, vier Tage vor der Veröffentlichung, und spricht von breiter Ausnutzung. Ob ein Angriff erfolgreich war, ist laut Amazon unklar.
Viele Betreiber haben ihre Websites am 21. Oktober vorsorglich abgeschaltet, auch das BSI berichtet von eingeschränkt erreichbaren Websites. Wenn Sie an dem Tag auf Wartungsseiten gestoßen sind, war das meist der Grund.
Welche PHP-Version Sie jetzt brauchen
PHP gibt es in mehreren Versionen nebeneinander, und für jede gibt es eine eigene reparierte Fassung. Welche bei Ihnen läuft, kann Ihnen Ihr Dienstleister oder Hoster sagen.
| Ihre PHP-Version | Geschützt ab | Hinweis |
|---|---|---|
| PHP 8.5 | 8.5.12 | |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | bekommt nur noch bis Ende 2026 Sicherheitsupdates |
| PHP 8.1, 8.0, 7.4 | kein neues Release | nur Quellcode-Korrekturen des PHP-Teams; manche Linux-Anbieter liefern daraus fertige Updates |
| PHP 7.3 und älter | keine Reparatur | allenfalls über kostenpflichtige Langzeit-Anbieter; besser umsteigen |
Was das für TYPO3 bedeutet
Die TYPO3 GmbH, die hinter TYPO3 steht, hat am selben Tag die Mitteilung TYPO3-PSA-2026-001 veröffentlicht. Kurz gesagt: TYPO3 selbst ist nicht betroffen und braucht kein Update. PHP dagegen muss auf jeder Installation sofort aktualisiert werden. Welche PHP-Version läuft, sieht Ihre Redaktion im TYPO3-Backend oben in der Werkzeugleiste unter den Systeminformationen.
Wer sich kümmern muss, hängt davon ab, wo Ihre Website liegt:
- Bei einem Hoster (Webspace oder verwalteter Server): Der Hoster spielt das Update ein. Lassen Sie sich trotzdem bestätigen, dass die neue Version wirklich läuft.
- Auf einem eigenen Server: Ihr Dienstleister aktualisiert PHP über das Betriebssystem. Manche Linux-Anbieter reparieren die Lücke, ohne die Versionsnummer zu ändern. Ob das geschehen ist, steht in deren Sicherheitshinweisen.
- In Docker-Containern, also abgeschlossenen Paketen aus Website und Software: Das Paket muss neu gebaut und neu gestartet werden. Genau hier lauert eine Falle, dazu gleich mehr.
Ältere TYPO3-Versionen haben ein zusätzliches Problem. TYPO3 v10 läuft nur mit PHP-Versionen, für die das PHP-Projekt kein fertiges Update mehr liefert. Die TYPO3 GmbH empfiehlt dort kostenpflichtige Sicherheitsupdates, etwa über Ubuntu Pro. Wer TYPO3 v11 oder v12 noch mit PHP 8.1 betreibt, sollte auf PHP 8.2 oder neuer wechseln. Wie lange Ihre TYPO3-Version selbst noch versorgt wird, steht in der Übersicht der TYPO3-Versionen.
Warum „einfach neu bauen“ nicht gereicht hätte
Wir betreiben die Websites unserer Kunden in eigenen Docker-Containern, die wir auf TYPO3 zugeschnitten und auf Geschwindigkeit optimiert haben. Jeder Kunde hat seinen eigenen Server und dazu ein eigenes Testsystem. Jede Änderung läuft zuerst im Testsystem, erst danach geht sie live. Das galt auch am 21. Oktober.
Alle Container bauen auf einem gemeinsamen Grundpaket auf, in dem PHP steckt. Dieses Grundpaket bezog PHP bisher von Alpine Linux, einem verbreiteten Linux-Anbieter. Als die Reparatur am Nachmittag erschien, hatte Alpine sie noch nicht, und wann sie kommen würde, war offen. Bei einem besonders abgesicherten Grundpaket eines anderen Anbieters, das wir gerade testeten, war es genauso. Ein Neubau hätte in diesem Moment nur ein frisches, aber weiterhin verwundbares Paket erzeugt. Alpine lieferte die Reparatur erst am Abend nach.
Das offizielle PHP-Paket für Docker hatte die Reparatur dagegen noch am selben Tag. Wir haben unser Grundpaket deshalb darauf umgestellt und vorher geprüft, dass unsere eigene Website danach genauso ausgeliefert wird wie vorher. Die Lehre daraus: Wer PHP über einen Zwischenhändler bezieht, bekommt Reparaturen in dessen Tempo.
Wie wir den 21. Oktober erlebt haben
Gegen 16 Uhr, als die Reparatur erschien, haben wir alle Websites, die wir betreuen, vorsorglich vom Netz genommen. So legt es das BSI für Systeme nahe, die noch nicht repariert sind. Danach haben wir das gemeinsame Grundpaket umgestellt und jede Website darauf neu aufgebaut. Websites, die bis dahin noch ein eigenes Paket hatten, haben wir am selben Tag umgezogen. Bei einem älteren Projekt brauchte es einen zweiten Anlauf.
Kurz vor Mitternacht waren alle Seiten wieder online, mit der reparierten PHP-Version 8.4.27. Auch Websites mit der älteren TYPO3-Version 12 bekamen die Reparatur, ohne dass wir an TYPO3 selbst etwas ändern mussten.
Seit diesem Tag laufen alle Projekte auf demselben, zentral gepflegten Grundpaket. Jede Aktualisierung ersetzt die alte Fassung, und wir können jederzeit auf die vorige zurück. Das nächste PHP-Update ist damit eine Änderung an einer Stelle, nicht in jedem Projekt einzeln. Eine Falle haben wir dabei selbst entdeckt: Unser Baurechner hält das Grundpaket zwischengespeichert und nimmt ohne ausdrücklichen Befehl die alte Fassung. Ein Neubau allein beweist deshalb nichts. Erst ein Blick in die laufende Website zeigt, welche Version wirklich drin ist.
Was Sie heute klären sollten
- Fragen Sie Ihren Dienstleister oder Hoster, welche PHP-Version auf Ihrer Website läuft, oder lesen Sie sie im TYPO3-Backend ab
- Gleichen Sie die Antwort mit der Tabelle oben ab
- Lassen Sie sich bestätigen, dass die Version auf der laufenden Website geprüft wurde, nicht nur, dass ein Update eingespielt ist
- Läuft noch PHP 8.1 oder älter: Lassen Sie den Umstieg auf PHP 8.2 oder neuer planen
- Bitten Sie Ihre IT, die Server-Protokolle auf auffällige Häufungen von Fehlern zu prüfen. Das ist ein Hinweis aus Fachmedien, gesicherte Angriffsmerkmale nennt das BSI noch nicht
- Denken Sie an andere Geräte mit PHP im Haus, etwa Firewalls oder Netzwerkspeicher (NAS)
Häufig gestellte Fragen
Nein. Laut TYPO3 GmbH ist TYPO3 selbst nicht betroffen. Repariert werden muss PHP, die Software unter TYPO3. Ein TYPO3-Update allein schützt nicht.
An der PHP-Version, die tatsächlich läuft: 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder neuer. Ihr Dienstleister kann sie Ihnen sagen, im TYPO3-Backend steht sie unter den Systeminformationen. Manche Linux-Anbieter reparieren die Lücke, ohne die Versionsnummer zu ändern. Dann zählt deren Sicherheitshinweis.
Nein. Solche Filter, Web Application Firewalls genannt, fangen bekannte Angriffsmuster ab und überbrücken die Zeit bis zum Update. BSI und PHP-Projekt sind sich einig: Nur das Update schließt die Lücken vollständig.
Stand 22. Oktober sehen Sicherheitsfirmen viele Angriffsversuche, Amazon spricht von breiter Ausnutzung. Ob dabei ein Einbruch gelungen ist, ist noch nicht bestätigt. Abwarten, bis die Lage klar ist, ist deshalb keine gute Idee.
Ihr Dienstleister muss das Paket neu bauen und danach in der laufenden Website prüfen, welche PHP-Version drin ist, etwa mit docker exec <container> php -v. Ein frischer Neubau allein beweist nichts. Kommt PHP über einen Linux-Anbieter, kann die Reparatur dort später ankommen. Dann hilft der Wechsel auf das offizielle PHP-Paket, das sie schon enthält.
