Auf einen Blick:

Produkt / Komponente	Betroffene Versionen	Gepatcht in
PHP 8.5	vor 8.5.12	8.5.12
PHP 8.4	vor 8.4.27	8.4.27
PHP 8.3	vor 8.3.36	8.3.36
PHP 8.2	vor 8.2.35	8.2.35
PHP 8.1 und älter	betroffen, kein offizieller Support mehr	kein offizielles Release; Quell-Backports für 7.4, 8.0 und 8.1

• Schwachstellen: CVE-2026-109618 und CVE-2026-109619 (je CVSS 9.2, kritisch)
• Exploit: Proof of Concept öffentlich; laut Amazon breite Ausnutzung, ein erster Angriffsversuch schon am 17. Oktober
• Patch verfügbar seit: 21.10.2026, Pakete für Debian und Ubuntu bereits verfügbar
• BSI-Kritikalität: 3 / Orange (BITS-H 2026-297981-1132, Version 1.1)

Zeitleiste: Was bisher passiert ist

• 17. Oktober 2026: Amazon registriert in seinen Honeypots (MadPot) einen ersten Ausnutzungsversuch, vier Tage vor der Veröffentlichung.
• 20. Oktober 2026: Details zu den Schwachstellen werden vorzeitig bekannt. Das PHP-Projekt kündigt ein Notfall-Sicherheitsrelease an.
• 21. Oktober 2026, 16:00 Uhr MESZ: PHP veröffentlicht die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie die technischen Advisories. Die Entdecker von Wiz Research, OpenAI Codex Security und Calif stellen ihre Forschung auf php2shell.com vor.
• 21. Oktober 2026: CERT-EU und BSI warnen, das BSI stuft die Lage als Orange ein und meldet in Version 1.1 einen öffentlichen Proof of Concept. Ubuntu veröffentlicht gepatchte Pakete (USN-8948-1), auch Debian stellt Pakete bereit. Einige Betreiber in Deutschland nehmen Webseiten vorsorglich vom Netz.
• Seit 21. Oktober 2026: Laut Amazon wird PHP2Shell breit ausgenutzt. Das RUS-CERT der Universität Stuttgart hat einen öffentlichen Exploit an einem Testsystem verifiziert.

Welche Software ist betroffen?

Die Schwachstelle sitzt in PHP selbst, nicht in einer bestimmten Anwendung. Betroffen ist deshalb jede Software, die auf einer verwundbaren PHP-Version läuft: Content-Management-Systeme wie WordPress, Drupal, TYPO3 und Joomla, Shops wie Magento, Shopware und WooCommerce, Nextcloud, Moodle, MediaWiki und selbst entwickelte Anwendungen auf Laravel oder Symfony. Laut den Entdeckern reicht sogar eine einfache „Hello World“-Seite auf einer verwundbaren PHP-Version. Ein Update der Anwendung allein schließt die Lücke nicht, entscheidend ist die PHP-Laufzeitumgebung darunter.

Das BSI weist zudem darauf hin, dass PHP in Komponenten proprietärer Produkte und Appliances steckt, etwa in den Firewall-Distributionen pfSense und OPNsense. Das niederländische NCSC sammelt auf GitHub eine Liste betroffener Produkte, die laufend erweitert wird.

Gefährdet sind laut PHP-Advisory alle PHP-Installationen, die Web-Anfragen verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Projekt das Risiko bei mod_php ein: Dort gibt es einen demonstrierten Exploit, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor überhaupt Anwendungscode läuft.

PHP-FPM ist ebenfalls betroffen. Für CVE-2026-109619 wurde die Remote Code Execution laut GitHub-Advisory auch gegen PHP-FPM nachgewiesen, über die standardmäßig aktive Funktion Session Upload Progress. Dieser Weg setzt allerdings eine passende Operation in der Anwendung voraus. Red Hat stuft die Lücke für seine Distribution deshalb niedriger ein („Important“): Unter Red Hat Enterprise Linux läuft standardmäßig PHP-FPM, und Codeausführung sei dort in der Praxis schwierig.

Was Angreifende mit dem Exploit erreichen können

• Code ausführen: Bei erfolgreicher Ausnutzung führen Angreifende Code mit den Rechten des Web-Worker-Kontos aus. Die Entdecker haben das ohne Anmeldung gegen aktuelle Container-Images von WordPress, Drupal und Joomla vorgeführt.
• Arbeitsspeicher auslesen: CVE-2026-109619 erlaubt auch das Auslesen von Speicher des PHP-Prozesses, ohne dass Code ausgeführt wird. Darin können laut den Entdeckern Passwörter, Authentifizierungs-Tokens, API-Schlüssel und Zertifikate anderer Anfragen oder des Servers stehen. Solche Angriffe sind schwerer zu erkennen.

Die beiden Schwachstellen im Einzelnen:

• CVE-2026-109618 – Remote Code Execution über Out-of-Memory-Fehler (GHSA-w8hw-w9fx-j79w): Bricht PHP eine Anfrage wegen Speichermangels ab, während interne Request-Daten erst teilweise initialisiert sind, kann die Aufräumroutine diese ungültigen Daten als gültig behandeln. Laut Advisory lässt sich der Speichermangel unter anderem über präparierte Multipart-Anfragen gezielt herbeiführen.
• CVE-2026-109619 – Remote Code Execution über veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp): Zustand, der zu einer Anfrage gehört, kann im Worker-Prozess überleben, nachdem sein Speicher bereits freigegeben wurde. Eine spätere Anfrage im selben Worker kann diesen Zustand verwenden, bevor er zurückgesetzt wird (Use-after-free).

Die CVSS-Bewertung weist eine hohe Angriffskomplexität aus. Mit öffentlichen Exploits und laufenden Angriffen spielt das in der Praxis aber kaum noch eine Rolle. Unit 42 von Palo Alto Networks zählt nach eigenen Telemetriedaten mehr als 22,6 Millionen aus dem Internet erreichbare Instanzen, die potenziell verwundbar sind.

Betroffene PHP-Systeme im Inventar finden

Wer schnell patchen will, muss zuerst wissen, wo PHP überhaupt läuft. Ein vollständiges Inventar umfasst nicht nur die bekannten Webserver, sondern auch Subdomains, Altsysteme, Testumgebungen, Docker-Container, Appliances mit eingebettetem PHP und Webseiten bei externen Hostern oder Dienstleistern.

Wie prüfe ich die PHP-Version?

• Auf dem Server: php -v zeigt die Version der Kommandozeile. Der Webserver kann eine andere Version nutzen. Bei PHP-FPM deshalb zusätzlich die FPM-Version prüfen, je nach Distribution etwa mit php-fpm -v oder php-fpm8.3 -v.
• Installierte Pakete: unter Debian und Ubuntu mit dpkg -l | grep php, unter Red Hat und verwandten Systemen mit rpm -qa | grep php. Ausschlaggebend ist die Paketversion der Distribution, nicht die Versionsnummer von PHP selbst.
• Docker: Die PHP-Version steckt im Image. Images müssen aktualisiert bzw. neu gebaut werden, ein Update auf dem Host reicht nicht.
• Von außen: Manche Server verraten die PHP-Version im HTTP-Header X-Powered-By. Fehlt der Header, heißt das nicht, dass kein PHP läuft.

Gepatchte Pakete der Linux-Distributionen

Distribution	Paket	Gepatcht in
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS und älter	php7.4 und älter	Korrektur nur über Ubuntu Pro

Distributionen portieren die Korrektur in ihre eigenen Pakete zurück. Ein Ubuntu-Server mit „PHP 8.3.6“ kann deshalb gepatcht sein, obwohl die Versionsnummer älter aussieht als 8.3.36. Für Red Hat Enterprise Linux gilt das Advisory von Red Hat.

Was Sie jetzt tun sollten

• Auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren bzw. die gepatchten Pakete der Distribution einspielen.
• Wer das freiwillig gepflegte Repository rpms.remirepo.net nutzt: Laut PHP-Projekt gab es dort am Release-Tag keine Updates. Das PHP-Projekt rät, auf Distributionspakete umzusteigen oder aus dem Quellcode zu bauen.
• Nach dem Update alle PHP-Worker neu starten, etwa PHP-FPM-Pools und Apache.
• PHP in Docker-Containern und Appliances nicht vergessen: Images neu bauen, bei Appliances auf neue Firmware der Hersteller achten.
• Hosting-Dienstleister ansprechen, wenn Sie den Webserver nicht selbst betreiben, und um sofortiges Einspielen bitten.
• PHP 8.1 und älter: Das PHP-Projekt liefert dafür keine Updates mehr. Für PHP 7.4, 8.0 und 8.1 hat es minimale Quellcode-Backports bereitgestellt. Laut BSI haben alle Versionen vor 8.2 ihr End-of-Life erreicht, PHP 8.2 erhält nur noch bis Jahresende Sicherheitsupdates. Betroffene Systeme sollten auf eine unterstützte Version migriert werden.
• Nach Anzeichen eines Angriffs suchen, und zwar ab dem 17. Oktober 2026.

Wo nicht sofort aktualisiert werden kann, empfehlen RUS-CERT und BSI, betroffene Systeme vom Internet zu trennen oder ihre Erreichbarkeit einzuschränken, bis die Updates installiert sind.

Woran erkenne ich einen Angriff?

Ein einzelnes Merkmal, das jeden Angriff zuverlässig erkennt, gibt es laut den Entdeckern nicht. Als Hinweise für eine Untersuchung nennen sie:

• auffällig große oder fehlerhafte PHPSESSID-Cookies in Server-Antworten,
• ungewöhnliche Multipart-Anfragen, gefolgt von Speicherfehlern („memory limit“) oder wiederholten HTTP-500-Antworten,
• unerklärliche Abstürze oder Neustarts von PHP-Workern.

Amazon rät, Untersuchungen nicht erst ab der Veröffentlichung, sondern mindestens ab dem 17. Oktober 2026 anzusetzen. Fehlen solche Spuren, ist ein System damit nicht entlastet: Ein Auslesen des Arbeitsspeichers hinterlässt unter Umständen kaum Spuren in den Anwendungsprotokollen. Verbindliche Angriffsindikatoren hat das BSI bislang nicht veröffentlicht. Wer Anzeichen einer Ausnutzung findet, sollte davon ausgehen, dass Zugangsdaten, Tokens und Schlüssel aus dem PHP-Prozess betroffen sein können, und sie austauschen. Hilfe bei der Untersuchung bieten spezialisierte Incident-Response-Dienstleister; das BSI führt eine Liste qualifizierter Anbieter.

Übergangsmaßnahmen, wenn das Update noch nicht möglich ist

Das PHP-Projekt nennt Maßnahmen, die einzelne Angriffswege erschweren. Es betont ausdrücklich, dass nur das Update eine vollständige Lösung ist; auch RUS-CERT und BSI warnen, dass die Maßnahmen umgangen werden können. Laut BSI müssen alle Maßnahmen gemeinsam umgesetzt werden, um eine Ausnutzung maßgeblich zu erschweren.

• Gegen CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen den Wert nicht überschreiben können (etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration), und post_max_size niedrig halten (8M ohne Datei-Uploads, sonst 32M). Zusätzlich Größen- und Anzahlgrenzen für Anfragen am Webserver oder Proxy setzen.
• Braucht die Anwendung keine Multipart-Formulare, rät das PHP-Projekt, solche Anfragen schon am Frontend zu blockieren, bevor sie PHP erreichen.
• Gegen CVE-2026-109619: session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool setzen und alle Worker neu starten; ini_set() und .user.ini reichen nicht. Unter PHP 8.5 zusätzlich fatal_error_backtraces=0. Wer Session Upload Progress nicht braucht, sollte die Funktion laut PHP-Projekt auch nach dem Update abgeschaltet lassen.
• Wenn Leistung keine Rolle spielt, nennt das PHP-Projekt pm.max_requests=1 als weitere Option: Dann bearbeitet jeder FPM-Worker nur eine Anfrage, und veralteter Zustand kann nicht in die nächste Anfrage gelangen.
• Fehlerprotokolle mit error_reporting=E_ALL auf Warnungen vor dem Skriptstart, Fatal Errors und „Maximum execution time exceeded“ prüfen und gefundene Fehler beheben. Ein unauffälliges Protokoll ist laut PHP-Projekt aber kein Beweis, dass ein System sicher ist.
• Web Application Firewalls: Anbieter wie Cloudflare haben Regeln gegen bekannte Angriffswege veröffentlicht. Vollständigen Schutz bieten laut BSI aber nur das Update oder die Trennung vom Internet.
• Unabhängig davon empfiehlt das BSI, SELinux oder AppArmor zu nutzen, um die Folgen einer erfolgreichen Codeausführung zu begrenzen.

DACH- und EU-Kontext

Für Einrichtungen im Anwendungsbereich von NIS-2 gilt: Führt eine Ausnutzung dieser Schwachstellen zu einem erheblichen Sicherheitsvorfall, greifen die Meldepflichten nach Art. 23 NIS-2-Richtlinie, in Deutschland nach § 32 BSIG. In Österreich und der Schweiz gelten die jeweiligen nationalen Meldepflichten. Das BSI hat zu den Lücken einen BSI-IT-Sicherheitshinweis (BITS-H 2026-297981-1132) mit Kritikalität Orange herausgegeben; dieser ist als TLP:CLEAR frei weitergebbar.

Wie LocateRisk bei exponierten Assets ansetzt

LocateRisk unterstützt External Attack Surface Management durch die Sichtbarkeit extern erreichbarer Systeme und eingesetzter Software. Bei diesem Vorfall kann das helfen, öffentlich erreichbare Webserver und PHP-Installationen im Asset-Inventar zu finden, auch solche, die in keiner internen Liste stehen, und die Update-Reihenfolge zu priorisieren.

LocateRisk ersetzt kein Patch-Management und trifft keine Aussage darüber, ob auf einem erkannten System eine verwundbare PHP-Version läuft. Dafür ist der Abgleich der eingesetzten Version mit dem PHP-Advisory bzw. dem Paketstand der Distribution nötig.

Für ausgelagerte Webanwendungen oder Kundenportale kann Vendor Risk Management ergänzend helfen, Rückmeldungen der Dienstleister zum Patch-Stand nachvollziehbar zu dokumentieren.

Bin ich betroffen?

Betroffen ist PHP vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12 sowie jede ältere PHP-Version; behoben ist die Lücke in 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bzw. in den gepatchten Paketen der Distributionen. Wer wissen will, ob PHP in der eigenen extern erreichbaren Infrastruktur überhaupt sichtbar ist, kann den CVE-Quick-Check am Ende dieses Artikels nutzen: Er zeigt exponierte Systeme und die von außen erkennbare Software.

Die konkret installierte Version lässt sich von außen nicht in jedem Fall bestimmen — ausschlaggebend ist der Abgleich mit dem Hersteller-Advisory.

Quellen und weitere Infos

• PHP / php.net: Security advisory: Critical remote code execution vulnerabilities, update now
• PHP / GitHub: GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• PHP / GitHub: GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• Wiz, OpenAI, Calif: PHP2Shell – Forschungsseite der Entdecker
• BSI: BSI-IT-Sicherheitshinweis 2026-297981-1132: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot
• RUS-CERT Universität Stuttgart: Kritische Schwachstellen in PHP (CVE-2026-109618 und CVE-2026-109619)
• NCSC-NL: php2shell – Liste betroffener Produkte
• Debian: Security Tracker CVE-2026-109618
• Ubuntu: USN-8948-1: PHP vulnerabilities
• Red Hat: CVE-2026-109618
• Unit 42: CVE-2026-109618 und CVE-2026-109619
• CERT-EU: Security Advisory 2026-018: Critical Vulnerabilities in PHP

Stand: 22.10.2026. Dieser Beitrag dient allgemeinen Informationszwecken und ist keine Rechts-, Sicherheits- oder Handlungsberatung im Einzelfall. Sicherheitslage und Patch-Verfügbarkeit können sich seit der Veröffentlichung geändert haben; maßgeblich ist stets das verlinkte Hersteller-Advisory. Trotz sorgfältiger Recherche übernehmen wir keine Gewähr für Aktualität, Richtigkeit und Vollständigkeit.

---