← Alle News
ARTIKEL
Gerüchte
23. Oktober 2026 3 Min. Lesezeit
Erstellt von Neska

PHP2Shell-Sicherheitslücke: PHP heute patchen, beide RCE-Lücken schon ausgenutzt

Zwei kritische PHP-Lücken, CVE-2026-109618 und CVE-2026-109619, erlauben Codeausführung ohne Authentifizierung und werden bereits ausgenutzt. Korrigierte Releases erschienen am 21. Oktober.

In diesem Artikel
  1. Was bestätigt ist
  2. PHP2Shell-Sicherheitslücke: Welche PHP-Versionen sicher sind
  3. Was man hört
  4. Warum das wichtig ist
  5. Was heute zu tun ist

Die PHP2Shell-Sicherheitslücke besteht in Wahrheit aus zwei kritischen Schwachstellen in der Programmiersprache PHP, CVE-2026-109618 und CVE-2026-109619, mit denen ein Angreifer ohne Zugangsdaten Code auf einem Webserver ausführen kann. Das PHP-Projekt hat am 21. Oktober 2026 korrigierte Releases veröffentlicht, noch am selben Tag wurden die ersten Angriffe beobachtet. Wer eigene Server oder die eines Kunden mit PHP betreibt, sollte noch heute aktualisieren.

Ein großer Serverraum von oben, mit Reihen von Server-Racks und Schildern für Mail-Server und Webserver.
Foto: Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Was bestätigt ist

Das PHP-Projekt erhielt die ersten Meldungen am 11. August 2026. Amazon Threat Intelligence berichtete am 17. Oktober, vor der öffentlichen Bekanntgabe, von einem Ausnutzungsversuch. Am 20. Oktober sickerten die Details vor dem vereinbarten Termin ins Netz, und PHP zog das Notfall-Release auf den 21. Oktober vor. An diesem Tag beobachtete watchTowr aktive Angriffe in seinem Honeypot-Netzwerk.

CVE-2026-109618 betrifft den Umgang mit Out-of-Memory-Fehlern: Geht PHP beim Aufbau der Anfragedaten der Speicher aus, bleiben diese Daten nur teilweise initialisiert, und die abschließende Bereinigung behandelt sie als gültig. CVE-2026-109619 ist ein Fehler durch nicht zurückgesetzten globalen Zustand, der zu einem Heap-Use-after-free mit Speicherauslese und Codeausführung führt. Beide erlauben Remote-Codeausführung ohne Authentifizierung, mit den Rechten des Webserver-Kontos. Die Advisories der Sicherheitsanbieter bewerten sie mit 9,2 auf CVSS v4.0.

Betroffen ist jede PHP-Installation, die Webanfragen bedient: Apache mit mod_php, PHP-FPM, php-cgi, LiteSpeed und FrankenPHP. Das PHP-Projekt sieht das Risiko bei mod_php am höchsten, weil der Angriff gelingen kann, bevor Anwendungscode läuft. Aus demselben Grund stoppt ihn eine Web Application Firewall oder ein RASP-Agent im PHP-Prozess womöglich nicht.

PHP2Shell-Sicherheitslücke: Welche PHP-Versionen sicher sind

  • PHP 8.5: auf 8.5.12 aktualisieren.
  • PHP 8.4: auf 8.4.27 aktualisieren.
  • PHP 8.3: auf 8.3.36 aktualisieren.
  • PHP 8.2: auf 8.2.35 aktualisieren.
  • PHP 8.1, 8.0 und 7.4: kein offizielles Release. Minimale Backports gibt es nur als Quellcode oder als Pakete von Distributionen und LTS-Anbietern.
  • PHP 7.3 und älter, einschließlich PHP 5: keine Korrektur, der Wechsel auf einen unterstützten Zweig ist nötig.

Linux-Distributionen beheben Schwachstellen oft, ohne die Versionsnummer zu ändern: Deshalb das Changelog des Pakets prüfen, nicht nur die Ausgabe von php -v.

Gerücht

Was man hört

Zum Stand des Exploits widersprechen sich die Quellen. Manche Forscher sagen, die beiden Lücken seien bereits in einem einzigen funktionierenden Skript verkettet, und es gebe öffentliche Analysen sowie ein Tool. Huntress schrieb, man habe keinen Proof of Concept reproduziert, und JFrog warnte, dass gefälschte Exploits kursieren. Wer einen angeblichen PHP2Shell-Exploit aus einem Forum herunterlädt, riskiert, Malware zu installieren.

Laut watchTowr standen die Lücken am 22. Oktober nicht im CISA-KEV-Katalog. Das britische National Cyber Security Centre (NCSC) forderte Organisationen auf, sofort zu aktualisieren oder exponierte Systeme vom Netz zu nehmen. VirusTotal schätzt, dass mehr als 5,1 Millionen PHP-Hosts aus dem Internet erreichbar sind.

Warum das wichtig ist

Wer die IT für ein KMU oder für mehrere Kunden betreut, muss bedenken: PHP steckt nicht nur in selbst geschriebenen Websites. Es steckt in WordPress, Joomla, Magento, PrestaShop, Webmail, alten Fachanwendungen und in jedem Container, dessen Basis-Image PHP enthält. Ein Container behält das PHP, mit dem er gebaut wurde: Er muss neu gebaut oder durch ein korrigiertes Image ersetzt und erneut deployt werden.

Was heute zu tun ist

  1. Bestandsaufnahme: php -v auf jedem Host und docker exec <container> php -v in jedem Container, der PHP ausliefert.
  2. Auf die korrigierte Version oder das korrigierte Paket des Anbieters aktualisieren, danach PHP-FPM oder Apache neu starten.
  3. Wenn sich nicht sofort aktualisieren lässt, das System vom direkten Internetzugang nehmen.
  4. Als Übergangsmaßnahmen, die nicht vollständig schützen: session.upload_progress.enabled=0 mit Neustart der Worker, ein niedriges post_max_size (8M, oder 32M, wenn Uploads nötig sind) und Speicherlimits auf Container-Ebene.
  5. Zugriffslogs ab dem 17. Oktober prüfen und, falls der Verdacht besteht, dass Prozessspeicher ausgelesen wurde, Passwörter, Tokens und API-Schlüssel rotieren.

Das PHP-Projekt stellt klar: Keine Konfiguration entschärft diese Lücken vollständig, und das Update ist die einzige dauerhafte Abwehr. Hilfe bei der Priorisierung und beim schnellen Patchen bieten unsere Cybersecurity-Services.

Quellen: watchTowr, PHP2Shell-FAQ; BleepingComputer; Qualys; JFrog; Huntress.

← ← Alle News