Kritische PHP-Lücke php2shell: der Tag im Verlauf – und was jetzt zu tun ist

9:20 Uhr · Zwei Lücken, Angriffe – und kein Patch

Seit dem frühen Morgen läuft eine Meldung durch die Fachpresse, die ungewöhnlich viele Websites betrifft: In PHP stecken zwei schwerwiegende Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, zusammengefasst unter dem Namen php2shell. Was ein Angreifer damit erreichen kann, ist schnell gesagt: eigenen Programmcode auf dem Webserver ausführen. Ohne Zugangsdaten, ohne Anmeldung, ohne dass jemand auf etwas klicken muss.

Bemerkenswert ist der Weg an die Öffentlichkeit. Gemeldet wurden die Lücken bereits am 11. August, die koordinierte Offenlegung lief seitdem, ein Patch war für den 22. Oktober vorbereitet. Am 20. Oktober sickerten die Details durch – ein inzwischen gelöschter Beitrag auf Hacker News, danach Screenshots in sozialen Netzwerken. Die Sicherheitsforscher von watchTowr bestätigten öffentlich, dass die Berichte echt sind, ohne weitere Einzelheiten zu nennen. Ihre Empfehlung an diesem Morgen lautet schlicht: ernst nehmen und patchen, sobald es etwas zu patchen gibt.

Nur gibt es das zu diesem Zeitpunkt nicht. Und das ist die unangenehme Lage des Vormittags: Die Lücke ist öffentlich, der Patch nicht da.

9:43 Uhr · Die ersten Angriffsversuche waren schon vorher da

Cloudflare beobachtet die ersten Angriffsversuche – nach eigenen Angaben um 7:43 Uhr UTC, also 9:43 Uhr deutscher Zeit. Das ist der Moment, in dem aus einem theoretischen Risiko ein laufender Vorgang wird.

Für Betreiber heißt das: Es geht nicht mehr um die Frage, ob jemand die Lücke ausnutzen wird. Es geht nur noch darum, ob die eigene Website erreicht wird, bevor sie korrigiert ist.

Im Lauf des Vormittags · Das BSI warnt

Das Bundesamt für Sicherheit in der Informationstechnik gibt eine eigene Cybersicherheitswarnung heraus. Das tut es nicht bei jeder Lücke. Die Bewertung dort: CVSS 9.2 von 10 nach Version 4.0 – ausnutzbar aus der Ferne, ohne Authentifizierung, ohne Nutzerinteraktion.

In der Warnung steht auch der Satz, auf den an diesem Tag alles hinauslief: Der Patch sei für 16 Uhr deutscher Zeit angekündigt und solle unverzüglich zu diesem Zeitpunkt installiert werden. Bestätigte Ausnutzungen seien noch keine bekannt, unbestätigte Berichte über existierende Exploits dagegen schon.

Kurz vor 16 Uhr · Die Patches kommen, einen Tag früher als geplant

Die PHP Group zieht die Veröffentlichung vor – ursprünglich war der 22. Oktober vorgesehen. Das Advisory trägt den Titel „Security advisory: Critical remote code execution vulnerabilities, update now“. Korrigiert sind vier Versionen:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Damit ist die akute Phase für den größeren Teil der Betreiber vorbei – aber eben nur für den größeren Teil.

17:40 Uhr · Was übrig bleibt

Der Patch beantwortet die Frage „wie komme ich da raus“ für alle, die eine gepflegte PHP-Version fahren. Für alle anderen stellt er sie erst. Darum geht es im Rest dieses Beitrags.

Warum ausgerechnet PHP so viele trifft

PHP ist die Sprache, in der ein großer Teil des Webs läuft. Betroffen sind nach Angaben der PHP Group alle PHP-Installationen, die Webanfragen beantworten – also praktisch jeder Aufbau, der im Einsatz ist: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed.

Was darauf läuft, ist für die Lücke zweitrangig, aber für Sie entscheidend: In der Berichterstattung ausdrücklich genannt werden WordPress, Joomla, Drupal, Magento, phpBB, MediaWiki und Laravel. Diese Aufzählung ist nicht abschließend – sie nennt die verbreitetsten PHP-Anwendungen, nicht die einzigen betroffenen. Wenn Ihre Website auf einem dieser Systeme steht – und das ist bei den allermeisten Unternehmensseiten in Deutschland der Fall –, dann läuft darunter PHP.

Die beiden Lücken sitzen tief im Unterbau, nicht in einem Plugin oder einem Theme:

• CVE-2026-109618 betrifft die Art, wie PHP mit knappem Arbeitsspeicher umgeht. Der Abbruch kann mitten in der Vorbereitung einer Anfrage greifen und halb fertige Daten zurücklassen.
• CVE-2026-109619 betrifft Daten einer Anfrage, die nach dem Freigeben des Speichers liegen bleiben – und von einer späteren Anfrage weiterverwendet werden können.

Für die Praxis heißt das: Kein Plugin-Update der Welt behebt das. Es muss PHP selbst ausgetauscht werden, und das tut der Hoster oder Ihr Administrator, nicht das Redaktionssystem.

Der Punkt, an dem es für viele unangenehm wird

Hier liegt die eigentliche Nachricht, und sie steht in den meisten Meldungen erst weit unten.

Verwundbar ist nach den vorliegenden Angaben jede PHP-Version ab 5.4 – eine Reihe, die bis ins Jahr 2004 zurückreicht. Einen Patch bekommen aber nur die Versionen ab 8.2. Alles darunter – PHP 5.x, 7.x, 8.0 und 8.1 – steht ohne offizielle Korrektur da. Diese Versionen haben ihr Lebensende erreicht und werden nicht mehr gepflegt. Für sie gibt es heute keinen Patch, und es wird auch keinen geben.

Das ist deshalb bitter, weil genau dort viele kleinere Unternehmensseiten stehen. Eine Website, die vor fünf Jahren gebaut und seitdem nicht angefasst wurde, läuft mit hoher Wahrscheinlichkeit auf einer PHP-Version, die niemand mehr aktualisiert hat – oft, weil ein altes Plugin oder ein altes Theme den Sprung nicht mitmacht. Solange nichts passiert, fällt das nicht auf. Heute fällt es auf.

Wie teuer eine alte Seite im Normalbetrieb ist, haben wir in der Rechnung über vier Jahre aufgemacht. Der heutige Tag fügt dieser Rechnung einen Posten hinzu, den man nicht budgetieren kann.

Was Sie jetzt konkret tun

Der Weg hängt davon ab, wer Ihren Server betreut. Drei Fälle, und für alle drei gilt: heute, nicht nächste Woche.

Sie haben ein Hosting-Paket bei einem Anbieter. Das ist der Normalfall für kleine und mittlere Unternehmen. Der Anbieter spielt das PHP-Update ein, meist innerhalb von Stunden. Ihre Aufgabe ist eine andere: nachsehen, welche PHP-Version Ihre Website benutzt. Steht dort 8.2 oder höher, warten Sie das Update des Anbieters ab und prüfen danach nach. Steht dort etwas darunter, haben Sie ein Problem, das nicht von allein weggeht – dann muss die Version angehoben werden, und zwar jetzt.

Sie haben einen eigenen Server oder einen gemieteten virtuellen Server. Dann ist niemand sonst zuständig. PHP auf eine der vier korrigierten Versionen bringen, Dienste neu starten, fertig. Wer eine Version unter 8.2 fährt, kommt um das Anheben nicht herum.

Wir betreuen Ihre Website. Dann ist dieser Tag für Sie im Wesentlichen schon gelaufen – bei uns. Die betroffenen Server in unserem Haus haben wir aktualisiert, sobald die korrigierten Versionen vorlagen.

Danach sind wir nicht der Reihe nach vorgegangen, sondern nach Schadenshöhe. Zuerst die Installationen, die mit sensiblen Daten arbeiten: Dort richtet ein erfolgreicher Zugriff den größten Schaden an, und dort ist die Reihenfolge wichtiger als das Tempo. Diese Seiten haben wir vorgezogen geprüft und, wo nötig, direkt korrigiert. Anschließend alles, wofür wir einen Wartungsauftrag haben.

Kunden, deren Seiten nicht bei uns in der Pflege liegen, haben wir angeschrieben – dort, wo es nötig und angemessen war. Viele sind uns dabei zuvorgekommen und haben von sich aus angerufen. Das hat den Tag turbulent gemacht und war zugleich das Beste daran: Die Meldung war schneller bei unseren Kunden, als wir sie hintragen konnten.

Wenn Sie unsicher sind, ob Ihre Seite dabei war – fragen Sie kurz nach. Das geht schneller, als es selbst herauszufinden.

Wo Sie die PHP-Version ablesen

• WordPress: Werkzeuge → Website-Zustand → Bericht → Server. Dort steht die PHP-Version.
• Hosting-Oberfläche: Bei den gängigen Anbietern gibt es einen Punkt wie „PHP-Version“ oder „PHP-Einstellungen“, meist je Domain einstellbar.
• Im Zweifel: beim Anbieter anfragen. Diese Woche bekommen Sie darauf schnell eine Antwort, die Leitungen sind ohnehin heiß.

Woran Sie erkennen würden, dass etwas passiert ist

Ein erfolgreicher Angriff dieser Art hinterlässt Spuren, aber keine, die ein Besucher sieht. Sicherheitsanbieter nennen als Hinweise: PHP-Prozesse, die plötzlich Unterprozesse starten, die dort nichts zu suchen haben – eine Shell, ein Download-Werkzeug, Befehle, die auskundschaften, auf welchem System man gelandet ist.

Das sind Dinge, die ein Administrator in den Serverprotokollen sucht, nicht Sie in Ihrem Redaktionssystem. Wenn Sie den Verdacht haben, dass Ihre Seite betroffen ist, ist der richtige nächste Schritt nicht das Aufräumen, sondern das Sichern der Protokolle – wer zuerst aufräumt, löscht die Spur, an der sich klären ließe, was passiert ist.

Was Sie nicht tun sollten

Aus den Stunden vor dem Patch kursieren Notbehelfe: bestimmte Anfragetypen blockieren, eine Speichergrenze aufheben, einzelne PHP-Einstellungen abschalten.

Diese Hinweise richteten sich an Administratoren, die abschätzen können, was sie damit auslösen. Eine aufgehobene Speichergrenze zum Beispiel kann dazu führen, dass eine einzelne Anfrage den Server lahmlegt. Seit die Patches draußen sind, sind diese Behelfe überholt – der Patch ist der bessere Weg, und er ist verfügbar. Wer unsicher ist, ändert nichts an der Serverkonfiguration, sondern spielt das Update ein oder lässt es einspielen.

Zwei weitere Dinge, die heute nicht helfen: ein Update der Plugins (die Lücke sitzt tiefer) und das Abwarten darauf, dass sich die Lage beruhigt. Sicherheitsforscher rechneten schon vor der Veröffentlichung damit, dass automatisierte Angriffe sehr schnell nach dem Erscheinen der Patches einsetzen – weil die Korrektur selbst verrät, wo die Lücke saß.

So gehen Sie es durch

Kurz gefasst

Zwei PHP-Lücken erlauben es, fremden Code auf einem Webserver auszuführen – ohne Anmeldung, ohne Zutun des Betreibers, bewertet mit 9.2 von 10. Betroffen ist jede PHP-Installation, die Webanfragen beantwortet, und damit praktisch jede Website auf WordPress, Joomla, Drupal oder Magento. Seit dem Nachmittag des 21. Oktober gibt es Korrekturen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Die wichtigere Frage ist deshalb nicht, ob Sie aktualisieren sollten, sondern ob Sie es überhaupt können. Alles unterhalb von PHP 8.2 bekommt keinen Patch. Wer dort steht, hat heute kein Update-Problem, sondern ein Modernisierungsproblem – und das lässt sich nicht an einem Nachmittag lösen. Sehen Sie nach, welche Version Ihre Website benutzt. Das ist die eine Sache, die heute wirklich dringend ist.