PHP2Shell erklärt: CVE-2026-109618 und CVE-2026-109619

Stand: 22.10.2026, 00:23 Uhr MESZ. Die Sicherheitsupdates sind verfügbar. Dieser Artikel erklärt beide Fehlerklassen anhand der öffentlichen PHP-Advisories und Forschungsberichte. Paketstände und unsere Reaktion im Betrieb dokumentiert die Analyse zu PHP2Shell.

Eine PHP-Anfrage schlägt fehl, ihr Speicher wird freigegeben, der Webserver arbeitet weiter. So soll Fehlerbehandlung funktionieren. Bei PHP2Shell kann PHP dabei internen Zustand zurücklassen, dem es später weiter vertraut. Aus einem abgebrochenen Request kann so ein Speicherfehler entstehen, der Codeausführung ermöglicht.

Das betrifft die PHP-Laufzeit unter deiner Anwendung. Ein aktuelles WordPress und sauber geschriebener Anwendungscode ersetzen deshalb kein PHP-Update.

Kurzfassung

• Was ist PHP2Shell? Der Name umfasst mehrere Speicherfehler, die unter CVE-2026-109618 und CVE-2026-109619 behoben werden. Beide sind mit CVSS v4.0 von 9,2 bewertet.
• Was kann passieren? Codeausführung ohne Anmeldung im Kontext des Web-Workers. Forschungsberichte zeigen außerdem das Auslesen von Prozessspeicher. Root-Rechte sind damit nicht automatisch verbunden.
• Ist FPM sicher? Nein. Der Ablauf unterscheidet sich von Apache mit mod_php; für FPM gibt es ebenfalls bestätigte Angriffswege.
• Was behebt die Lücken? PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 beziehungsweise ein ausdrücklich bestätigter Hersteller-Backport für beide CVEs. Die laufenden Prozesse müssen den Fix verwenden.

Quelle für Bewertung, Reichweite und Release: PHP Security Team, 21. Oktober 2026. Dieser Artikel erklärt die Fehler. Die Patchlisten für Plesk, Distributionen, Container und Appliances bleiben in der Analyse, mit den jeweiligen Prüfzeiten.

Zwei CVEs, zwei Fehlerklassen

Die offiziellen PHP-Advisories unterscheiden danach, wie ungültiger Zustand entsteht und später verwendet wird:

CVE	Fehlerklasse	Was dabei schiefgeht
CVE-2026-109618	OOM corruption	Speichermangel unterbricht einen internen Arbeitsschritt. Beim Aufräumen verarbeitet PHP einen noch ungültigen Zustand.
CVE-2026-109619	Stale global state	Ein Worker behält Verweise auf bereits freigegebenen Request-Speicher. Eine spätere Anfrage verwendet sie, bevor die normale Initialisierung sie zurücksetzt.

Die Mechanismen können zusammenkommen: Ein Speicherfehler kann die Bereinigung abbrechen und damit veraltete Verweise hinterlassen. Zwei CVE-Nummern bedeuten hier deshalb nicht zwei isolierte Funktionen, die man unabhängig abschaltet.

Zur Quellenzuordnung: Wiz gruppiert seine Demonstrationen teilweise anders. Für die Kapitel verwenden wir die Zuordnung des PHP-Projekts, das den Session-Upload-Lifecycle ausdrücklich bei CVE-2026-109619 beschreibt. Warum die Zuordnungen voneinander abweichen, geht aus den Veröffentlichungen nicht eindeutig hervor. Quellen: PHP zu CVE-2026-109618, PHP zu CVE-2026-109619.

Warum eine Anfrage schon vor deinem PHP-Code gefährlich sein kann

PHP muss eine HTTP-Anfrage vorbereiten, bevor dein Skript läuft. Dazu gehört das Einlesen von Formulardaten. Auch die sessionbasierte Upload-Fortschrittsanzeige kann zu diesem Zeitpunkt aktiv werden. Das PHP-Handbuch dokumentiert ausdrücklich, dass diese Informationen vor der Skriptausführung in die Session geschrieben werden.

Ein Login-Check am Anfang der Anwendung kommt für solche Vorgänge zu spät. Dass deine Anwendung selbst keinen Upload anbietet oder kein session_start() aufruft, genügt ebenfalls nicht als Nachweis, dass PHP den betreffenden Verarbeitungspfad nie erreicht.

Für die folgenden Fehler ist außerdem die Lebensdauer wichtig: Eine Anfrage endet, der Worker kann aber weiterlaufen und die nächste Anfrage bedienen. PHP muss an dieser Grenze alle Verweise auf den Speicher der beendeten Anfrage korrekt bereinigen.

CVE-2026-109618: Wenn Speichermangel das Aufräumen unsicher macht

Out of memory, kurz OOM, muss nicht bedeuten, dass der ganze Server keinen RAM mehr hat. Schon das Erreichen von PHPs eigenem memory_limit kann einen Request abbrechen.

Das PHP-Advisory beschreibt einen abrupten Sprung aus dem aktuellen Ablauf über longjmp(). Zu diesem Zeitpunkt kann eine interne Datenstruktur bereits erreichbar sein, obwohl PHP sie noch nicht fertig aufgebaut hat. Die anschließende Bereinigung behandelt sie trotzdem als gültig. So wird aus dem kontrollierten Abbruch ein Speicherfehler. Offizielles OOM-Advisory.

Calif zeigt das am Aufbau einer internen Tabelle: PHP zählt einen neuen Eintrag schon mit, bevor alle seine Werte initialisiert sind. Scheitert eine Speicheranforderung dazwischen, kann das Aufräumen auf den unfertigen Eintrag zugreifen. Entscheidend ist also die Reihenfolge von Sichtbarkeit, Initialisierung und Bereinigung. Eine kleinere erlaubte Upload-Datei löst dieses Problem nicht grundsätzlich; intern erzeugte Datenstrukturen können mehr Speicher brauchen als die übertragene Anfrage. Quelle: Calif, Abschnitt „But what does an OOM buy you, really?“.

Der Fix verändert die OOM-Behandlung: Ein weicher Abbruch erfolgt an einem sicheren Ausführungspunkt; eine höhere harte Grenze kann den Prozess unmittelbar beenden. So soll die normale Bereinigung keinen halbfertigen Zustand mehr verarbeiten. Quelle: PHP-Fix für beide CVEs.

CVE-2026-109619: Wenn eine Anfrage Speicherreste der vorherigen verwendet

Hier überlebt ein Verweis die Daten, auf die er zeigt. PHP gibt den Request-Speicher frei, aber der Worker behält an anderer Stelle eine alte Referenz darauf. Wird dieselbe Speicheradresse später neu belegt, zeigt die Referenz nicht mehr auf das ursprüngliche Objekt. Ein Zugriff darüber heißt Use-after-free.

Das PHP-Advisory beschreibt zwei notwendige Teile: einen Vorgang, der solchen Zustand hinterlässt, und einen späteren Vorgang, der ihn vor dem normalen Zurücksetzen verwendet. Ein fataler Fehler kann die Bereinigung unterbrechen. Session Upload Progress ist ein bestätigter Weg, über den der nächste Request zu früh auf zurückgebliebenen Session- oder Decoderzustand zugreift. Quelle: PHP-Advisory zu CVE-2026-109619.

Ein weiteres bestätigtes Beispiel betrifft den Fatal-Error-Backtrace in PHP 8.5: die intern gespeicherte Aufrufhistorie eines fatalen Fehlers. Sie kann länger erhalten bleiben als der dazugehörige Speicher. Der gemeinsame Patch bereinigt solche Zustände umfassender. Er beschränkt sich nicht auf die Upload-Fortschrittsanzeige. Quellen: PHP-Advisory, Änderungen an Fehlerbehandlung und globalem Zustand.

Was die Demonstrationen von Wiz zusätzlich zeigen

Wiz Research berichtet von Codeausführung ohne Anmeldung gegen WordPress, Drupal und Joomla. Die erste Originalabbildung zeigt diese nachgewiesenen Auswirkungen. Die Anwendungen waren Demonstrationsziele; der Fehler liegt in PHP selbst.

Die zweite Abbildung zeigt einen anderen nachgewiesenen Effekt: das Auslesen von Worker-Speicher. Darin können Zugangsdaten, Tokens oder API-Schlüssel liegen. Im beschriebenen Session-Fall gelangten Speicherinhalte über ein Session-Cookie in die HTTP-Antwort. Dafür musste der Angreifer noch keinen eigenen Befehl auf dem Server ausführen.

Die Abbildungen stellen Auswirkungen dar. Sie zeigen weder sämtliche internen Schritte noch jeweils genau eine der beiden CVEs.

Wiz beschreibt außerdem einen OPcache-Fall: Inkonsistente Verwaltungsdaten lassen einen Worker einen Speicherverweis als falschen Objekttyp interpretieren. Das betrifft gemeinsam verwendeten Zustand über Worker hinweg und unterscheidet sich vom oben beschriebenen Request-Lifecycle im selben Worker.

Wir haben diese Demonstrationen nicht selbst reproduziert. Unsere Erklärung stützt sich auf die öffentlichen Forschungsberichte, die PHP-Advisories und den veröffentlichten Fix.

Apache mit mod_php und PHP-FPM: Wo liegt der Unterschied?

Calif zeigt den entscheidenden Unterschied beim fehlgeschlagenen Requeststart: mod_php führt anschließend noch Request-Cleanup aus. FPM beendet dagegen den betroffenen Worker. Damit entfällt bei FPM genau dieser Weg, bei dem der beschädigte Startzustand später weiterverwendet wird. Nach erfolgreichem Start kann ein Fehler während der Anwendungsausführung jedoch anders behandelt werden; der Worker kann für weitere Anfragen erhalten bleiben. Calif: Erklärung und FPM-Demonstration.

Daraus ergibt sich eine wichtige Grenze der Belege: Das OOM-Advisory zu 109618 nennt keinen vollständig demonstrierten FPM-Exploit. Das Advisory zu 109619 beschreibt dagegen einen validierten FPM-Angriffsweg über zurückgebliebenen Decoderzustand. Dieser benötigt eine passende Anwendungsoperation. „Ohne Anmeldung“ bedeutet also nicht bei jeder Variante „ohne Beteiligung der Anwendung“. PHP: OOM, PHP: stale global state.

Ein Wechsel von mod_php zu FPM ersetzt das Update nicht. PHPs Sicherheitsmeldung schließt auch CGI, FrankenPHP und LiteSpeed in ihre Warnung für webverarbeitende Installationen ein.

Warum der INI-Workaround nicht beide Fehler behebt

session.upload_progress.enabled = Off

Diese Einstellung deaktiviert PHPs sessionbasierte Upload-Fortschrittserfassung. Normale Datei-Uploads bleiben grundsätzlich möglich; Anwendungen, die diese spezielle Fortschrittsfunktion nutzen, verlieren sie. Quelle: PHP Session-Konfiguration.

Damit wird ein beteiligter Verarbeitungspfad abgeschaltet. Die Fehlerbehandlung bei Speichermangel und andere langlebige Zustände werden dadurch aber nicht korrigiert. Die offizielle Empfehlung bleibt das Sicherheitsupdate. PHP-Sicherheitsmeldung.

Aus den beschriebenen Fehlerklassen folgt auch: Eine Sperre für einen bestimmten Session-Cookie-Namen ist kein allgemeiner Fix. Gleiches gilt für das Abschalten von Sessions insgesamt. Das würde viele Anmeldungen und Warenkörbe beeinträchtigen, ohne die übrigen Fehlerklassen zu beseitigen. Eine Multipart-Sperre vor PHP kann erreichbare Wege einschränken, deckt aber nicht jede anwendungsabhängige Fehlerursache ab.

Die konkrete Einrichtung des Workarounds und seine Grenzen stehen in unserer Plesk-Anleitung innerhalb der Analyse. Wenn kein bestätigtes Update verfügbar ist, bleibt für sensible Anwendungen eine Zugriffsbeschränkung vor PHP oder eine vorübergehende Abschaltung abzuwägen.

Welche Versionen sind betroffen, und was prüfe ich jetzt?

Für die gepflegten Upstream-Linien nennt PHP folgende Grenzen:

PHP-Linie	Verwundbarer Stand in dieser Linie	Sicherheitsrelease
8.2	vor 8.2.35	8.2.35
8.3	vor 8.3.36	8.3.36
8.4	vor 8.4.27	8.4.27
8.5	vor 8.5.12	8.5.12

Quelle: PHP-Sicherheitsrelease. Ältere Linien sind dadurch nicht ausgenommen. Calif beschreibt betroffene Pfade bis zurück zu PHP 5.4.0; daraus folgt nicht, dass jede Variante in jeder alten Version identisch funktioniert. Für alte Installationen brauchst du einen bestätigten Backport deines Anbieters oder den Wechsel auf eine gepflegte Linie.

Eine rein statische Website, deren Auslieferung kein PHP aufruft, hat diesen PHP-Angriffsweg nicht. Ein PHP-basiertes Verwaltungsportal oder Webmail auf demselben Server muss trotzdem separat geprüft werden.

Für den eigenen Bestand gehen wir so vor:

1. Laufzeiten zuordnen. Welche PHP-Version bedient welche Domain? Welche steckt im Panel, im Webmail oder im Container? php -v zeigt nur das aufgerufene CLI-Binary.
2. Fix nachweisen. Vollständige Paketversion oder Image-Digest mit der Herstellerfreigabe für beide CVEs abgleichen. Bei Backports kann die sichtbare PHP-Basisversion älter bleiben.
3. Laufende Prozesse ersetzen. Die betroffenen Dienste kontrolliert neu starten beziehungsweise Container aus dem bestätigten Image neu erstellen. Ein heruntergeladenes Image aktualisiert keinen laufenden Container.
4. Betrieb prüfen. Tatsächlichen Web-Handler, Anmeldung, Uploads, Hintergrundaufgaben und Fehlerlogs kontrollieren. Ein HTTP 200 allein sagt nichts über den verwendeten PHP-Code aus.

Diese Trennung ist gerade bei Plesk wichtig: Ein Update der Website-Handler belegt noch keinen Fix der Panel-Laufzeit sw-engine. Den jeweils geprüften Lieferstand führen wir in der Plesk-Patchliste.

Einordnung für Hosting und Anwendungen mit Kundendaten

Ein kompromittierter Web-Worker kann die Rechte seiner Anwendung nutzen. Für einen Shop kann schon der Zugriff auf seine Datenbankzugangsdaten oder Kundendaten erheblichen Schaden bedeuten. Dafür braucht der Angreifer keine Root-Shell. Getrennte Benutzer, eng begrenzte Datenbankrechte und eingeschränkter Netzwerkzugriff begrenzen den möglichen Schaden; sie reparieren den PHP-Fehler nicht.

Umgekehrt beweist die bloße Verbreitung von PHP keinen größeren tatsächlichen Schaden als bei Log4Shell. Dafür fehlen zum Redaktionsstand belastbare Vergleichszahlen zur Ausnutzung. Unsere Priorität richtet sich nach erreichbarer Laufzeit, Datenzugriff und nachgewiesenem Fix.

Wie wir bei Nerdscave Hosting reagiert haben, welche Dienste wir vorsorglich abgeschaltet haben und wann welche Updates überprüfbar waren, bleibt in der Analyse mit Betriebsverlauf und Update-Log. Dieser Verlauf gehört zur Einordnung: Zwischen einem Upstream-Patch und einem korrigierten, laufenden Dienst liegen mehrere Schritte.

Wie die Veröffentlichung vorbereitet wurde

Wiz nennt für seine eigene Recherche folgende Stationen:

Datum 2026	Laut Wiz
19. August	Erster Fund
20./21. August	RCE gegen Drupal beziehungsweise WordPress bestätigt
24. August	Meldung an das PHP-Sicherheitsteam
21. September	Bestätigung und Beginn der koordinierten Fehlerbehebung
21. Oktober	Sicherheitsreleases und öffentliche Offenlegung

Quelle: Disclosure-Zeitleiste von Wiz Research. Das ist Wiz’ eigener Verlauf, nicht die vollständige Entdeckungsgeschichte. Calif dokumentiert frühere eigene Funde und eine erste Meldung am 11. August. OpenAI beschreibt die unabhängigen Forschungen und die gemeinsame Abstimmung mit PHP und Infrastruktur-Anbietern.

Die Forscher beschreiben KI-Unterstützung bei Suche, Exploit-Entwicklung und Prüfung. Die Sicherheitsreleases verantwortete das PHP-Team. Für Betreiber bleibt die praktische Arbeit dieselbe: Abhängigkeiten erfassen, Updates zuordnen und ihre Wirksamkeit im laufenden Betrieb prüfen.

Update-Log

• 21.10.2026, 05:05 Uhr MESZ: Internen Entwurf angelegt und die spätere URL als Titelseite vorbereitet. Der technische Inhalt blieb unveröffentlicht.

• 21.10.2026, 20:45 Uhr MESZ: Entwurf anhand der inzwischen öffentlichen PHP-Advisories, des Fixes und der Berichte von Wiz und Calif neu geschrieben. Beide Fehlerklassen getrennt erklärt, FPM-Abgrenzung und eigene Schaubilder ergänzt. Paketstände und Betriebschronik bleiben in der Analyse.

• 21.10.2026, 21:48 Uhr MESZ: Erklärartikel veröffentlicht. Quellenstand erneut geprüft; eigene Schaubilder mit Quellenangaben über die Website eingebunden.

• 22.10.2026, 00:23 Uhr MESZ: Eigene Schaubilder durch die unveränderten Originalabbildungen von Wiz Research ersetzt. Bildunterschriften und Zuordnung zu den dargestellten Auswirkungen überarbeitet; Quellen direkt an den Bildern ergänzt.

Quellen

• PHP Security Team: Sicherheitsrelease vom 21. Oktober 2026
• PHP: CVE-2026-109618, RCE via OOM corruption
• PHP: CVE-2026-109619, RCE via stale global state
• PHP: gemeinsamer Fix für beide CVEs
• Wiz Research: PHP2Shell
• Calif Research: A tale of two PHP remote vulnerabilities
• PHP-Handbuch: Session Upload Progress
• PHP-Handbuch: Session-Konfiguration
• OpenAI: Koordination der PHP-Sicherheitsupdates

Die beiden Abbildungen stammen von Wiz Research und werden unverändert mit Quellenangabe über unser CDN ausgeliefert. Beim Lesen werden dafür keine Ressourcen von Wiz oder dessen Bildhoster geladen. Die Quellenlinks führen erst beim Anklicken zu den Originalen.