PHP2Shell: Ist Ihre Website schon gepatcht?
Zwei kritische Lücken in PHP selbst betreffen fast jede Website, egal ob TYPO3, WordPress oder Shop. Woran Sie erkennen, ob Ihre Website schon geschützt ist, welche Fragen Sie Ihrer Agentur stellen sollten und warum ältere PHP-Versionen keinen offiziellen Patch mehr bekommen.
Zwei kritische Lücken in PHP selbst
Am 21.10.2026 hat das PHP-Projekt zwei kritische Sicherheitslücken veröffentlicht, die unter dem Namen PHP2Shell bekannt geworden sind (CVE-2026-109618 und CVE-2026-109619). Beide erreichen den höchsten Schweregrad. Wer sie ausnutzt, kann auf dem Server eigenen Programmcode ausführen, ohne Passwort und ohne dass jemand etwas anklicken muss.
Die Lücken stecken nicht in TYPO3, WordPress oder einer Erweiterung, sondern in PHP selbst. PHP ist die Programmiersprache, mit der der Großteil aller Websites läuft. Betroffen ist laut PHP-Projekt (externer Link) jede PHP-Installation, die Webanfragen beantwortet, egal welches CMS darauf läuft und wie aktuell es ist. Sicherheitsfirmen berichten von Angriffsversuchen seit Mitte Oktober, also schon vor der Veröffentlichung.
Für Betreiberinnen und Betreiber heißt das: Die Website kann auf dem neuesten Stand sein und trotzdem offen stehen, wenn der Server darunter nicht aktualisiert wurde.
Welche PHP-Versionen einen Patch bekommen
Das PHP-Projekt hat am selben Tag korrigierte Versionen veröffentlicht. Sicher sind Server mit mindestens:
| PHP-Zweig | Korrigierte Version | Sicherheitsupdates bis |
|---|---|---|
| 8.5 | 8.5.12 | 31.12.2029 |
| 8.4 | 8.4.27 | 31.12.2028 |
| 8.3 | 8.3.36 | 31.12.2027 |
| 8.2 | 8.2.35 | 31.12.2026 |
| 8.1 und älter | kein offizieller Patch | bereits ausgelaufen |
Für PHP 8.1, 8.0 und 7.4 gibt es keine offizielle Version mehr. Diese Zweige bekommen vom PHP-Projekt seit Längerem keine Updates. Das Sicherheitsteam hat zwar Code-Korrekturen für alle drei bereitgestellt, aber nur als Quelltext für alle, die PHP selbst kompilieren. Einige Linux-Distributionen und Anbieter von Langzeit-Support portieren die Korrekturen für PHP2Shell zurück, Details stehen im Abschnitt „Paketversion statt PHP-Version". Andere Schwachstellen bleiben in diesen Zweigen offen. Läuft Ihre Website noch auf einer dieser Versionen, ist der Wechsel auf einen unterstützten PHP-Zweig der dauerhaft verlässliche Weg.
Das betrifft vor allem ältere Websites: TYPO3 v11 läuft zum Beispiel mit PHP 7.4 bis 8.3, viele dieser Installationen sind nie über PHP 8.1 hinausgekommen. Und PHP 8.2 bekommt den Patch zwar noch, aber nur bis Jahresende. Mehr dazu in unserem Beitrag PHP 8.2: Sicherheitsupdates enden am 31.12.2026.
Quelle: php.net (externer Link), Stand 25.10.2026.
Support-Zeiträume der PHP-Versionen
Die Fristen aktualisieren sich täglich. Der Countdown zeigt, wie viele Tage jeder Version bis zum Ende der aktuellen Phase bleiben.
- Aktiver Support
- Nur Sicherheitsupdates
| Version | Stand heute | Aktiver Support bis | Sicherheitsupdates bis | Aktuelles Release |
|---|---|---|---|---|
| PHP 8.1 | 8.1.34 | |||
| PHP 8.2 | 8.2.35 | |||
| PHP 8.3 | 8.3.36 | |||
| PHP 8.4 | 8.4.27 | |||
| PHP 8.5 | 8.5.12 |
Quelle: endoflife.date (Daten von php.net), Stand 29.10.2026
So finden Sie heraus, ob Ihre Website betroffen ist
Die PHP-Version Ihrer Website sehen Sie bei TYPO3 im Backend unter den Systeminformationen, bei WordPress unter „Werkzeuge > Website-Zustand“. Wichtig ist die vollständige Nummer mit drei Stellen: 8.3.36 ist sicher, 8.3.35 nicht.
Haben Sie keinen Zugang oder sind Sie unsicher, fragen Sie Ihre Agentur oder Ihren Hoster. Diese Fragen helfen Ihnen dabei:
- Welche PHP-Version läuft auf dem Server, der unsere Website ausliefert, mit vollständiger Versionsnummer?
- Wann wurde das Update eingespielt, und wurden danach alle PHP-Prozesse neu gestartet?
- Wurden die Server-Logs seit August auf Auffälligkeiten geprüft?
- Falls die Website noch auf PHP 8.1 oder älter läuft: Wie und bis wann wechseln wir?
- Wer ist bei der nächsten Lücke zuständig, und wie schnell wird reagiert?
Eine gute Agentur beantwortet die ersten beiden Fragen innerhalb eines Tages. Wenn die Antwort lange auf sich warten lässt oder vage bleibt, ist das selbst schon eine Antwort.
Paketversion statt PHP-Version
Läuft PHP als Paket einer Linux-Distribution, sagt die Ausgabe von php -v wenig. Distributionen übernehmen Korrekturen in ihre alten Versionsnummern. Ubuntu 22.04 zeigt PHP 8.1.2 und Ubuntu 24.04 PHP 8.3.6, beide Systeme können gepatcht sein. Maßgeblich ist die Paketversion.
| System | Paket | Gepatcht ab |
|---|---|---|
| Ubuntu 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| Ubuntu 26.04 | php8.5 | 8.5.4-0ubuntu1.5 |
| Ubuntu 24.04 | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| Ubuntu 22.04 | php8.1 | 8.1.2-1ubuntu2.28 |
| Debian 13 (trixie) | php8.4 | 8.4.27-1~deb13u1 |
| Debian 12 (bookworm) | php8.2 | 8.2.35-1~deb12u1 |
| RHEL 9 | php:8.2 | 8.2.35-1.module+el9.8.0+25111+a1450321 |
| RHEL 8 | php:7.4 | 7.4.33-8.module+el8.10.0+25117+30337cca |
Für Alma, Rocky, SUSE und Alpine liegt keine Prüfung vor. Dort muss die Paketversion beim Hersteller nachgeschlagen werden. Ob ein Paket gepatcht ist, zeigt sein Änderungsprotokoll, bei Debian und Ubuntu zum Beispiel mit zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz (Paketname an die installierte Version anpassen). Nach dem Update muss PHP-FPM bzw. Apache neu gestartet werden, sonst läuft die alte Binärdatei weiter.
Quellen: Ubuntu Security (externer Link) (CVE-2026-109618), Debian Security Tracker (externer Link) (CVE-2026-109618) rahulranjan.org (externer Link) (Fixed Versions Ubuntu, Debian, RHEL, Amazon Linux), TuxCare (externer Link) (ELS für PHP 8.1 und älter), Sansec (externer Link).
Gepatcht heißt nicht automatisch sauber
Ein Update schließt die Lücke, es entfernt aber nichts, was vorher eingeschleust wurde. Weil es Angriffsversuche schon vor der Veröffentlichung gab, sollte jede Website, die bis zum Update offen war, auf Spuren geprüft werden: unbekannte oder kürzlich veränderte PHP-Dateien, ungewöhnliche Uploads in den Logs, neue Backend-Konten und Verbindungen vom Server zu unbekannten Zielen.
Das PHP-Projekt hat am 23.10.2026 außerdem eine dritte, verwandte Lücke angekündigt (CVE-2026-115560: php.net (externer Link), CERT-EU (externer Link)), die mit den Updates vom 21.10. noch nicht geschlossen ist. Sie wird mit der nächsten regulären PHP-Version behoben, bis dahin gibt es eine Server-Einstellung, die den Angriffsweg sperrt. Auch danach lohnt sich die Frage an die Agentur.
Wie wir bei TYPOHEADS reagiert haben
Wir betreiben die Websites unserer Kundinnen und Kunden in Containern, die alle auf einem gemeinsamen Basis-Image aufbauen. Als die korrigierten PHP-Versionen am Mittwoch erschienen, haben wir dieses Basis-Image neu gebaut und die Websites nacheinander ausgerollt. Seit Donnerstag, 22.10.2026, laufen alle von uns betriebenen Websites auf unterstützten PHP-Versionen mit dem Patch.
Updates spielen wir laufend ein, das ist Teil jeder Wartung. Bisher war zwischen der Veröffentlichung einer Sicherheitslücke und den ersten Angriffen meist Zeit für ein geplantes Update im nächsten Wartungsfenster. Bei PHP2Shell gab es die ersten Angriffsversuche schon vor der Veröffentlichung. Solche Fälle sind noch die Ausnahme, werden aber häufiger. Dann zählt, ob jemand innerhalb von Stunden statt Wochen reagieren kann.
Was das für die Zukunft heißt
PHP2Shell wird nicht die letzte Lücke dieser Art sein. Werkzeuge mit künstlicher Intelligenz finden Schwachstellen schneller, und die Zeit zwischen Veröffentlichung und ersten Angriffen wird kürzer. Für alle, die eine Website betreiben, zählen deshalb drei Dinge:
- Eine unterstützte Basis: PHP- und CMS-Versionen, die noch Sicherheitsupdates bekommen. Wer ausgelaufene Versionen betreibt, hat bei der nächsten Lücke keine Wahl mehr.
- Klare Zuständigkeit: Ein Vertrag, in dem steht, wer Updates einspielt und in welcher Zeit. „Wir kümmern uns, wenn etwas ist“ reicht nicht, wenn Angriffe schon am Tag der Veröffentlichung laufen.
- Nachweise: Wer zeigen kann, wann welche Version lief, ist bei Fragen von Versicherung, Aufsicht oder Geschäftsführung auf der sicheren Seite. Für Organisationen unter NIS2 ist das ohnehin Pflicht, siehe NIS2 und die eigene Website.
Wie das bei uns aussieht, beschreiben wir unter TYPO3-Hosting, Wartung & SLA.
Häufige Fragen zu PHP2Shell
Ist meine TYPO3- oder WordPress-Website betroffen?
Ja, wenn der Server eine PHP-Version vor 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 verwendet. Bei Distributionspaketen entscheidet die Paketversion. Die Lücken liegen in PHP, nicht im CMS. Ein aktuelles TYPO3 oder WordPress schützt deshalb nicht.
Bekommt PHP 8.1 noch einen Patch?
Nein, keine offizielle Version. Für PHP 8.1, 8.0 und 7.4 gibt es nur Code-Korrekturen zum Selbstkompilieren und je nach Anbieter gepatchte Pakete von Linux-Distributionen, etwa bei Ubuntu 22.04 und RHEL 8. Andere Schwachstellen bleiben in diesen Zweigen offen. Dauerhaft hilft der Wechsel auf PHP 8.2 oder neuer, besser gleich auf 8.4 oder 8.5.
Reicht es, das Update einzuspielen?
Es schließt die Lücke, entfernt aber keine Hintertür, die vorher eingeschleust wurde. Websites, die bis zum Update erreichbar waren, sollten auf Spuren eines Angriffs geprüft werden.
Wie finde ich die PHP-Version meiner Website heraus?
In TYPO3 unter den Systeminformationen im Backend, in WordPress unter „Werkzeuge > Website-Zustand“. Ohne Zugang fragen Sie Ihre Agentur oder Ihren Hoster nach der vollständigen Versionsnummer.
Was bedeuten CVE-2026-109618 und CVE-2026-109619?
Das sind die offiziellen Kennungen der beiden Lücken. Unter diesen Nummern finden Sie Warnungen von Behörden und Herstellern, etwa im Advisory des PHP-Projekts.
Über den Autor
