PHP2Shell erklärt: 2 kritische Sicherheitslücken, die das Web beschäftigen

PHP ist seit Jahrzehnten ein Fundament des Webs. TYPO3, WordPress, Drupal, Shopware und unzählige eigene Anwendungen laufen damit. Genau diese Verbreitung macht Lücken in PHP so kritisch.

Am 20. Oktober 2026 kamen 2 schwere Schwachstellen im PHP-Kern ans Licht. Unter dem Namen PHP2Shell sorgen sie seitdem weltweit für Aufsehen. Das PHP-Team hat schnell reagiert und am 21. Oktober kurzfristige Sicherheitsupdates veröffentlicht.

Aber warum ist PHP2Shell so gefährlich? Und wie können 2 Fehler in der Speicherverwaltung dazu führen, dass Angreifer einen Server übernehmen? Schauen wir genauer hin.

PHP2Shell ist der Name, den die Sicherheits-Community 2 kritischen Lücken in PHP gegeben hat. Offiziell tragen sie diese Kennungen:

• CVE-2026-109618: Remote Code Execution durch fehlerhafte Behandlung von Out-of-Memory-Situationen.
• CVE-2026-109619: Remote Code Execution durch veraltete Referenzen auf bereits freigegebenen Speicher.

Beide Lücken erreichen im Common Vulnerability Scoring System (CVSS 4.0) 9,2 von 10 Punkten.

Das Besondere: Die Lücken stecken nicht in deinem CMS, deinem Shopsystem, einer Extension oder deinem eigenen Code. Sie stecken in PHP selbst. Deshalb können auch Anwendungen betroffen sein, die nach allen Regeln der Kunst entwickelt sind.

Unter bestimmten Bedingungen ermöglichen die Lücken eine Remote Code Execution, kurz RCE. Ein Angreifer kann dann über das Netzwerk Code auf einem fremden System ausführen. Je nach Angriffsweg braucht er dafür weder ein Benutzerkonto noch eine Anmeldung. Im schlimmsten Fall übernimmt er die betroffene Anwendung oder die Umgebung, in der sie läuft.

Der Name beschreibt genau dieses Risiko: Ein Angriff auf PHP kann den Weg ebnen, eigene Befehle auf dem Server auszuführen.

Dafür lohnt sich ein Blick darauf, wie PHP arbeitet. Wenn du eine PHP-Website aufrufst, passiert vereinfacht Folgendes:

1. Dein Browser schickt eine HTTP-Anfrage an den Webserver.
2. Der Webserver reicht die Anfrage an PHP weiter.
3. PHP verarbeitet die Anfrage und führt den Code der Anwendung aus.
4. Das Ergebnis geht über den Webserver zurück an deinen Browser.

Bevor deine Anwendung zum Beispiel Inhalte aus der Datenbank lädt, erledigt PHP schon einiges im Hintergrund. Es nimmt die Anfrage entgegen, verwaltet den Speicher, stellt Eingabedaten bereit und richtet interne Zustände ein. Genau hier setzen die PHP2Shell-Lücken an, also eine Ebene unter deinem eigentlichen Code.

Bei manchen Angriffswegen klappt der Angriff sogar, bevor auch nur eine Zeile deines Codes läuft. Ein aktuelles CMS mit aktuellen Extensions allein schützt dich deshalb nicht, solange das PHP darunter verwundbar ist.

Die 1. Lücke betrifft sogenannte Out-of-Memory-Situationen, kurz OOM. Jedes Programm braucht Arbeitsspeicher. Ist das Limit erreicht, muss es kontrolliert reagieren. Genau das klappt bei PHP2Shell nicht immer.

PHP springt bei Speichermangel intern mit longjmp() aus der laufenden Ausführung heraus. Manchmal passiert das aber, während interne Datenstrukturen noch nicht fertig eingerichtet sind. Beim späteren Aufräumen behandelt PHP diese halbfertigen Speicherbereiche dann so, als wären sie gültig. Die Folge: PHP greift auf ungültige Inhalte zu oder trifft Entscheidungen auf ihrer Basis.

Und wie bringt ein Angreifer PHP gezielt an sein Speicherlimit? Die bekannten Angriffe nutzen Schwächen beim Verarbeiten von multipart-Anfragen. Das ist das Format, in dem dein Browser Formulare und Datei-Uploads verschickt. Ein Teil einer solchen Anfrage darf zum Beispiel beliebig viele Header enthalten. Intern braucht PHP dafür deutlich mehr Speicher, als die Anfrage selbst groß ist. Ähnlich wirken leere Datei-Felder, die nicht als Upload zählen, aber trotzdem Speicher belegen. So kann eine Anfrage, die alle Limits wie post_max_size einhält, den Speicher von PHP trotzdem ausreizen.

Wichtig: Es geht nicht um die normale PHP-Fehlermeldung, die du bei einem überschrittenen Memory Limit siehst. Die Lücke steckt in der Fehlerbehandlung der PHP-Engine selbst. Mit dem Update ersetzt PHP den riskanten Sprung durch einen kontrollierten Abbruch.

Die 2. Lücke betrifft globale Zustände und bereits freigegebenen Speicher. Ein PHP-Prozess verarbeitet in seinem Leben oft viele HTTP-Anfragen. Für jede Anfrage legt er Daten im Speicher ab, die danach sauber aufgeräumt werden sollten.

Unter bestimmten Bedingungen bleiben aber Verweise auf Daten bestehen, deren Speicher schon wieder frei ist. Greift PHP später darauf zu, landet es in einem Bereich, der inzwischen für etwas ganz anderes genutzt wird. Dieses Fehlerbild heißt Use-after-free. Vereinfacht gesagt: PHP arbeitet mit Informationen weiter, die längst nicht mehr gültig sind.

Für einen Angriff braucht es 2 Bausteine in 2 Anfragen, die beim selben PHP-Worker landen:

• Der Producer hinterlässt Daten einer Anfrage an einer globalen Stelle. Das passiert, wenn ein fataler Fehler einen Vorgang abbricht, bevor er aufräumen kann. Beispiele sind Parse-Fehler, nicht abgefangene Fehler, ein fehlgeschlagenes require, ein überschrittenes Zeitlimit oder Speichermangel.
• Der Consumer greift bei der nächsten Anfrage auf diese veralteten Daten zu, bevor PHP sie zurücksetzen kann. Bestätigt sind 2 Wege: Warnungen durch ungültige oder veraltete INI-Einstellungen, die schon vor dem Start der Anfrage greifen, etwa per .htaccess. Und der Session Upload Progress, der standardmäßig aktiv ist und kein session_start() braucht.

Kann ein Angreifer zusätzlich steuern, was danach an dieser Stelle im Speicher liegt, kann er den Programmablauf manipulieren. Daraus kann eine Remote Code Execution werden. Übrigens schützt es nicht, Fehlermeldungen auszublenden oder das Logging abzuschalten. PHP greift auf die veralteten Daten zu, bevor es entscheidet, ob es eine Warnung überhaupt anzeigt.

Eine ausgenutzte RCE-Lücke kann ernste Folgen haben:

1. Zugriff auf vertrauliche Daten: Ein Angreifer könnte Konfigurationsdateien, Zugangsdaten zur Datenbank, API-Schlüssel und andere Daten auslesen, auf die der betroffene Prozess Zugriff hat.
2. Manipulierte Websites: Er könnte Inhalte ändern, schädliche Skripte einbinden oder unbemerkte Weiterleitungen einrichten.
3. Schadsoftware: Je nach Rechten könnte er weitere Software installieren und sich dauerhaft Zugang verschaffen.
4. Angriffe auf weitere Systeme: Eine übernommene Anwendung kann als Sprungbrett zu benachbarten Diensten dienen.
5. Ausfälle: Manipulationen oder Abstürze können dazu führen, dass deine Website nicht mehr zuverlässig erreichbar ist.

Wichtig: Eine RCE bedeutet nicht automatisch volle Admin-Rechte auf dem Server. Was ein Angreifer tatsächlich anrichten kann, hängt von den Prozessrechten, der Isolation und weiteren Schutzmaßnahmen ab. Trotzdem gehört eine RCE ohne Anmeldung zu den gefährlichsten Arten von Sicherheitslücken.

Das PHP-Team hat am 21. Oktober 2026 Sicherheitsupdates für diese Versionszweige veröffentlicht:

Ältere PHP-Versionen bekommen vom offiziellen PHP-Projekt keine neuen Sicherheitsreleases. Für viele dieser Zweige gibt es aber PHP LTS. Damit erhalten auch Versionen Sicherheitspatches, die das PHP-Projekt selbst nicht mehr pflegt.

Die Versionsnummer allein verrät deshalb nicht immer, ob eine Installation geschützt ist. Auch Linux-Distributionen und Hosting-Anbieter können Sicherheitskorrekturen per Backport in ältere Pakete einbauen, ohne die Versionsnummer zu ändern. Entscheidend ist also, ob die Korrekturen tatsächlich enthalten sind.

In allen PHP-Umgebungen, die wir für dich betreiben, kümmern wir uns auch um die Sicherheit von PHP selbst. Neben den offiziell gepflegten Versionen setzen wir für ältere Zweige auf PHP LTS. So haben wir die Patches für PHP2Shell für alle Versionen ab PHP 5.6 eingespielt. Läuft dein Projekt auf einer dieser Versionen, ist es bereits geschützt.

Für Versionen älter als PHP 5.6 gibt es keine Sicherheitspatches. Nutzt dein Projekt noch eine solche Version, musst du auf eine aktuelle PHP-Version wechseln.

Betreibst du PHP selbst, zum Beispiel in einem eigenen Container, liegt der Patchstand in deiner Hand. Prüfe ihn bitte gesondert.

PHP lässt sich auf verschiedene Arten mit einem Webserver verbinden, zum Beispiel über Apache mit mod_php, PHP-FPM, PHP-CGI, FrankenPHP oder LiteSpeed. Die Lücken können grundsätzlich alle diese Varianten treffen. Die bekannten Angriffswege und ihre Voraussetzungen unterscheiden sich aber.

Für Apache mit mod_php gibt es einen besonders kritischen, bereits demonstrierten Angriffsweg. Hier reicht eine manipulierte HTTP-Anfrage, noch bevor der Code der Anwendung läuft. Aber auch PHP-FPM ist nicht automatisch sicher. Über den Session Upload Progress ist ein Angriff auch dort bestätigt. Aus der Webserver-Architektur allein solltest du also keine Entwarnung ableiten.

Betreibst oder betreust du PHP-Anwendungen, geh am besten diese Punkte durch:

• PHP-Umgebung klären: Welche PHP-Version läuft tatsächlich? Und wo läuft sie: im Managed Hosting, auf einem eigenen Server oder in einem Container?
• Patchstand prüfen: Ist deine Installation durch eine aktuelle PHP-Version, eine LTS-Version oder einen bestätigten Backport geschützt?
• Alte PHP-Versionen ablösen: Läuft noch eine PHP-Version ohne Support und ohne Patch, solltest du jetzt handeln.
• Kompatibilität testen: Ein Wechsel auf eine neuere PHP-Version kann Anpassungen an deiner Anwendung, an Erweiterungen oder Abhängigkeiten nötig machen. Teste den Umstieg deshalb vorher. Wie du dabei vorgehst, zeigt dir unser [Artikel zum PHP-Update]([LINK ARTIKEL LUKAS]).
• Übergangslösungen kennen: Kannst du selbst betriebenes PHP nicht sofort updaten, nennen die offiziellen Advisories zu CVE-2026-109618 und CVE-2026-109619 Maßnahmen, die das Risiko senken. Ein Update ersetzen sie aber nicht.
• Auf Spuren eines Angriffs achten: Auf selbst verwalteten Systemen können ungewöhnliche Abstürze, auffällige HTTP-Anfragen, veränderte Dateien oder unbekannte Prozesse auf einen Angriff hinweisen. Dann lohnt sich eine genauere Analyse.

Denn ein Update schließt die Lücke, macht aber einen möglicherweise schon erfolgten Angriff nicht ungeschehen.

PHP2Shell zeigt, wie vielschichtig die Sicherheit moderner Webanwendungen ist. Eine Website besteht längst nicht nur aus HTML, CSS und etwas PHP. Dahinter arbeiten Laufzeitumgebungen, Webserver, Datenbanken, Betriebssysteme und Bibliotheken. Jede dieser Ebenen kann Lücken haben.

Sicherheit ist deshalb kein einmaliges Projekt. Sie braucht laufende Pflege, aktuelle Software, ein durchdachtes Konzept und klare Zuständigkeiten. Für Agenturen, Freelancer und Developer heißt das: Nicht nur deine Anwendung muss gepflegt sein, sondern auch die Infrastruktur darunter. Genau deshalb ist ein guter Hosting-Partner mehr als nur der Ort, an dem deine Website liegt.

Du hast Fragen zu PHP2Shell oder zu deinem Projekt? Die Antworten auf die häufigsten Fragen findest du in unserer FAQ Seite zu PHP2Shell. Und wenn du lieber direkt mit uns sprichst: Unser Kundenservice ist für dich da.