PHP-Update gegen php2shell: Zwei kritische Lücken erlauben Codeausführung ohne Login

Was ist php2shell? Remote Code Execution im PHP-Kern

php2shell ist der Sammelname für zwei kritische Schwachstellen im PHP-Kern: CVE-2026-109618 und CVE-2026-109619. Beide erlauben Remote Code Execution (RCE) ohne Anmeldung auf jedem PHP-System, das Webanfragen bedient. Das PHP-Projekt hat sie am 21. Oktober 2026 mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen. Beide Lücken tragen die Bewertung CVSS v4.0 9.2.

Der Name stammt vom Exploit-Skript, mit dem Wiz Research beide Lücken zu einem Angriff verband. Eine der Schwachstellen entdeckte Calif, Teilnehmer am OpenAI-Programm "Patch the Planet", mit dem KI-Modell GPT-5.6 Sol. Wiz meldete beide Lücken unabhängig davon am 24. August 2026 an das PHP-Security-Team.

Laut Wiz existiert der fehlerhafte Code seit über einem Jahrzehnt im Projekt, jede Version ab PHP 5.4 ist von mindestens einer Lücke betroffen. Erste Anzeichen des Speicherfehlers fand das Projekt laut PHP Foundation schon 2024. Die Korrektur stockte danach monatelang, die Foundation nennt das "ein strukturelles Versagen". W3Techs zählt PHP auf rund 70 Prozent aller Websites mit bekannter Server-Sprache.

Quelle: Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities", Abschnitt Responsible disclosure timeline (Screenshot wiz.io, 21.10.2026)

Ein Beitrag auf Hacker News nannte am 20. Oktober die reservierten CVE-Nummern vorab, als Quelle stand dort "source: trust me, bro", dazu eine angebliche Bewertung von CVSS 10.0. Daraufhin zog das PHP-Projekt die Ankündigung vor und verschob das Release vom 22. auf den 21. Oktober, 14:00 UTC. Laut CERT-EU trafen die Patches um 13:30 UTC ein. Erste Proof-of-Concepts kursieren seither. Die National Vulnerability Database (NVD) führt CVE-2026-109618 nach CVSS v3.1 mit 9.8, das PHP-Projekt bewertet beide Lücken nach CVSS v4.0 mit 9.2.

Betroffene und gepatchte PHP-Versionen

Betroffen sind laut PHP-Projekt alle Installationen, die Webanfragen verarbeiten. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Diese Schnittstellen zwischen Webserver und PHP-Interpreter heißen SAPI (Server API). Die Versionen im Überblick:

Die Patches gingen laut PHP-Projekt vorab an Linux-Distributionen und LTS-Anbieter (Long-Term Support). Debian 13 erhält den Fix als php8.4 8.4.27-1deb13u1 (DSA-6574-1), Debian 12 als php8.2 8.2.35-1deb12u1 (DLA-4848-1). Container-Images bringen ihr eigenes PHP mit und müssen neu gebaut und ausgerollt werden. Die offiziellen Docker-Images folgten am 21. Oktober erst mit Verzögerung.

Quelle: PHP-Projekt, "Security advisory: Critical remote code execution vulnerabilities, update now" (Screenshot php.net, 21.10.2026)

Wie der Angriff funktioniert: Use-after-free zwischen zwei Requests

PHP-Worker überdauern einzelne Anfragen, jeder Request bekommt dabei einen eigenen Speicherbereich, der am Ende wieder freigegeben wird. Einige globale Zustände des Workers verweisen in diesen Speicher und müssen vor der Freigabe zurückgesetzt werden. In beiden Lücken bleibt genau dieser Reset aus.

CVE-2026-109618 heißt beim PHP-Projekt "RCE via OOM corruption". Überschreitet eine Anfrage das memory_limit, bricht PHP sie per longjmp() ab (Out of Memory, OOM). Passiert das, während die Request-Daten erst teilweise initialisiert sind, bleibt der Speicher in einem ungültigen Zustand, und die Aufräumroutine am Request-Ende behandelt ihn trotzdem als gültig. Ein Angreifer kann den Speicherverbrauch gezielt hochtreiben: Eine Multipart-Anfrage ohne nutzbare Content-Length passiert die Prüfung von post_max_size und liefert trotzdem Daten nach. Die Zahl der Header je Multipart-Teil ist unbegrenzt, intern brauchen sie deutlich mehr Speicher als bei der Übertragung.

CVE-2026-109619 heißt "RCE via stale global state": Hier überlebt Request-Zustand die Freigabe seines Speichers. Das PHP-Projekt beschreibt den Angriff als Produzent-Konsument-Paar. Im ersten Request entsteht nach einem Fatal Error, einem Speicherfehler oder einer Zeitüberschreitung ein verwaister Zeiger, und ein zweiter Request auf demselben Worker greift vor der normalen Initialisierung darauf zu. Das ist ein klassischer Use-after-free. Als bestätigte Konsumenten nennt das Projekt Diagnosen aus INI-Einstellungen vor der Request-Initialisierung und den Session-Upload-Progress, der standardmäßig aktiv ist und keinen session_start()-Aufruf braucht.

Wiz nennt zusätzlich einen Speicherabfluss: PHP kodiert zurückgeholten Heap-Inhalt in ein PHPSESSID-Antwort-Cookie, und darüber lassen sich Passwörter, Tokens und API-Schlüssel anderer Anfragen auslesen.

mod_php, PHP-FPM, FrankenPHP: wo das Risiko am höchsten ist

Das PHP-Projekt stuft das Risiko für Apache mit mod_php am höchsten ein. Der Grund laut Advisory: mod_php ruft die Shutdown-Routine selbst bei fehlgeschlagenem Request-Start auf, noch vor jeder Zeile Anwendungscode.

PHP-Version anzeigen und Patchstand prüfen

Bei der Prüfung gibt es drei Fallen:

1. php -v zeigt nur die Version der Kommandozeile. Das Web-SAPI kann eine andere sein, deshalb php-fpm -v oder eine temporäre phpinfo()-Seite heranziehen.
2. Distributionspakete können den Fix unter der alten Versionsnummer tragen. Entscheidend ist der CVE-Eintrag im Paket-Changelog, nicht die Zahl in phpinfo(). Ubuntu 22.04 LTS etwa trägt den Fix als php8.1 8.1.2-1ubuntu2.28, die Nummer vor dem Bindestrich bleibt 8.1.2.
3. Container-Images, Appliances und eingebettete Produkte bringen eigenes PHP mit. Das BSI nennt als Beispiele WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Inventarlisten betroffener Produkte sammelt das Repository des niederländischen NCSC.

Das Update wirkt erst, wenn alle PHP-Worker neu gestartet sind.

Quelle: NCSC-NL, Repository php2shell, Verzeichnis software (Screenshot github.com, 21.10.2026)

PHP End of Life: Was für 7.4, 8.0 und 8.1 gilt

Für PHP 8.1 und älter liefert das Projekt keine Updates mehr. Wegen der Schwere veröffentlichte das Security-Team dennoch minimale Quell-Backports für PHP 7.4, 8.0 und 8.1 auf GitHub. Distributionspakete erhalten den Fix nur durch einen Anbieter-Backport: Canonical liefert ihn für Ubuntu 20.04 und älter ausschließlich über Ubuntu Pro, Debian 12 bekommt ihn vom LTS-Team. Das Community-Repository rpms.remirepo.net hatte am Release-Tag laut CERT-EU noch keine Pakete. Auch PHP 8.2 läuft aus, Sicherheitsupdates für diesen Zweig enden am 31. Dezember 2026.

Notmaßnahmen ohne Update: PHP-Memory-Limit und Upload-Progress

Das PHP-Projekt schreibt in jeder Release-Note: "There are no complete mitigations, updating is the only safe choice." Unvollständig sind die Workarounds, nicht die Korrektur. Für die vier Releases lag bis zum Abend des 21. Oktober weder eine Nachkorrektur noch ein weiteres Advisory vor. Die folgenden Einstellungen verkleinern einzelne Angriffspfade, machen eine Installation aber nicht sicher.

Die Einstellungen gehören in php.ini, FPM-Pool oder Server-Konfiguration, danach müssen alle Worker neu starten. Über ini_set() oder .user.ini greifen sie zu spät.

Wiz nennt drei Erkennungssignale: ungewöhnliche Multipart-Anfragen mit anschließenden Memory-Limit-Fehlern oder gehäuften HTTP-500-Antworten, auffällig große oder fehlerhafte PHPSESSID-Cookies in Antworten sowie unerklärlicher Worker-Austausch. Anwendungs-Logs helfen dabei wenig, weil der Angriff unterhalb der Anwendungsebene stattfindet.

BSI-Warnung Orange: Behörden und Kliniken nehmen Webseiten offline

Das BSI führt php2shell als Cybersicherheitswarnung BITS-H 2026-297981-1132 (BSI-IT-Sicherheitshinweis) mit Kritikalität 3 / Orange. Orange bedeutet laut BSI: Maßnahmen müssen unverzüglich ergriffen werden, eine massive Beeinträchtigung des Regelbetriebs ist möglich. Eine breite Ausnutzung innerhalb weniger Stunden nach Patch-Veröffentlichung hält die Behörde für wahrscheinlich. Wer nicht sofort patchen kann, soll laut BSI "eine vorübergehende Trennung vom Internet erwägen, da alle Workarounds keinen vollständigen Schutz vor Angriffen bieten". Berichte in sozialen Medien über erste Angriffsversuche konnte das BSI nicht verifizieren. CISA, das britische NCSC und CERT-EU empfehlen übereinstimmend, nicht patchbare Systeme abzuschalten oder zu isolieren.

Quelle: BSI, Cybersicherheitswarnung BITS-H 2026-297981-1132, Seite 1 (Screenshot bsi.bund.de, 21.10.2026)

Zahlreiche Betreiber folgten dem laut Reuters und dpa, vorsorglich und ohne bekannte Kompromittierung. Das Informationstechnikzentrum Bund (ITZBund) nahm laut Digitalministerium mehrere Websites präventiv vom Netz. Baden-Württemberg schaltete die Seiten seiner Ministerien und Regierungspräsidien ab, Landesangebote in Hessen, Bayern und Thüringen waren zeitweise nicht erreichbar. Mainz, Dresden, Potsdam, Offenbach und Halberstadt nahmen Dienste offline, ebenso die Charité, mehrere Universitätskliniken und der Verkehrsbetrieb Üstra in Hannover.

In Europa gingen unter anderem das niederländische NCSC, das Login-System DigiD, der Hafen Rotterdam und die französischen Präfekturen offline. Finnlands Staats-IT Valtori schaltete alle öffentlichen Webdienste ab und meldet weder Ausnutzung noch Datenabfluss. Die Wikimedia Foundation nahm Phabricator und weitere Systeme vom Netz.

Laut Sansec hilft der Wartungsmodus von WordPress oder Magento nicht, weil PHP jede Anfrage verarbeitet, bevor die Anwendung das Wartungs-Flag prüft. Wirksam ist, eine statische Seite auszuliefern und PHP-FPM zu stoppen, ebenso am Webserver nur GET und HEAD zuzulassen.

Vorgelagerte Filter gibt es ebenfalls: Ab dem 21. Oktober, 3:02 UTC, hat Cloudflare Regeln in seiner Web Application Firewall (WAF) aktiviert, auch für kostenlose Tarife. Im Angriffsverkehr sah das Unternehmen bereits variierte Payloads, die diese Regeln umgehen sollten. Neben Cloudflare nennt das BSI den WAF-Anbieter Bunny Shield, hält aber fest, dass nur Patchen oder Trennen vom Internet vollständig schützt.

WordPress-PHP-Update und Hosting: wer für den Patch zuständig ist

Wiz demonstrierte den Exploit gegen aktuelle Container-Images von WordPress, Drupal und Joomla. Die Schwachstelle sitzt in PHP selbst: Ein Update von WordPress oder eines Plugins behebt sie nicht, solange die PHP-Laufzeit veraltet ist.

Zuständig ist der Betreiber der PHP-Laufzeit: im Shared Hosting der Provider über die PHP-Versionswahl im Kundenmenü, sonst Distributionspakete oder das Basis-Image des Containers. Managed-Plattformen und Agenturen müssen den Patchstand nachweisen, eine bloße Zusage genügt nicht.

Die Laufzeitumgebung gehört deshalb in den Prüfumfang eines Penetrationstests für Webanwendungen, und PHP-Instanzen gehören ins Inventar eines Schwachstellenscans. Ein Patch-Management für Anwendungen allein erfasst die darunterliegende Laufzeit nicht.

PHP-Sicherheitslücken: Wird php2shell schon ausgenutzt?

php2shell steht in einer Reihe mit der HTTP/2 Bomb vom Juni: Wieder entdeckte Calif mit einem KI-Modell einen alten Fehler in Basisinfrastruktur, und laut Wiz beschleunigt KI auch die Ausnutzung. Wiz beschreibt, wie Gemini 4 Argon und GPT-5.6 Sol Exploits an Versionen, Konfigurationen und Speicherlayouts anpassen.

Dass sich die Zeitspanne zwischen Advisory und Angriff weiter verringert, zeigt der Beitrag zur Mean Time to Exploit. Diesmal sickerten schon vor dem Release Details durch: Laut PHP Foundation veröffentlichte Calif am 20. Oktober versehentlich ein Video des eigenen Proof-of-Concept, und Chainguard stellte am 21. Oktober um 7:41 UTC, über sechs Stunden vor dem koordinierten Termin, Container-Images mit dem Fix bereit.

Bis zur Veröffentlichung sah das PHP-Security-Team keinen funktionierenden Exploit. Die Sicherheitsfirma watchTowr meldete Ausnutzungsversuche über ihr Honeypot-Netz, CISA berichtete keine beobachtete Ausnutzung. Palo Alto Networks zählte über 22,6 Millionen exponierte, potenziell verwundbare Instanzen. Zuerst kommt deshalb das Update, dann die Prüfung über das Web-SAPI, danach die eingebetteten PHP-Instanzen und zuletzt die Migration weg von PHP 8.2.

Quellen

• PHP-Projekt: Security advisory "Critical remote code execution vulnerabilities, update now" (21.10.2026)
• PHP-Projekt: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)
• PHP-Projekt: GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)
• PHP-Projekt: Supported Versions
• The PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security (21.10.2026)
• BSI: Cybersicherheitswarnung BITS-H 2026-297981-1132, PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit (Version 1.1, 21.10.2026, PDF)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21.10.2026)
• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities (Sagi Tzadik, Shir Tamari, Nir Ohfeld, Tomer Schwartz, 21.10.2026)
• OpenAI: Patch the Planet: global response coordination as agents uncover critical vulnerabilities (21.10.2026)
• CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
• NCSC UK: Critical security issue affecting PHP (21.10.2026)
• NCSC-NL: php2shell, Inventar betroffener Produkte (GitHub)
• Valtori: Päivitys 21.10. klo 18: PHP-korjauspäivityksen asennukset aloitettu (21.10.2026, finnisch)
• Reuters: Factbox, Websites taken offline over PHP risks (21.10.2026)
• tagesschau.de: Programmiersprache PHP: Sicherheitslücke bedroht weltweit Webseiten (21.10.2026, 19:32 Uhr)
• Sansec: php2shell, Analyse und Empfehlungen für Shop-Betreiber (21.10.2026)
• Palo Alto Networks Unit 42: CVE-2026-109618 and CVE-2026-109619 (21.10.2026)
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability (21.10.2026)
• Canonical: USN-8948-1, PHP vulnerabilities (21.10.2026)
• Debian Security Tracker: CVE-2026-109618
• docker-library/php: Issue 1693 zu den PHP-Images (21.10.2026)
• NVD: CVE-2026-109618
• CISA: Known Exploited Vulnerabilities Catalog
• watchTowr: FAQ zu CVE-2026-109618 und CVE-2026-109619
• Hacker News: Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming (20.10.2026)
• W3Techs: Usage statistics of PHP for websites