Notfall-Patch! PHP2Shell ermöglicht Remote Code Execution auf PHP-Servern

Laufende Entwicklung ●

Status: In Bewegung. Dieser Beitrag wurde zuletzt am 28. Oktober 2026 um 09:19 UTC aktualisiert. Wir ergänzen ihn, sobald neue Informationen vorliegen.

PHP hat Patches für zwei kritische Schwachstellen veröffentlicht, CVE-2026-109618 und CVE-2026-109619, von Sicherheitsforschenden PHP2Shell genannt. Jede unterstützte PHP-Installation sollte unverzüglich aktualisiert werden. Laut PHP können beide Schwachstellen eine nicht authentifizierte Remote Code Execution ermöglichen, und das PHP-Sicherheitsteam bewertet beide mit CVSS v4.0 9,2. Die behobenen Versionen, am 21. Oktober 2026 veröffentlicht, sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter haben ihr End of Life erreicht und erhalten offiziell keine Updates mehr, auch wenn das Sicherheitsteam von PHP minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht hat. Die Ausnutzungsversuche haben bereits begonnen: Amazon meldet seit dem 17. Oktober, vier Tage vor der Offenlegung, Versuche gegen seine Honeypots, und öffentliche Proofs of Concept sind im Umlauf. Die CISA hat beide CVEs am 26. Oktober 2026 in ihren KEV-Katalog aufgenommen (CVE-2026-109618, CVE-2026-109619). Eine frühere kritische PHP-Schwachstelle, CVE-2024-4577, zog innerhalb eines Tages Exploit-Versuche nach sich; diesmal kamen sie noch vor dem Patch.

Die unterstützten Zweige zu aktualisieren, ist der einfache Teil. Schwieriger ist es, jede PHP-Installation in Ihrem Netzwerk zu finden, auch die, die von außen nicht sichtbar sind, und die, die das PHP-Projekt nicht mehr aktualisiert. CERT-EU und das deutsche BSI haben zu beiden Schwachstellen Advisories veröffentlicht [1][2].

Jetzt auf PHP2Shell scannen, 14 Tage kostenlos →

Was PHP2Shell für End-of-Life-PHP bedeutet

PHP unterstützt derzeit vier Zweige: 8.2 und 8.3 erhalten nur noch Sicherheitsupdates, während 8.4 und 8.5 im aktiven Support sind. Der Sicherheitssupport für PHP 8.2 endet am 31. Dezember 2026. Jeder ältere Zweig hat sein End of Life erreicht: PHP 8.1 seit dem 31. Dezember 2025, PHP 8.0 seit dem 26. November 2023, PHP 7.4 seit dem 28. November 2022 und PHP 5.6 seit dem 31. Dezember 2018. Laut den Advisories von PHP ist jede Version unterhalb von 8.2.35 betroffen [3][4]. Für End-of-Life-Zweige verweist PHP auf Distributionen und LTS-Anbieter, die Korrekturen per Backport bereitstellen, und das Sicherheitsteam hat minimale Quellcode-Backports für PHP 7.4, PHP 8.0 und PHP 8.1 veröffentlicht, für alle, die aus dem Quellcode bauen. Ältere Zweige wie PHP 5.6 erhalten beides nicht. Bevor Sie diese Systeme beheben können, müssen Sie wissen, wo sie laufen.

Im Internet ist noch sehr viel altes PHP im Einsatz. Laut Mallorys Zählung von Shodan-Bannern vom 20. Oktober 2026 melden rund 884.000 aus dem Internet erreichbare Hosts eine End-of-Life-PHP-Version, das sind 59 % der rund 1,5 Millionen Hosts, die überhaupt eine Version anzeigen. Weitere rund 740.000 geben ihre Version nicht preis. Dabei handelt es sich um Banner-Zählungen, nicht um bestätigt betroffene Systeme.

Ein verborgenes Versionsbanner bedeutet nicht, dass dahinter kein PHP läuft. PHP steckt auch in Control Panels wie cPanel und Plesk, Content-Management-Systemen und Herstellersoftware, wo es nach fremdem Zeitplan aktualisiert wird, oder gar nicht.

Eine Risikoeinschätzung zu PHP2Shell

Informationen zu beiden Schwachstellen sind vor der geplanten koordinierten Offenlegung durchgesickert [5]. Amazon, das am 17. Oktober einen ersten Versuch beobachtete, und watchTowr melden Ausnutzungsversuche gegen beide Schwachstellen. Das neuseeländische NCSC gibt an, dass ihm Berichte über eine aktive Ausnutzung bekannt sind. Am 26. Oktober 2026 hat die CISA beide CVEs in ihren Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen: CVE-2026-109618, CVE-2026-109619. Die Warnung des BSI vom 22. Oktober 2026 nennt keine bestätigte Ausnutzung. Die Schwachstellen sind aber in der Praxis ausnutzbar: Laut dem Advisory von PHP wurde eine nicht authentifizierte Remote Code Execution über HTTP gegen mod_php validiert, und zwar mit Standard-Eingabe- und Speicherlimits.

PHP-Schwachstellen wurden schon früher sehr schnell angegriffen. Als die kritische PHP-Schwachstelle CVE-2024-4577 im Juni 2024 bekannt wurde, beobachtete Akamai die ersten Exploit-Versuche gegen seine Honeypots bereits innerhalb eines Tages.

Technische Details zu CVE-2026-109618 und CVE-2026-109619 in PHP

PHP sieht alle PHP-Installationen, die Webanfragen bearbeiten, als gefährdet an, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko stuft PHP bei mod_php am höchsten ein, wo eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft. Beide Advisories nennen Use-after-free [CWE-416] unter den Schwächen, und das ChangeLog verzeichnet beide unter einer einzigen Korrektur im PHP-Kern („Avoid state corruption via bailout“).

Die zwei CVEs, die in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben sind, jeweils mit CVSS-Schweregrad und EPSS-Ausnutzungswahrscheinlichkeit

CVE-2026-109618

CVSS 9,2 · Kritisch EPSS 100,0 % (100.)

RCE durch OOM-Korruption (GHSA-w8hw-w9fx-j79w): Wenn PHP der Arbeitsspeicher ausgeht, während interne Anfragedaten erst teilweise initialisiert sind, kann die Bereinigung der Anfrage die ungültigen Daten als gültig behandeln.

CVE-2026-109619

CVSS 9,2 · Kritisch EPSS 100,0 % (100.)

RCE durch veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp): Interner Zustand, der zu einer Anfrage gehört, kann in einem dauerhaft laufenden Worker bestehen bleiben, nachdem sein Speicher freigegeben wurde, und eine spätere Anfrage, die derselbe Worker bearbeitet, kann ihn verwenden.

Die Advisories von PHP enthalten alle technischen Details [6][7].

Betroffene Versionen und Gegenmaßnahmen für CVE-2026-109618 und CVE-2026-109619 in PHP

Aktualisieren Sie jede unterstützte PHP-Installation auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wenn Sie einen End-of-Life-Zweig betreiben, steigen Sie auf einen unterstützten Zweig um. Da der Sicherheitssupport für PHP 8.2 am 31. Dezember 2026 endet, ist PHP 8.4 oder 8.5 das bessere Ziel. Wenn Sie noch nicht umsteigen können, prüfen Sie, ob Ihre Distribution oder Ihr LTS-Anbieter eine Korrektur per Backport bereitstellt, oder bauen Sie aus den Quellcode-Backports von PHP für 7.4, 8.0 und 8.1.

Wenn Sie nicht unverzüglich aktualisieren können, nennt PHP Konfigurationsänderungen, die das Risiko für bestimmte Angriffspfade verringern, zum Beispiel das Erzwingen von memory_limit=-1 gegen CVE-2026-109618 und das Setzen von session.upload_progress.enabled=0 gegen CVE-2026-109619. PHP stellt klar, dass diese Maßnahmen eine Installation nicht sicher machen und dass nur das Update vollständig schützt. Die Einstellung zu session.upload_progress verhindert einzelne Angriffswege, aber nicht alle. Insbesondere schützt sie nicht vor CVE-2026-109618. Bei CVE-2026-109619 greift sie nur, wenn sie serverseitig vor der Verarbeitung der Anfrage gesetzt und anschließend die Worker neu gestartet werden. Ein ini_set() in der Anwendung kommt dafür zu spät. Behandeln Sie Konfigurationsänderungen deshalb höchstens als zusätzliche Maßnahme, nicht als Ersatz für das Update. CERT-EU empfiehlt zusätzlich, internetexponierte Anwendungen von öffentlichen Netzen zu isolieren, bis der Patch eingespielt ist. Die CISA geht noch weiter: Organisationen, die nicht unverzüglich aktualisieren können oder noch PHP 8.1 oder älter betreiben, sollten PHP-basierte Systeme vom Netz nehmen, bis sie gepatcht oder aktualisiert sind.

Linux-Distributionen übernehmen Korrekturen manchmal per Backport in ihre eigenen PHP-Pakete, ohne die Versionsnummer zu ändern. Laut PHP haben Distributionen und LTS-Anbieter die Patches vorab erhalten, prüfen Sie daher bei Ihrem Anbieter, ob aktualisierte Pakete vorliegen. Debian, Red Hat und Ubuntu haben bereits korrigierte Pakete veröffentlicht, auch für Zweige, die PHP nicht mehr unterstützt, etwa PHP 7.4 und 8.0 unter Red Hat Enterprise Linux 8 und 9 [8][9][10][11]. Bei PHP, das mit Control Panels, Content-Management-Systemen oder Appliances mitgeliefert wird, fragen Sie den jeweiligen Hersteller. Das niederländische NCSC führt eine Liste von Produkten, die PHP enthalten und betroffen sein können, und erweitert sie laufend. Mehrere Hersteller haben bereits reagiert: cPanel hat seine PHP-Pakete korrigiert, einschließlich Backports für PHP 7.4, 8.0 und 8.1, und Plesk hat korrigierte PHP-Builds veröffentlicht sowie ein Update für die eigene Verwaltungsoberfläche. Palo Alto Networks führt alle Versionen von PAN-OS und Panorama als betroffen und hat noch keine korrigierten Versionen veröffentlicht; bis dahin empfiehlt der Hersteller, den Zugriff auf die Management-Schnittstelle auf vertrauenswürdige interne IP-Adressen zu beschränken. Webanwendungen wie WordPress, Drupal und Nextcloud laufen auf dem darunter installierten PHP, daher schließt ein Update dieses PHP die Lücken auch für sie.

PHP-Zweig	Status	Behoben in	Hinweise
8.5	Aktiver Support bis 31. Dezember 2027	8.5.12
8.4	Aktiver Support bis 31. Dezember 2026	8.4.27
8.3	Nur Sicherheitsupdates bis 31. Dezember 2027	8.3.36
8.2	Nur Sicherheitsupdates bis 31. Dezember 2026	8.2.35	Umstieg auf 8.4 oder 8.5 empfohlen
8.1 und älter	End of Life	Kein offizielles Release	Als betroffen aufgeführt. Minimale Quellcode-Backports für 7.4, 8.0 und 8.1; prüfen Sie bei Ihrer Distribution oder Ihrem LTS-Anbieter, ob Pakete mit Backports vorliegen

Empfehlungen für Ihre Sicherheitsverantwortlichen

• Identifizieren Sie mit den Scans aus der Scan-Anleitung möglichst jede PHP-Installation und patchen Sie dort, wo es möglich ist.
• Nicht jede PHP-Instanz lässt sich patchen, zum Beispiel Appliances oder PHP als Middleware in einem Software-Bundle. Schalten Sie internetexponierte Systeme ab. Ist das nicht möglich, isolieren und überwachen Sie sie mindestens.
• Betreiben Sie PHP-Dienste hinter einem aktivierten IDS/IPS und prüfen Sie, ob PHP2Shell-Signaturen vorhanden sind.
• Kann ein PHP-basierter Dienst vorübergehend vom Netz genommen werden, tun Sie das. Muss er online bleiben, wenden Sie die genannten Maßnahmen an und bewerten Sie zusätzlich das Risiko: Welche Daten wären im Ernstfall betroffen? Ein Security Monitoring, zum Beispiel mit einer EDR-Lösung, ist dann erforderlich. Verlassen Sie sich nicht allein darauf: Prüfen Sie, ob die EDR Signaturen für PHP2Shell enthält, denn Varianten können durchrutschen. Als Hunting-Ansatz kommt etwa eine Shell in Frage, die als Subprozess von PHP gestartet wird.
• Rechnen Sie mit weiteren öffentlichen Proofs of Concept. Der bisher beste bestätigte Proof of Concept funktioniert in Tests nicht in allen Umgebungen, und welche Variante gegen welche Konfiguration wirkt, ist noch offen.

Mit dem Patch und der von uns veröffentlichten Erkennung sind Sie gut aufgestellt. Wir können aber nicht garantieren, dass eine neue Variante das Bild nicht verändert.

So finden Sie anfällige PHP-Installationen mit Greenbone

1. Führen Sie einen authentifizierten Remote-Scan durch, also mit hinterlegten Zugangsdaten (Anleitung). Ein nicht authentifizierter Scan liest nur Remote-Informationen wie Banner aus, die nicht immer einen Schluss auf die Version zulassen. Setzen Sie bei nicht authentifizierten Scans den QdE-Filter (Quality of Detection) in den Ergebnissen auf 0.
2. Sind Remote-Scans in Ihrer Umgebung nicht zulässig, können Sie den Greenbone Agenten einsetzen (Anleitung). Hinweis: Der Agent ist derzeit eine Technology Preview.
3. Für Linux-Systeme verwenden Sie die Scan-Konfiguration „Full and fast“ unverändert. Sie prüft installierte Pakete und durchsucht zusätzlich das Dateisystem nach PHP-Programmdateien (php, php-cli, php5, php7, php8). Nicht gesucht wird nach php-cgi und php-fpm. Bei selbstkompilierten Applikationen oder wenn PHP als Middleware gebündelt wird, sind weitere Prüfschritte erforderlich. Bitte beachten Sie, dass Scans laufender Container nicht zur Verfügung stehen.
4. Für Windows-Systeme aktivieren Sie vor dem Scan die Erkennung portabler Anwendungen:
   • Klonen Sie die Scan-Konfiguration „Full and fast“ und suchen Sie in der Suchleiste nach „Options for Local Security Checks“.
   • Setzen Sie „Enable Detection of Portable Apps on Windows“ auf „yes“ und speichern Sie.
5. Optional: Prüfen Sie, ob für jede gefundene PHP-Software die Version erhoben wurde. Ohne Version ist ein Abgleich mit der Schwachstelle nicht möglich. Wurde PHP nur generisch ohne Version erkannt, gehen Sie davon aus, dass das System betroffen sein kann. So finden Sie diese Systeme: (1) Öffnen Sie „Ergebnisse“. (2) Aktivieren Sie die Logeinträge. (3) Suchen Sie nach name~"CPE Inventory" and ~php and not ~"php:php:". (4) Es werden die möglicherweise betroffenen Hostnamen und IP-Adressen angezeigt. Über einen Klick auf das blaue „CPE Inventory“ sehen Sie weitere Software und das Betriebssystem, die auf demselben System erkannt wurden. Wir haben diesen Filter getestet, er funktioniert. Ob er in jeder Umgebung alle Fälle erfasst, können wir weder testen noch bestätigen. Wurde nur ein Banner erkannt und ist kein authentifizierter Scan gelaufen oder fehlgeschlagen, sollten Admins auf den Systemen alle PHP-Programmdateien über eine Suche im gesamten Dateisystem erfassen und die Versionen bestätigen.
6. Stellen Sie sicher, dass der Feed aktuell ist. Mit einem manuellen Feed-Update erhalten Sie die PHP2Shell-Prüfungen sofort, sonst über das bei Ihnen eingerichtete automatische Update des NVT-Feeds.

Schnellere Alternative: Wir stellen zwei fertige Scan-Konfigurationen bereit, eine für Linux und eine für Windows, die auf die PHP2Shell-Prüfungen beschränkt sind (Download, Anleitung zum Import einer Scan-Konfiguration). Nutzen Sie sie wie in Schritt 1 beschrieben mit Zugangsdaten: SSH-Zugangsdaten für Linux, SMB-Zugangsdaten für Windows. In der Windows-Konfiguration ist die Erkennung portabler Anwendungen bereits aktiviert. Die Schritte oben gelten weiterhin.

Die Prüfungen für CVE-2026-109618 und CVE-2026-109619 funktionieren in nicht authentifizierten und in authentifizierten Scans, doch beide sehen Unterschiedliches. Ein nicht authentifizierter Scan sieht nur, was ein Server preisgibt. Verbirgt ein Host seine PHP-Version, kann der Scan nicht feststellen, welche Version läuft, und das Ergebnis ist nur so zuverlässig wie die Versionsinformation, die der Server sendet. Ein authentifizierter Scan meldet sich an und untersucht die installierte Software; er findet daher PHP auch auf Hosts, die keine Version anzeigen, im Rahmen der oben in der Anleitung genannten Grenzen. Für eine tiefere Suche auf Windows-Hosts aktivieren Sie vor dem Scan die Portable-App-Erkennung: Bearbeiten Sie Ihre Scan-Konfiguration (zum Beispiel eine Kopie von Full and fast), scrollen Sie zu Network Vulnerability Test Preferences, suchen Sie Options for Local Security Checks, setzen Sie Enable Detection of Portable Apps on Windows auf yes und speichern Sie. Authentifizierte Scans dauern länger und belasten die gescannten Systeme stärker, daher sollten Sie Umfang und Zeitpunkt des Scans entsprechend planen.

Zusammenfassung

CVE-2026-109618 und CVE-2026-109619 sind zwei kritische Schwachstellen in PHP, die eine nicht authentifizierte Remote Code Execution ermöglichen können. PHP hat sie in 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben, während End-of-Life-Zweige auf Backports angewiesen sind. Die Ausnutzungsversuche begannen, bevor die Patches veröffentlicht waren, und öffentliche Proofs of Concept sind im Umlauf. Inzwischen hat die CISA beide CVEs in ihren KEV-Katalog aufgenommen. Sicherheitsverantwortliche sollten jetzt aktualisieren und sicherstellen, dass sie jede PHP-Installation erfassen: End-of-Life-Versionen, Hosts, die ihre Version verbergen, und PHP, das in andere Software eingebettet ist.

Updates

1. 21. Oktober 2026: Erstveröffentlichung.
2. 22. Oktober 2026: Ausnutzungsversuche laut Amazon und watchTowr, öffentliche Proofs of Concept, korrigierte Pakete von Debian, Red Hat und Ubuntu, Reaktionen von cPanel, Plesk und Palo Alto Networks sowie die Empfehlungen der CISA für nicht mehr unterstützte PHP-Versionen ergänzt. Der Feed von Greenbone enthält jetzt Prüfungen auf Paketebene für zehn Linux-Distributionen.
3. 23. Oktober 2026: Schritt-für-Schritt-Anleitung zur Erkennung von PHP2Shell mit Greenbone und EPSS-Werte ergänzt.
4. 26. Oktober 2026: Scan-Anleitung um den Greenbone Agenten (Technology Preview), Umfang und Grenzen der Dateisystemsuche unter Linux sowie eine optionale Prüfung auf PHP ohne erkannte Version erweitert. Empfehlungen für nicht sofort patchbare Systeme ergänzt und die Grenzen der Einstellung session.upload_progress präzisiert. Prüfungen auf Paketebene für AlmaLinux, SUSE und openSUSE, Prüfungen für Produkte, die PHP mitliefern, sowie Links zu den Prüfungen auf SecInfo ergänzt.
5. 27. Oktober 2026: Fertige PHP2Shell-Scan-Konfigurationen für Linux und Windows zum Download ergänzt.
6. 28. Oktober 2026: Aufnahme beider CVEs in den KEV-Katalog der CISA ergänzt und EPSS-Werte aktualisiert.