PHP-Sicherheitslücke PHP2Shell: Was Sie heute tun müssen

Am 21. Oktober 2026 hat das PHP-Team außerplanmäßig vier Versionen veröffentlicht. Der Grund sind zwei Schwachstellen, die unter dem Namen PHP2Shell laufen und mit CVSS 9.2 von 10 bewertet sind: Ein Angreifer kann aus der Ferne eigenen Code auf dem Webserver ausführen, ohne sich anzumelden und ohne dass jemand auf etwas klicken muss. Diese PHP-Sicherheitslücke betrifft praktisch jeden Webserver, der PHP ausliefert. Dieser Beitrag ordnet ein, wer betroffen ist und in welcher Reihenfolge zu handeln ist.

Das BSI führt die Warnung unter dem Aktenzeichen 2026-297981-1032 in Warnstufe 3 (Orange). Wenn Sie nur fünf Minuten haben: Springen Sie zur Checkliste am Ende.

Was PHP2Shell ist

Hinter dem Namen stecken zwei Einträge: CVE-2026-109618 und CVE-2026-109619. Beide haben dieselbe Wurzel. PHP räumt am Ende einer Anfrage den belegten Arbeitsspeicher auf. Bricht eine Anfrage vorher unsauber ab – typischerweise, weil das konfigurierte Speicherlimit erschöpft ist –, bleibt dieser Aufräumvorgang auf halbem Weg stehen. Der Arbeitsprozess bedient aber weiter Anfragen. Die nächste Anfrage trifft dann auf Speicher, der eigentlich freigegeben war, und behandelt ihn als gültige Daten.

Fachleute nennen das einen Use-after-free. Wer einen solchen Zustand gezielt herbeiführen kann, bestimmt in Grenzen mit, was in diesem Speicher steht – und damit, was der Server tut. Am Ende steht die Ausführung eigenen Codes mit den Rechten des Webserver-Benutzers.

Der zweite Namensbestandteil ist eine Anspielung auf Log4Shell. Die Parallele liegt nicht in der Technik, sondern in der Verbreitung: Es geht um einen Baustein, der fast überall steckt und den kaum jemand auf dem Schirm hat.

Warum der Name „2Shell" hier berechtigt ist

Eine Shell ist eine Befehlszeile. Wer eine Shell auf einem Server hat, kann dort tun, was der jeweilige Benutzer darf: Dateien lesen und schreiben, Programme starten, Verbindungen nach außen aufbauen. Der Webserver-Benutzer hat selten Administratorrechte, aber er hat Zugriff auf das Verzeichnis der Website, auf Konfigurationsdateien und häufig auf die Zugangsdaten zur Datenbank. Das reicht für Datenabfluss, für eine manipulierte Website und als Sprungbrett tiefer ins Netz.

Wer betroffen ist

Hier liegt der unangenehme Teil. Betroffen sind nicht einzelne Versionen, sondern praktisch alle.

Besonders wichtig: Es geht nicht nur um die Firmenwebsite. PHP steckt in Intranet-Anwendungen, in Ticketsystemen, in Webmail-Oberflächen, in Verwaltungsoberflächen von Netzwerkgeräten und in Software, die ein Lieferant einmal installiert hat. Die Frage lautet also nicht „betreiben wir eine Website", sondern „wo überall läuft bei uns PHP".

Wer eine Website mit WordPress, TYPO3 oder Magento betreibt und keinen Zugriff auf den Server hat, findet das Vorgehen dafür in WordPress-Sicherheit nach PHP2Shell. Zum laufenden Betrieb einer Unternehmenswebsite haben wir die Grundlagen unter Firmenwebsite sicher betreiben zusammengefasst.

Dass bereits angegriffen wird, ist belegt

Die Details sind am 20. Oktober vorzeitig öffentlich geworden. Das PHP-Team hat daraufhin eine Vorwarnung herausgegeben und die Veröffentlichung auf den 21. Oktober gelegt. Cloudflare berichtete von Angriffsverkehr gegen Kundenseiten ab 07:43 Uhr UTC – also mehrere Stunden bevor der Patch überhaupt verfügbar war.

Das ändert die Lage: Es geht nicht um Vorsorge gegen etwas, das vielleicht kommt. Es wird gesucht, und zwar seit heute früh.

Die Reihenfolge, auf die es ankommt

Erstens: herausfinden, wo PHP läuft

Ohne diese Liste ist alles Weitere Stückwerk. Gemeint sind nicht nur die Server im eigenen Haus, sondern auch Webhosting-Pakete, gemietete Server und Anwendungen, die ein Dienstleister betreut. Prüfen Sie auch Systeme, an die niemand mehr denkt: die alte Projektseite, das Testsystem, das Archiv.

Zweitens: patchen

Behoben ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Team ist deutlich: Nur das Einspielen schützt vollständig. Wer Webhosting bei einem Anbieter nutzt, muss selbst nichts tun, sollte sich aber bestätigen lassen, dass und wann aktualisiert wurde – schriftlich, nicht am Telefon.

Drittens: notfalls abschalten

Das BSI nennt diesen Schritt ausdrücklich: patchen oder das System vom Internet trennen. Eine Website, die für einen Tag nicht erreichbar ist, kostet Umsatz. Ein übernommener Server kostet mehr. Wenn Sie heute keinen Patch einspielen können, ist Abschalten die richtige Entscheidung – und kein Zeichen von Kopflosigkeit.

Viertens: Notbehelfe, wenn beides nicht geht

Für Systeme, die weder gepatcht noch abgeschaltet werden können, nennen Sicherheitsforscher drei Behelfe. Alle bekannten Angriffe laufen bisher über Datei-Uploads, also über Anfragen im Format multipart/form-data. Wer diese auf der vorgelagerten Firewall oder im Webserver blockiert, nimmt den Angriffen die bekannte Eintrittstür. Zweitens lässt sich der Dienst auf lesende Zugriffe beschränken, also auf GET und HEAD. Drittens lässt sich in der `php.ini` die Einstellung `session.upload_progress.enabled` auf `Off` setzen.

Das sind Behelfe, keine Lösung. Sie schließen die Lücke nicht, sie erschweren den bekannten Weg dorthin. Sobald ein Patch möglich ist, gehört er eingespielt.

Fünftens: nachsehen, ob schon etwas passiert ist

Ein eingespielter Patch beseitigt die Lücke, aber nicht einen Angreifer, der vorher hereingekommen ist. Wer seit heute früh ein verwundbares System im Netz hatte, sollte die Protokolle ansehen. Worauf dabei zu achten ist, behandeln wir ausführlich im Beitrag PHP2Shell-Angriff erkennen.

Ein zweiter Punkt gehört dazu: Was von außen überhaupt erreichbar ist, wissen die wenigsten vollständig. Wie Sie das systematisch klären, beschreibt unser Beitrag zur Angriffsfläche von außen.

Was das für den Mittelstand bedeutet

Die meisten Unternehmen mit 10 bis 500 Arbeitsplätzen betreiben ihren Webserver nicht selbst. Daraus folgt nicht, dass Sie nichts tun müssen – es folgt, dass Ihre Aufgabe eine andere ist: Verschaffen Sie sich Gewissheit, statt sie vorauszusetzen.

Fragen Sie bei jedem Dienstleister, der etwas mit PHP betreibt, drei Dinge: Welche PHP-Version läuft? Ist auf eine der heute veröffentlichten Fassungen aktualisiert worden, und wann? Wurde geprüft, ob zwischen heute früh und dem Patch etwas passiert ist? Notieren Sie die Antworten mit Datum. Das ist nicht Misstrauen, sondern Dokumentation – und im Ernstfall genau das, was Ihre Versicherung oder eine Aufsichtsbehörde sehen will.

Checkliste: erste Schritte

Wie DAVINCI unterstützt

Wir prüfen für Sie, wo in Ihrer Umgebung PHP läuft, bringen die betroffenen Systeme auf einen sicheren Stand und sehen nach, ob zwischen Bekanntwerden und Patch etwas passiert ist. Besteht der Verdacht auf einen Zugriff, übernimmt unser Incident Response. Wenn es brennt, erreichen Sie uns rund um die Uhr über IT-Notfall – ansonsten über die Kontaktseite.

Verwandte Themen: Wer hier weiterdenkt, liest bei Remote Code Execution, WordPress-Sicherheit und Schwachstellenmanagement weiter.