Autor: Omar Alkhateeb

Advisories, Incidents

​​php2shell: Kritische RCE-Schwachstellen in PHP

CVE-2026-109618 & CVE-2026-109619, CVSS 9.2

Stand: 22. Oktober 2026, 12:00 Uhr

​Es wurde eine kritische Sicherheitslücke in PHP entdeckt, die Angreifenden die Ausführung beliebiger Befehle auf jedem Server ermöglicht, auf dem PHP läuft. Als betroffen gemeldet wurden alle Versionen ab einschließlich PHP 5 (also PHP 5.x, 7.x und 8.x). Patches für den 8.x-Zweig wurden wie Tage zuvor angekündigt am 21. Oktober 2026 um 14 Uhr UTC (16 Uhr CEST) bereitgestellt.1 Die Verteilung in Linux-Distributionen erfolgte zeitnah – Patches für Appliances waren später verfügbar (bzw. sind immer noch nicht).  Patches für ältere PHP Versionen folgten bzw. sollten folgen.

​Betroffenheitsanalyse durchführen

​Zuerst sollte zusammengestellt werden, welche Systeme überhaupt betroffen sind bzw. betroffen sein könnten.

  • ​Vollständige Inventarisierung aller Systeme und Anwendungen, die PHP verwenden.
    Dies betrifft auch „Appliances“ mit Weboberflächen wie bspw. Firewalls, NAS-Systeme, …
  • Ermittlung und Dokumentation der jeweiligen Server/Appliances und der exakten darauf verwendeten PHP-Versionen
  • Priorisierung derjenigen Instanzen, die aus dem Internet oder öffentlichen Netzen erreichbar sind.
  • Triage der Instanzen hinsichtlich der Möglichkeit eines zeitnahen Patches – nicht warten bis alle „wichtigen“ Systeme einen Patch verfügbar haben, sondern bei noch ausstehender Lieferung alles weitere in der Liste patchen, sobald Patches verfügbar sind.
  • CVE-2026-109618 kann NICHT ausgenutzt werden, wenn in der php.ini die Parameter wie folgt gewählt sind:
memory_limit < 4x post_max_size

was in der Standardeinstellung leider verletzt wird (128MB < 4x 8MB).
Die Einstellungen kann man prüfen mit Shell-Befehl:

php -i | grep -E "^(memory_limit|post_max_size)"

​Sofortmaßnahmen zur Mitigation ergreifen

Bis Patches verfügbar und eingespielt sind, sollten Systeme und Schwachstellen provisorisch abgesichert werden:

Generell:

  • Durch Firewalls Wegsperren von nicht betriebsnotwendigen aber aus öffentlichen Netzen erreichbaren Weboberflächen, insbesondere Administrationsoberflächen (z. B. von Routern, NAS-Systemen, sogar Firewalls selbst)2

Für aktualisierbare Systeme und Anwendungen:

  • Durchführung von Update-Tests in einer Staging-Umgebung, dann zeitnahes Einspielen der offiziellen PHP-Sicherheitsupdates, Neustart der betroffenen Dienste, Funktionskontrolle des Dienstes
  • Verifizierung der aktualisierten Versionsnummern auf allen Instanzen
  • Kontrolle der Systemintegrität auf Anzeichen einer Kompromittierung (siehe späterer Abschnitt)

Für nicht-aktualisierbare Systeme und Anwendungen (Workarounds):

  • Organisatorische Vorbereitung auf Installation von Patches
  • Implementierung von WAF- bzw. Webserver-Regeln zur Blockierung verdächtiger Requests (siehe letzer Abschnitt). Dies kann allerdings zu Einschränkungen der Funktionalität führen, insbesondere bei Upload von Bildern oder Dokumenten.
  • Einschränkung des Netzwerkzugriffs via Firewall auf bekannte IPs und Ports, beispielsweise beim Mailserver SMTP(S), Submission und IMAPS weiter erlauben, aber HTTPS-Zugriff auf den Webmailer sperren.
  • Evaluation der Trennung oder Abschaltung betroffener Instanzen
  • In der php.ini gefährliche PHP-Funktionen (z. B. exec(), system() oder popen() ) deaktivieren, die häufig für Remote-Code-Executions verwendet werden.
    Dies verhindert zwar nicht die Ausnutzung der Schwachstellen, erschwert einem Angreifer aber die weiter Ausnutzung nach einem erfolgreichen Eindringen
  • Erstellung von VM-Snapshots zur Detektion von Änderungen am System – und zur schnellen Wiederherstellung im Falle eines Falles
  • Erhöhung des Log-Levels und Senden der Logs an einen zentralen Logserver/SIEM
  • Überwachung der Server-Logs auf ungewöhnliche Prozessstarts
  • Härtung der Dateisystemberechtigungen für den Webserver-User – der Webserver sollte keinesfalls unter Root laufen.

Schwachstelle schließen

Sobald verfügbar, sollten die Patches zeitnah eingespielt werden, die die Lücken schließen. Anschließend können die oben Workarounds wieder weitgehend zurückgenommen werden.

Zusätzlich empfiehlt sich die Beachtung folgender weiterer Maßnahmen:

  • Beibehalten der Zugriffseinschränkungen auf Hochrisiko-Webinterfaces (Firewalls, Router, etc.). Diese sollten weiterhin nur von sehr wenigen, einzeln benannten IP-Adressen aus erreichbar sein.
  • Migration von alten PHP-Versionen und EOL-Versionen auf eine aktuell unterstützte Version (PHP 8.2 oder höher)
  • Beobachten der Hersteller-Nachrichten der Distributionen, Anwendungen, Appliances, da es zu Folge-Funden von Schwachstellen kommen könnte. Wir beobachten die Lage laufend.

Bei verspäteten Maßnahmen: Kontrolle auf erfolgreiche Angriffe

Angreifende die durch die Schwachstelle kommen, erhalten die Rechte des Nutzers des PHP-Prozesses, also des Webservers oder des PHP-FPM, also meist http, www-data, www o.ä. – manchmal aber leider auch root.

Leider ist bei einem erfolgreichen Angriff die Spurenlage meist dünn. Dennoch sollten folgende Punkte überprüft werden:

  • Im $HOME-Verzeichnis des Nutzers nach ungewöhnlichen oder frisch geänderten Dateien History suchen.
  • Dort auch .history / .bash_history des Nutzers prüfen.
  • Den Webserver-Bereich auf PHP-Dateien prüfen, die seit gestern 21.10.2026  14:00 UTC / 16:00 MESZ angelegt oder modifiziert wurden.
  • Die journald-Ausgaben sowie error.log der Webserver auf ungewöhnliche Fehlermeldungen prüfen, insbesondere solche, die Speicherfehler (Memory exhausted u. ä. ) melden, insbesondere
    • Allowed memory size of ... exhausted
    • Unknown on line 0
    • Failed to decode session object
  • Prozessliste prüfen: haben Webserver oder PHP-Prozesse ungewöhnliche Child-Prozesse?
  • Auf ungewöhnliche Listener-Ports prüfen (netstat -tlpn oder ss -tlpn)

Mitigation: Filter auf Webservern

Die Angriffe sind möglich, sobald der PHP-Prozessor angesprochen wird. Welche Funktionen in der jeweiligen PHP-Seite verarbeitet werden sollen, ist dabei irrelevant.

Üblicherweise werden PHP-Seiten über einen Webserver wie Apache oder Lighttpd als Modul oder FCGI / PHP-FPM aufgerufen. Wenn der Zugriff auf entsprechende Funktionen bereits auf dem Webserver gesperrt ist, dann erreicht der Angriff nie den PHP-Prozessor.

Dieser Filter kann allerdings zu Einschränkungen der Funktionalität führen, insbesondere bei Upload von Bildern oder Dokumenten.

Filter in Lighttpd:

Der folgende Filter sollte an die entsprechende Strelle der Konfiguration des lighttpd-Webservers eingefügt werden:

$REQUEST_HEADER["Content-Type"] =~ "multipart" {

url.access-deny = ( "" )

}

Filter für Apache 2.4

Dieser Filter kann in der Konfiguration, aber oft auch in .htaccess-Dateien gesetzt werden:

<If "req('Content-Type') =~ /multipart/i">Require all denied</If>