CVE-2026-109618 und CVE-2026-109619 erklärt: Welche PHP-Systeme betroffen sind

Am Abend des 20. Oktober 2026 trudelte bei vielen Systemverantwortlichen eine Meldung ein, die selten ist: Das PHP-Projekt kündigt für den nächsten Morgen ein kritisches Sicherheitsrelease an. Nicht ein Patch unter vielen, sondern zwei eigenständige Remote-Code-Execution-Lücken, beide mit CVSS-Basiswert 9,2. Wer den Release-Hinweis liest, weiß, dass etwas gepatcht werden muss — aber noch nicht, welche seiner Systeme wirklich gefährdet sind und wie dringend gehandelt werden muss.

Genau das ist das eigentliche Problem: CVE-2026-109618 und CVE-2026-109619 sind nicht für jede PHP-Installation gleich ausnutzbar. Die Angriffskomplexität ist laut CVSS-Vektor hoch, und ob eine Lücke in der eigenen Umgebung tatsächlich ausgenutzt werden kann, hängt vom eingesetzten SAPI, der Serverarchitektur und der Konfiguration ab. Wer pauschal Entwarnung gibt oder wahllos Server abschaltet, trifft in beiden Fällen die falsche Entscheidung.

Dieser Artikel erklärt beide Schwachstellen technisch verständlich, zeigt welche SAPIs und Versionszweige konkret betroffen sind, und hilft dabei, die eigene Risikoexposition einzuschätzen — ohne Exploit-Anleitung, ohne erfundene Zahlen.

Die kritischen PHP-Sicherheitslücken 2026 auf einen Blick

Für einen vollständigen Überblick über die Veröffentlichungshistorie, offizielle Quellen und den empfohlenen Update-Prozess lesen Sie zunächst die Übersichtsseite: Kritische PHP-Sicherheitslücken 2026: Jetzt patchen, Systeme prüfen und Modernisierung planen.

Beide Lücken sind in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 behoben. Alle Versionen darunter in diesen Zweigen sind betroffen. PHP 8.1 und älter erhält vom PHP-Projekt keine offiziellen Patches mehr — dazu später mehr.

CVE-2026-109618: RCE durch OOM-Korruption

Was passiert technisch?

Wenn PHP während der Verarbeitung eines Requests keinen Arbeitsspeicher mehr zuweisen kann — ein sogenannter Out-of-Memory-Zustand (OOM) — bricht es den Request über einen longjmp()-Aufruf ab. Dieser Mechanismus ist nicht neu; er existiert, damit ein einzelner Request den gesamten Prozess nicht zum Absturz bringt.

Das Problem: In bestimmten Startphasen des Request-Lifecycles ist der für diesen Request reservierte Speicher (Request-Speicher) bereits physisch erreichbar, aber noch nicht vollständig initialisiert. Wenn der OOM-Abbruch in genau diesem Fenster einsetzt, hinterlässt longjmp() einen inkonsistenten Zustand. Beim Aufräumen am Request-Ende greift PHP auf Strukturen zu, die unvollständig oder bereits freigegeben sind — ein klassischer Memory-Corruption-Pfad, der zu Remote Code Execution führen kann.

Das Advisory nennt das Parsen von Multipart-Anfragen als einen validierten Auslöser: Ein Angreifer kann durch entsprechend gestaltete multipart/form-data-Requests den OOM-Pfad gezielt provozieren, sofern das Memory-Limit nicht über Betriebssystem-Mechanismen (RLIMIT_AS/RLIMIT_DATA) abgesichert ist.

Welche SAPIs sind betroffen?

Für Apache mod_php ist Remote Code Execution über HTTP mit Standardlimits validiert — das ist die am stärksten betroffene Konfiguration.

Für PHP-FPM, FrankenPHP und LSAPI kommt das Advisory aufgrund von Quellcodeanalyse zu dem Schluss, dass diese SAPIs voraussichtlich anfällig sind. Ein vollständiger, demonstrierter Exploit existiert dort zum Zeitpunkt der Veröffentlichung (21.10.2026) nicht. Das bedeutet nicht, dass diese Systeme sicher sind — es bedeutet, dass der Aufwand für einen Angreifer dort höher ist.

Was begrenzt die Ausnutzbarkeit?

Der CVSS-Vektor AC:H (hohe Angriffskomplexität) und AT:P (besondere Voraussetzungen) spiegeln reale Einschränkungen wider: Der Angreifer muss den OOM-Zustand in einem präzisen Zeitfenster auslösen. Systeme mit sehr konservativen Speicherlimits auf Betriebssystemebene oder mit aggressiver Eingabebeschränkung sind schwerer zu treffen — aber nicht vollständig geschützt. Das PHP-Projekt bezeichnet das Update als einzig vollständige Abhilfe.

CVE-2026-109619: RCE durch veralteten globalen Zustand

Ein anderer Angriffspfad

Diese Lücke setzt an einer anderen Stelle des PHP-Internals an: dem globalen Zustand eines Workers nach Abschluss eines Requests. In persistenten Ausführungsmodellen — also überall dort, wo ein PHP-Prozess mehrere Requests nacheinander verarbeitet — werden nach Request-Ende Fehler-, Session-, Objekt- und Extension-Zustand zurückgesetzt. Läuft dieser Cleanup fehlerhaft, zeigen interne Datenstrukturen auf bereits freigegebenen Speicher. Das ist ein klassisches Use-after-free-Muster.

Der entscheidende Unterschied zu CVE-2026-109618: Eine Ausnutzung erfordert mindestens zwei Requests, die denselben Worker erreichen. Der erste Request präpariert den veralteten Zustand, der zweite nutzt ihn aus. Das macht den Angriff koordinierter und etwas schwerer als einen einstufigen Angriff — schließt ihn aber keineswegs aus.

Validierte Angriffspfade

• Apache mod_php: RCE ist bestätigt.
• PHP-FPM: Der Pfad über session.upload_progress ist validiert. Diese Funktion erlaubt es, beim Datei-Upload den Fortschritt in der Session zu speichern. Wer sie nicht benötigt, sollte session.upload_progress.enabled=0 setzen — das PHP-Projekt empfiehlt das auch nach dem Patch, falls die Funktion ungenutzt bleibt.

Hypothetisches Ablaufbeispiel

Stellen Sie sich einen Onlineshop auf Basis eines PHP-basierten Frameworks vor, betrieben via PHP-FPM hinter Nginx. Ein Angreifer sendet einen ersten Request, der session.upload_progress aktiviert und gezielt einen präparierten Session-Zustand erzeugt. Ein zweiter Request trifft denselben FPM-Worker — durch Wartezeit, Wiederholung oder Sticky-Session-Mechanismen erzwingbar — und greift auf den korrumpierten Speicherbereich zu. Das Ergebnis wäre Code-Ausführung mit den Rechten des PHP-FPM-Workers, typischerweise www-data. Dies ist ein hypothetisches Beispiel zur Illustration des Angriffspfads, kein dokumentierter realer Angriff.

Betroffene Versionszweige und Support-Status

Die folgende Tabelle zeigt, welche PHP-Versionszweige von Patches profitieren und wie lange sie noch unterstützt werden.

Wer noch PHP 8.1 einsetzt, steht vor einer schwierigen Lage: Das PHP-Projekt hat minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht. Distributionen, Hoster und LTS-Anbieter wie Plesk liefern teils eigene Backports. Plesk beispielsweise hat für die mit Plesk ausgelieferten PHP-Versionen eigene Patches bereitgestellt. Ob diese Backports vollständig und zeitnah verfügbar sind, hängt vom jeweiligen Anbieter ab — hier ist direktes Nachfragen beim Hoster oder Distributor notwendig.

PHP 5 erhält keinen Patch. Systeme auf PHP 5 sind von diesen Lücken betroffen und sollten unabhängig von diesem Vorfall bereits seit Jahren auf eine aktuelle Version migriert sein.

Aktive Ausnutzung: Was bekannt ist

watchTowr meldet, dass in seinem Honeypot-Netz seit dem 21. Oktober 2026 — dem Tag der Patch-Veröffentlichung — aktive Ausnutzungsversuche beobachtet wurden. Das ist eine einzelne Herstellerquelle und entsprechend einzuordnen: Honeypot-Netzwerke ziehen gezielt automatisiertes Scanning an und bilden nicht zwingend das vollständige Bild realer Angriffe ab. Die Meldung ist dennoch ein klares Signal, dass Exploits bereits entwickelt wurden und automatisiert eingesetzt werden.

In Fachmedien kursiert für den kombinierten Angriff der Name „PHP2Shell". Eine offizielle Bestätigung oder Klassifizierung durch das PHP-Projekt liegt dazu nicht vor.

Eine Warnung durch ENISA oder das BSI zu diesen spezifischen CVEs ist bis zum Stand dieses Artikels (22.10.2026) nicht verifiziert. Entsprechende Meldungen sollten direkt auf den offiziellen Behördenwebsites geprüft werden.

Was tatsächlich schützt — und was nicht

Das PHP-Projekt ist in seinem Advisory ungewöhnlich konkret: Die einzig vollständige Abhilfe ist das Update auf eine gepatchte Version, gefolgt vom Neustart aller PHP-Worker und Dienste. Alle anderen Maßnahmen sind Teilschritte, die das Risiko reduzieren, aber keine vollständige Absicherung bieten.

Teilmaßnahmen mit begrenzter Schutzwirkung

Das Advisory nennt folgende Konfigurationsanpassungen explizit als nicht vollständig schützend, aber als sinnvolle Überbrückung bis zum Patch:

• memory_limit=-1 administrativ erzwingen (nur wirksam, wenn auch RLIMIT_AS/RLIMIT_DATA auf Betriebssystemebene nicht greifen)
• post_max_size konservativ setzen
• max_input_nesting_level senken
• Anzahl der Eingabevariablen, Multipart-Teile und Uploads begrenzen
• Multipart-Anfragen am Frontend blockieren, wenn sie nicht benötigt werden
• session.upload_progress.enabled=0 (auch nach dem Patch empfohlen, wenn die Funktion ungenutzt ist)
• Unter PHP 8.5: fatal_error_backtraces=0
• pm.max_requests=1 in PHP-FPM, wo die Leistung es erlaubt (verhindert Worker-Wiederverwendung, eliminiert den Zwei-Request-Pfad von CVE-2026-109619 — auf Kosten der Performance)

pm.max_requests=1 ist für CVE-2026-109619 besonders relevant: Da die Lücke zwei Requests an denselben Worker erfordert, kann das Deaktivieren von Worker-Wiederverwendung den Angriffsvektor schließen. Auf stark frequentierten Systemen ist das aber wegen des Overhead durch häufiges Worker-Spawning keine langfristige Lösung.

Nach dem Patch

Der Neustart ist nicht optional. PHP-Worker halten Code und Zustand im Arbeitsspeicher. Ein Prozess, der vor dem Update gestartet wurde, führt weiterhin alten Code aus — bis er neu gestartet wird. Bei Apache mod_php bedeutet das einen Apache-Neustart, bei PHP-FPM einen php-fpm reload oder entsprechenden Serviceneustart.

Wer muss jetzt handeln — und in welcher Reihenfolge?

Nicht jede PHP-Installation trägt dasselbe Risiko. Die folgende Einordnung hilft bei der Priorisierung — sie ersetzt keine individuelle technische Prüfung.

Höchste Priorität haben Systeme, auf denen:

• Apache mod_php läuft (RCE für beide CVEs bestätigt)
• PHP unter 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 im Einsatz ist
• Der Server direkt aus dem Internet erreichbar ist
• Multipart-Uploads oder Session-Funktionen aktiv genutzt werden

Erhöhte Priorität haben Systeme mit PHP-FPM oder FrankenPHP, die öffentlich erreichbar sind — hier ist RCE für CVE-2026-109619 via session.upload_progress validiert, für CVE-2026-109618 laut Quellcodeanalyse wahrscheinlich.

Geringere, aber vorhandene Priorität tragen interne Systeme ohne direkte Internetanbindung. Der netzwerkseitige Schutz reduziert die Exposition, beseitigt sie aber nicht — insbesondere wenn interne Angreifer oder kompromittierte Systeme im selben Netz agieren.

Systeme auf PHP 8.1 oder älter ohne verfügbaren Distributor-Backport befinden sich in einer kritischen Lage, die über das reine Patchen hinausgeht: Ein PHP-Versions-Upgrade ist überfällig, und dieser Vorfall zeigt, warum End-of-Life-Software ein strukturelles Sicherheitsproblem darstellt — nicht nur ein punktuelles.

Praxisbeispiel: Bestandsaufnahme in einer typischen Mittelstandsumgebung

Nehmen wir ein hypothetisches produzierendes Unternehmen mit 80 Mitarbeitern: Es betreibt ein ERP-System auf einem internen Server (PHP 8.1, Apache mod_php, kein direkter Internetzugang), einen öffentlichen Webshop auf gemietetem Managed Hosting (PHP 8.3.34, Nginx + PHP-FPM), und ein internes Wiki (PHP 8.4.25, Apache mod_php, nur VPN-erreichbar).

Die Bestandsaufnahme ergibt drei unterschiedliche Risikoklassen:

1. Webshop (PHP 8.3.34, PHP-FPM, öffentlich): Unmittelbarer Handlungsbedarf. PHP-FPM mit validiertem session.upload_progress-Pfad, öffentlich erreichbar. Hoster kontaktieren oder manuelles Update auf 8.3.36 durchführen, session.upload_progress.enabled=0 als Sofortmaßnahme.

2. Wiki (PHP 8.4.25, mod_php, VPN): Erhöhte Priorität, aber durch VPN-Absicherung zeitlich etwas Spielraum. Update auf 8.4.27 einplanen, Apache-Neustart danach nicht vergessen.

3. ERP (PHP 8.1, mod_php, intern): Kein offizieller PHP-Patch, aber mod_php mit bestätigtem RCE-Pfad. Prüfen, ob der ERP-Anbieter oder der Distributor einen Backport liefert. Parallel: Migration auf einen unterstützten Zweig planen — PHP 8.1 läuft Ende 2024 aus und ist schon länger EOL.

Dieses hypothetische Beispiel illustriert, warum eine pauschale Antwort nicht funktioniert: Dieselbe Lücke hat je nach SAPI, Versionszweig und Netzwerkexposition sehr unterschiedliche Dringlichkeit.

Was SW Business Solutions für Sie prüft

Viele KMU wissen nicht exakt, welche PHP-Versionen auf welchen Servern laufen — und welche SAPI konfiguriert ist. Das ist kein Vorwurf, sondern eine strukturelle Realität: PHP steckt in CMS-Installationen, ERP-Systemen, Buchungsplattformen und Eigenentwicklungen, oft ohne zentrale Dokumentation.

SW Business Solutions führt eine technische Bestands- und Risikoprüfung der erreichbaren PHP-Systeme durch: Version, SAPI, Exposition und Konfiguration werden erfasst und gegen die bekannten Angriffspfade von CVE-2026-109618 und CVE-2026-109619 bewertet. Das Ergebnis ist eine priorisierte Maßnahmenliste — mit konkreter Unterscheidung zwischen sofort kritischen Systemen und solchen, bei denen Zeit für ein kontrolliertes Update bleibt.

Unsere Arbeit im Bereich IT-Sicherheit umfasst genau solche technischen Prüfungen: strukturierte Bestandsaufnahme, Risikobewertung und Unterstützung bei der Umsetzung. Wer lieber einen vollständigen Überblick über seine IT-Sicherheitslage haben möchte, kann auch unsere Managed IT-Services für den Mittelstand als dauerhaften Rahmen nutzen — damit solche Sicherheitsmeldungen nicht mehr als Überraschung ankommen.

Wenn Sie WordPress-basierte Systeme betreiben, lesen Sie ergänzend unseren Artikel zu WordPress-Sicherheit: Auch dort sind PHP-Versionen und Update-Prozesse zentrale Sicherheitsfaktoren.

Die entscheidende Frage: Welche Ihrer PHP-Systeme sind wirklich exponiert?

CVE-2026-109618 und CVE-2026-109619 sind ernst — aber nicht jede PHP-Installation trägt dasselbe Risiko. Wer jetzt strukturiert vorgeht, kann kritische Systeme sofort absichern und weniger exponierte Systeme kontrolliert nachziehen. Wer pauschal handelt, riskiert entweder unnötige Ausfälle oder — schlimmer — eine falsche Entwarnung.

Der erste Schritt ist eine vollständige Bestandsaufnahme: Welche PHP-Version läuft wo, mit welchem SAPI, und ist das System aus dem Internet erreichbar? Wenn diese Daten nicht vollständig vorliegen, ist das die eigentliche Dringlichkeit.

Lassen Sie Ihre PHP-Systeme technisch prüfen — bevor ein Angreifer das für Sie übernimmt. Sprechen Sie uns an: unverbindlich, konkret und ohne Werbedruck.