PHP2Shell: Kritische Schwachstellen im PHP-Kern (CVE-2026-109618 & CVE-2026-109619)

1. Ausgangslage, Management Summary und Steckbrief der Schwachstellen

Am 21. Oktober 2026 hat das Entwicklerteam der Skriptsprache PHP (Hypertext Preprocessor) gemeinsam mit den meldenden Forschungsteams, unter anderem von Calif, Wiz Research und OpenAI, außerplanmäßige Sicherheitsaktualisierungen für zwei schwerwiegende Schwachstellen im Kern der PHP-Laufzeitumgebung bereitgestellt. Die ursprünglich für den 22. Oktober geplante koordinierte Veröffentlichung wurde um einen Tag vorgezogen, nachdem Details bereits am 20. Oktober 2026 vorzeitig öffentlich geworden waren. Die beiden Schwachstellen werden im Verzeichnis bekannter Schwachstellen, dem Common Vulnerabilities and Exposures (CVE), unter den Kennungen CVE-2026-109618 und CVE-2026-109619 geführt und in der Fachöffentlichkeit zusammenfassend als „PHP2Shell“ bezeichnet.

Im Unterschied zu herkömmlichen Verwundbarkeiten in Webanwendungen, die meist auf Programmierfehler in einzelnen Content-Management-Systemen (CMS), Webshop-Erweiterungen oder individuell entwickelten Skripten zurückgehen, liegen CVE-2026-109618 und CVE-2026-109619 unmittelbar in der Laufzeitumgebung von PHP (php-src), die in der Programmiersprache C entwickelt ist.

Für die Unternehmensführung und die IT-Verantwortlichen ergibt sich daraus eine besondere Tragweite: Die fehlerhafte Speicherverarbeitung tritt bereits während der Entgegennahme und Aufbereitung eingehender HTTP-Anfragen (Hypertext Transfer Protocol) auf, insbesondere bei der Verarbeitung mehrteiliger Formulardaten (multipart/form-data) und der Sitzungsverfolgung für Datei-Uploads. Dieser Vorgang findet in der Laufzeitumgebung statt, bevor die erste Zeile des eigentlichen PHP-Anwendungscodes ausgeführt wird. Selbst Webanwendungen, deren Quellcode fachlich fehlerfrei programmiert ist oder die auf Anwendungsebene eine vorgeschaltete Benutzeranmeldung verlangen, sind auf ungepatchten Systemen angreifbar. Das gilt auch für Systeme auf Basis weit verbreiteter Plattformen und Frameworks wie WordPress, Typo3, Drupal, Joomla, Magento, Shopware, Laravel, Symfony und Nextcloud, sofern sie auf einer nicht bereinigten PHP-Version laufen. Das höchste Risiko besteht nach Einschätzung des PHP-Sicherheitsteams bei Webservern mit dem Apache-Modul mod_php.

1.1 Strukturierter Steckbrief zu CVE-2026-109618 und CVE-2026-109619

Die nachfolgende Übersicht fasst die technischen und organisatorischen Kerndaten der beiden Schwachstellen auf Basis der offiziellen Sicherheitsbekanntmachungen zusammen:

2. Regulatorischer Rahmen und Bedeutung für Leitungsorgane

Für Unternehmen, die Webserver, Kundenportale, E-Commerce-Systeme oder webbasierte Schnittstellen auf Basis von PHP betreiben, begründet die Veröffentlichung von CVE-2026-109618 und CVE-2026-109619 nicht nur einen operativen Handlungsbedarf in der IT-Abteilung. Sie berührt unmittelbar auch gesetzliche Sorgfalts-, Überwachungs- und Meldepflichten der Unternehmensführung.

2.1 Einordnung nach NISG 2026, NISV 2026 und Durchführungsverordnung (EU) 2024/2690

Für wesentliche und wichtige Einrichtungen im Anwendungsbereich des österreichischen Netz- und Informationssystemsicherheitsgesetzes 2026 (NISG 2026), das am 1. Oktober 2026 in Kraft getreten ist, ergeben sich folgende rechtliche Bezüge:

1. Pflichten zum Schwachstellen- und Patch-Management:
   Gemäß § 32 Abs. 4 lit. e NISG 2026 zählen Sicherheitsmaßnahmen bei der Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen einschließlich des Managements und der Offenlegung von Schwachstellen zu den gesetzlichen Mindestanforderungen. Über § 2 der Netz- und Informationssystemsicherheits-Verordnung (NISV 2026), BGBl. II Nr. 290/2026, gelten zudem die detaillierten technischen und methodischen Vorgaben des Anhangs der Durchführungsverordnung (EU) 2024/2690 für alle wesentlichen und wichtigen Einrichtungen. Diese verlangen strukturierte Prozesse zur zeitnahen Bewertung und Behebung kritischer Sicherheitslücken auf exponierten Systemen.

2. Überwachungspflicht der Leitungsorgane:
   Gemäß § 31 Abs. 1 NISG 2026 haben die Leitungsorgane (Geschäftsführung, Vorstand) die Umsetzung der Risikomanagementmaßnahmen nach § 32 zu billigen und deren Einhaltung laufend zu überwachen. Während die technische Einspielung von Sicherheitsupdates an die interne IT-Abteilung oder einen externen Managed Service Provider (MSP) delegiert wird, verbleibt die aufsichtsrechtliche Letztverantwortung beim Leitungsorgan. Bei kritischen Schwachstellen mit einem Wert von 9.2 nach dem Common Vulnerability Scoring System (CVSS) empfiehlt es sich für die Geschäftsführung, einen schriftlichen Umsetzungs- und Statusbericht der IT-Verantwortlichen einzufordern und zu dokumentieren.

3. Sicherheit der Lieferkette:
   Werden PHP-basierte Kundenportale, Webshops oder Schnittstellen durch externe Agenturen, Hosting-Anbieter oder Systemhäuser betrieben, fällt die Koordination der zeitnahen Bereinigung unter die Steuerung der Lieferkettensicherheit gemäß § 32 Abs. 4 lit. d NISG 2026.

4. Meldepflichten bei eingetretener Kompromittierung:
   Sollte im Zuge der Log-Prüfung (siehe Abschnitt 7) festgestellt werden, dass ein System bereits erfolgreich über CVE-2026-109618 oder CVE-2026-109619 kompromittiert wurde, ist unverzüglich zu prüfen, ob ein erheblicher Cybersicherheitsvorfall gemäß § 35 NISG 2026 in Verbindung mit § 5 Abs. 1 NISV 2026 vorliegt (insbesondere bei einem mutmaßlich böswilligen, unbefugten Zugriff auf Netz- und Informationssysteme, der geeignet ist, schwerwiegende Betriebsstörungen zu verursachen, oder bei einem Abfluss von Geschäftsgeheimnissen). In diesem Fall greift das mehrstufige Meldeverfahren nach § 34 NISG 2026 gegenüber dem zuständigen sektorspezifischen Computer Security Incident Response Team (CSIRT), ersatzweise dem nationalen CSIRT (Frühwarnung binnen 24 Stunden, Vorfallsmeldung binnen 72 Stunden, Abschlussbericht spätestens einen Monat nach der Vorfallsmeldung). Die Fristen laufen ab Kenntnisnahme des Vorfalls.

2.2 Bezüge zu DSGVO, Cyber Resilience Act (CRA) und ISO/IEC 27001:2022

Auch für Unternehmen außerhalb des direkten Anwendungsbereichs des NISG 2026 bestehen verbindliche Vorgaben:

• Datenschutz-Grundverordnung (DSGVO): Gemäß Art. 32 DSGVO sind Verantwortliche und Auftragsverarbeiter verpflichtet, technische und organisatorische Maßnahmen (TOMs) zu treffen, um ein dem Risiko angemessenes Schutzniveau für personenbezogene Daten zu gewährleisten. Da beide Schwachstellen zur Codeausführung und zum Auslesen von Arbeitsspeicherinhalten genutzt werden können, kann eine erfolgreiche Ausnutzung zu einer Verletzung des Schutzes personenbezogener Daten führen. Diese ist vom Verantwortlichen gemäß Art. 33 DSGVO binnen 72 Stunden ab Kenntnis an die österreichische Datenschutzbehörde (DSB) zu melden, sofern sie voraussichtlich zu einem Risiko für die Rechte und Freiheiten der betroffenen Personen führt. Bei voraussichtlich hohem Risiko sind zusätzlich die betroffenen Personen gemäß Art. 34 DSGVO zu benachrichtigen.
• Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847): Für Hersteller von Produkten mit digitalen Elementen, die eine eingebettete PHP-Laufzeitumgebung ausliefern (beispielsweise in Administrations-Weboberflächen von Routern, Speichersystemen, Gebäudeleittechnik oder Industriesteuerungen), gelten seit dem 11. September 2026 die Meldepflichten nach Art. 14 CRA: Erlangt der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle in seinem Produkt, sind eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme an das als Koordinator benannte CSIRT und die ENISA zu übermitteln. Da für PHP2Shell bereits Angriffe beobachtet werden, sollten Hersteller ihre Produkte zeitnah anhand der Software-Stückliste (Software Bill of Materials, SBOM) prüfen. Die Anforderungen an die Schwachstellenbehandlung nach Anhang I Teil II CRA gelten dagegen erst ab dem 11. Dezember 2027.
• ISO/IEC 27001:2022: Im Rahmen eines zertifizierten Informationssicherheits-Managementsystems (ISMS) adressiert Control 8.8 (Management technischer Schwachstellen) die zeitnahe Identifikation, Risikobewertung und Behebung veröffentlichter Schwachstellen. In der Praxis werden dafür interne Behebungsfristen nach Schweregrad festgelegt.

3. Technische Analyse der Ursache im PHP-Laufzeitkern

Für die fachliche Beurteilung der Abwehrmaßnahmen ist es hilfreich nachzuvollziehen, wie der PHP-Interpreter Arbeitsspeicher verwaltet und weshalb die eingesetzte Fehlerbehandlung bei Speichererschöpfung zu einem inkonsistenten Systemzustand führt.

3.1 Speicherverwaltung und Fehlerabbruch über zend_bailout und longjmp

PHP nutzt zur Verwaltung des Arbeitsspeichers eine eigene Komponente, den Zend Memory Manager (ZendMM). Für jede eingehende HTTP-Anfrage stellt ZendMM einen isolierten Speicherbereich (Request-Heap) bereit. Im regulären Betrieb werden sämtliche über interne Funktionen wie emalloc() reservierten Speicherblöcke am Ende der Anfrage automatisch freigegeben, damit nachfolgende Anfragen in einem bereinigten Zustand starten.

Überschreitet eine Anfrage jedoch während der Verarbeitung die konfigurierte Speicherobergrenze (memory_limit), erreicht sie die maximale Ausführungszeit (max_execution_time) oder tritt ein schwerwiegender interner Fehler auf, bricht die Zend Engine die Verarbeitung über die Funktion zend_bailout() ab:

/* Vereinfachte Darstellung des Fehlerabbruchs in der Zend Engine */
ZEND_API ZEND_COLD void _zend_bailout(const char *filename, uint32_t lineno) {
    if (!EG(bailout)) {
        zend_output_debug_string(1, "%s(%d) : Bailed out without a bailout address.", filename, lineno);
        exit(-1);
    }
    CG(unclean_shutdown) = 1;
    longjmp(*EG(bailout), FAILURE);
}

Die technische Schwachstelle des longjmp()-Mechanismus:
Die C-Standardfunktion longjmp() setzt den Befehlszähler und den Stapelspeicher (Call-Stack) unmittelbar auf einen zuvor definierten Auffangpunkt (zend_try / zend_catch, etwa beim Start der Anfrage oder der Skriptausführung) zurück. Dieses Vorgehen hat drei sicherheitsrelevante Konsequenzen:

1. Ausbleiben lokaler Aufräumroutinen: Sämtliche C-Funktionen, die sich zum Zeitpunkt der Speichererschöpfung in der Ausführung befanden, werden unvermittelt verlassen. Lokale Fehlerbehandlungs- oder Rücksetzschritte am Ende dieser Funktionen werden nicht mehr durchlaufen.
2. Unvollständig initialisierte Datenstrukturen: Wird eine C-Funktion während einer mehrstufigen Speicheroperation unterbrochen, etwa beim Einfügen eines Eintrags in eine interne Tabelle (HashTable), beim Einlesen einer mehrteiligen HTTP-Anfrage oder beim Aktualisieren von Sitzungsdaten, verbleibt die betroffene Datenstruktur in einem unvollständigen Zwischenzustand.
3. Fehlannahme in der Abschlussroutine der Anfrage: Unmittelbar nach dem Rücksprung über longjmp() leitet PHP die reguläre Abschlusssequenz der Anfrage (php_request_shutdown) ein. Diese Routine durchläuft die internen Tabellen, Sitzungsvariablen und Erweiterungsmodule, um deren Speicher freizugeben. Sie setzt dabei voraus, dass alle verknüpften Zeiger (Pointer) und Zählerstände valide sind.

3.2 Detailanalyse CVE-2026-109618: Speicherkorruption bei Speichererschöpfung (Out-of-Memory)

CVE-2026-109618 betrifft die beschriebene Unterbrechung durch longjmp() während der frühen Aufbereitung von HTTP-Anfragen, insbesondere beim Einlesen von multipart/form-data-Formulardaten und Datei-Uploads (spezifiziert nach Request for Comments [RFC] 1867 in der Quelldatei main/rfc1867.c) sowie beim Aufbau der globalen Anfragevariablen ($_POST, $_FILES). Laut Advisory ist in einigen dieser Abläufe Anfragespeicher vorübergehend erreichbar, bevor er vollständig initialisiert ist. Schlägt genau in diesem Moment eine Speicheranforderung fehl, bleibt der Anfragespeicher in einem ungültigen Zustand zurück, den die Abschlussroutine anschließend weiterverarbeitet.

Voraussetzungen laut Advisory

• Angreiferkontrollierte Multipart-Eingaben, die den Speicherverbrauch bis an die Grenze treiben, etwa Anfragen ohne verwertbare Längenangabe, eine unbegrenzte Anzahl von Kopfzeilen je Multipart-Teil, leere Datei-Felder (diese werden nicht auf max_file_uploads angerechnet) oder verschachtelte Feldnamen.
• Eine Serverumgebung, die nach einem fehlgeschlagenen Anfragestart die Abschlussroutine durchläuft: Apache mod_php tut dies stets. PHP-FPM beendet den Kindprozess bei einem Startfehler, weshalb die Ausnutzung dort weniger gesichert ist. FrankenPHP gilt als wahrscheinlich betroffen, LiteSpeed (LSAPI) ist nicht abschließend geprüft.
• Die vollständige Codeausführung wurde gegen mod_php mit Standardlimits und Prefork-Arbeitsprozessen nachgewiesen.

Technischer Ablauf der Zustandsverfälschung

Beim Einlesen komplexer Anfragedaten werden im C-Quellcode von PHP häufig zweistufige Speicherreservierungen vorgenommen:

• Erster Schritt (Reservierung des Eintrags): In einer internen Verwaltungsstruktur (beispielsweise einem Array oder einer HashTable) wird der Zähler der aktiven Elemente bereits um eins erhöht (count++ bzw. nNumUsed++) oder ein Tabellenplatz als belegt gekennzeichnet, bevor der zugehörige Datenpuffer für den Inhalt zugewiesen ist. Das Zeigerfeld in diesem neuen Eintrag enthält zu diesem Zeitpunkt noch nicht überschriebene Restdaten aus früheren Speicherbelegungen auf dem Heap.
• Zweiter Schritt (Zuweisung des Zielpuffers): Unmittelbar danach wird emalloc() oder estrdup() aufgerufen, um den Arbeitsspeicher für den eigentlichen Wert (z. B. den Dateinamen oder Parameterinhalt) anzufordern.

Konstruiert ein Angreifer eine HTTP-Anfrage durch gezielte Vorbelegung des Speichers (sogenanntes Heap Grooming) genau so, dass der erste Schritt noch ausgeführt wird, die Speicheranforderung im zweiten Schritt jedoch die Grenze von memory_limit überschreitet, tritt folgender Zustand ein:

/* Konzeptionelles Code-Muster zur Veranschaulichung von CVE-2026-109618 */
void vulnerable_multipart_parser_step(custom_container *container, const char *input, size_t len) {
    /* 1. Der Elementzähler wird bereits erhöht und der Slot als aktiv markiert */
    size_t idx = container->count++;

    /* 2. Überschreitet emalloc() an dieser Stelle das memory_limit, löst zend_bailout()
     *    sofort ein longjmp() aus. Das Feld container->items[idx].ptr bleibt uninitialisiert,
     *    obwohl container->count bereits den erhöhten Wert aufweist. */
    container->items[idx].ptr = emalloc(len + 1);
    memcpy(container->items[idx].ptr, input, len);
}

Auswirkung beim Bereinigen der Anfrage

1. Durch den Sprung über longjmp() wechselt der Interpreter direkt in die Aufräumphase (php_request_shutdown).
2. Die Bereinigungsroutine durchläuft alle Einträge von 0 bis container->count - 1 und ruft für jeden gespeicherten Zeiger die Freigabefunktion efree() oder eine zugehörige Destruktor-Funktion auf.
3. Da das Zeigerfeld des letzten Eintrags vor dem Abbruch nicht mehr beschrieben wurde, interpretiert die Aufräumroutine die dort liegenden Restbytes auf dem Heap als gültige Speicheradresse.
4. Hat der Angreifer diese Speicherstelle zuvor über vorangegangene Anfragefelder mit kontrollierten Werten vorbelegt, kann der PHP-Prozess eine Speicherfreigabe an einer vom Angreifer beeinflussten Adresse (Arbitrary Free) auslösen. In Verbindung mit weiteren Techniken, etwa zur Umgehung der zufälligen Adressraumanordnung, lässt sich dies zur Ausführung beliebigen Programmcodes im Kontext des Webserver-Prozesses ausbauen. Der dafür nötige Aufwand spiegelt sich in der hohen Angriffskomplexität (AC:H) der CVSS-Bewertung wider.

3.3 Detailanalyse CVE-2026-109619: Veralteter globaler Status und Cross-Request Use-After-Free

Während CVE-2026-109618 innerhalb derselben HTTP-Anfrage beim Abschluss wirksam wird, nutzt CVE-2026-109619 aus, dass PHP-Arbeitsprozesse in vielen Serverumgebungen über mehrere Anfragen hinweg bestehen bleiben. Beim Apache-Modul mod_php (Prefork), beim FastCGI Process Manager (PHP-FPM) oder bei FrankenPHP verarbeiten die einzelnen Arbeitsprozesse (Worker) nacheinander hunderte oder tausende Anfragen.

Bestätigt ist die Codeausführung laut Advisory gegen mod_php. Dort werden verzeichnisbezogene Einstellungen aus .htaccess-Dateien (php_value, php_flag, php_admin_*) bereits vor dem regulären Anfragestart angewendet. PHP-FPM ist nur unter bestimmten Bedingungen exponiert, für FrankenPHP in der Standardkonfiguration wurde kein früher Zugriffspfad nachgewiesen.

Modulweiter Status und anfragegebundener Speicher

Innerhalb eines persistenten PHP-Arbeitsprozesses existieren zwei Arten von Speicherbereichen mit unterschiedlicher Lebensdauer:

• Anfragegebundener Speicher (Request-Heap): Wird durch den ZendMM verwaltet und am Ende jeder einzelnen HTTP-Anfrage vollständig zurückgesetzt.
• Modulweiter globaler Status: Variablen von Kernmodulen (etwa die Struktur PS(...) im Sitzungsmodul ext/session) bleiben über die gesamte Lebensdauer des Betriebssystemprozesses erhalten. Sie müssen daher am Ende jeder Anfrage über definierte Abschlussroutinen (RSHUTDOWN) bereinigt werden.

Laut Advisory verweist dieser modulweite Status (Fehler-, Sitzungs-, Objekt- und Erweiterungsstatus) teilweise auf Speicher, der der jeweiligen Anfrage gehört, und wird nicht in jedem Fall zurückgesetzt, bevor der Request-Heap freigegeben wird.

Ein bestätigter Angriffspfad führt über die Funktion zur Überwachung des Upload-Fortschritts (session.upload_progress.enabled = 1), die in den Standardkonfigurationen von PHP ab Werk aktiviert ist. Übermittelt ein Client eine multipart/form-data-Anfrage, die ein Formularfeld mit dem Namen PHP_SESSION_UPLOAD_PROGRESS enthält, ruft PHP noch während des Einlesens des Datenstroms (also vor dem Start des Anwendungsskripts) die Rückruffunktion des Sitzungsmoduls (php_session_rfc1867_callback in ext/session/session.c) auf. Diese greift dabei auf den modulweiten Status zu, bevor die Anfrage regulär initialisiert ist.

Der zweistufige Angriffspfad über aufeinanderfolgende Anfragen

1. Erste Anfrage (Erzeugen des veralteten Zustands):
   * Der Angreifer löst gezielt einen schwerwiegenden Fehler (Fatal Error) aus, während der modulweite Status auf anfragegebundenen Speicher verweist. Als Auslöser nennt das Advisory unter anderem Parse- und Kompilierfehler, nicht abgefangene Fehler, fehlgeschlagene require-Aufrufe, Zeitüberschreitungen, Speichererschöpfung sowie Diagnosemeldungen während des Abschlusses der Anfrage.
   * Bestätigt ist dieser Schritt für die Erzeugung von Fehler-Aufrufstapeln über die mit PHP 8.5 eingeführte Option fatal_error_backtraces.
   * Durch den Abbruch über zend_bailout() und longjmp() unterbleibt das Zurücksetzen des globalen Status. Am Ende der ersten Anfrage gibt der ZendMM zwar den gesamten Request-Heap frei, der globale Verweis im Arbeitsprozess zeigt jedoch weiterhin auf die nunmehr freigegebene Speicheradresse (Dangling Pointer).
2. Zweite Anfrage (Nutzung im selben Arbeitsprozess):
   * Derselbe Arbeitsprozess übernimmt eine nachfolgende HTTP-Anfrage des Angreifers.
   * Bevor der globale Status neu initialisiert wird, greift eine früh ausgeführte Routine auf den veralteten Verweis zu. Bestätigt sind laut Advisory die Verarbeitung des Upload-Fortschritts (PHP_SESSION_UPLOAD_PROGRESS) sowie Diagnosemeldungen aus INI-Einstellungen, die vor dem Anfragestart angewendet werden. Die Zieladresse im Request-Heap ist inzwischen durch Daten der zweiten Anfrage neu belegt (Cross-Request Use-After-Free, CWE-416).
   * Durch gezielte Platzierung von Nutzdaten in der zweiten Anfrage kann der Angreifer an dieser Speicheradresse manipulierte interne Strukturen hinterlegen und dadurch fremde Speicherinhalte auslesen oder, mit erheblichem Zusatzaufwand, eigenen Programmcode zur Ausführung bringen.
   * Mehrere parallele Arbeitsprozesse und deren regelmäßige Erneuerung senken die Erfolgsquote, beseitigen die Angriffsmöglichkeit aber nicht.

4. Geschäftliche und technische Auswirkungen bei einer Ausnutzung

Da beide Schwachstellen in der Vorverarbeitungsphase der PHP-Laufzeitumgebung ausgelöst werden, bieten Sicherheitskontrollen innerhalb der jeweiligen Webanwendung (wie Anmeldemasken, Rollenprüfungen oder Sicherheits-Plugins in einem CMS) keinen Schutz vor dem initialen Zugriff. Gleiches gilt für die Wartungsmodi von CMS und Shopsystemen, da PHP die Anfrage bereits vor deren Auswertung verarbeitet.

4.1 Unauthentifizierte entfernte Codeausführung (Remote Code Execution)

Bei einer erfolgreichen Ausnutzung erlangt ein externer Angreifer die Möglichkeit, beliebige Systembefehle mit den Berechtigungen des Webserver- oder PHP-FPM-Dienstkontos (unter Linux-Distributionen in der Regel www-data, apache oder nginx) auf dem betroffenen Server auszuführen. Daraus resultieren weitreichende Folgerisiken:

• Kompromittierung von Zugangsdaten und kryptografischen Schlüsseln: Der Angreifer kann Konfigurationsdateien der Anwendung (wie .env, wp-config.php oder parameters.yml) auslesen. Darin befinden sich regelmäßig Zugangsdaten zu Datenbankservern, API-Schlüssel (Application Programming Interface) für Zahlungsdienstleister, Cloud-Zugangstoken sowie private Schlüssel.
• Zugriff auf angebundene Datenbanken und Kernsysteme: Mit den erlangten Datenbank-Zugangsdaten können Kundenstammdaten, Bestellhistorien, Rechnungsdaten und Geschäftsgeheimnisse vollständig kopiert, verändert oder gelöscht werden.
• Manipulation der Anwendung und Lieferkettenangriffe: Angreifer können unbemerkt Schadcode in den ausgelieferten Programmcode einfügen (beispielsweise zum Abgreifen von Zahlungsdaten im Bestellprozess von Online-Shops) oder das kompromittierte System als Ausgangspunkt für weiterführende Angriffe (Lateral Movement) in das interne Unternehmensnetzwerk nutzen.
• Dateilose Verankerung im Arbeitsspeicher: Da der Zugriff direkt im Prozessspeicher des PHP-Interpreters erfolgt, ist es denkbar, dass Angreifer Schadfunktionen in den laufenden Arbeitsprozess oder den gemeinsamen Speicherbereich (Shared Memory) des Bytecode-Caches (OPcache) einbringen, ohne eine klassische Hintertür-Datei (Webshell) auf der Festplatte abzulegen. Eine solche Verankerung geht mit dem Neustart der Arbeitsprozesse verloren.

4.2 Unbefugtes Auslesen von Arbeitsspeicher über Sitzungsgrenzen hinweg

Selbst wenn ein Angreifer bei der Ausnutzung der Schwachstellen keine Befehlsausführung anstrebt, kann der Zugriff auf freigegebene Speicherbereiche das Auslesen von Datenfragmenten ermöglichen, die aus vorangegangenen HTTP-Anfragen anderer regulärer Benutzer im selben Arbeitsprozess stammen. Hierdurch können insbesondere folgende Informationen abfließen:

• Aktive Sitzungskennungen (PHPSESSID), JSON Web Tokens (JWT) und Authentifizierungs-Header fremder Benutzer, was eine direkte Übernahme fremder Benutzersitzungen (Session Hijacking) ermöglicht.
• Kennwörter aus Anmeldeformularen und sonstige Formulardaten, die kurz zuvor vom selben Arbeitsprozess verarbeitet wurden (nach der TLS-Entschlüsselung liegen diese im Arbeitsspeicher im Klartext vor).
• Personenbezogene Daten (unter anderem besondere Kategorien personenbezogener Daten gemäß Art. 9 DSGVO bei Portalen im Gesundheitswesen) sowie vertrauliche Unternehmensdaten.

4.3 Beeinträchtigung der Verfügbarkeit (Denial of Service) und Folgerisiken

Speicherkorruptionsangriffe und automatisierte Schwachstellenscans führen bei abweichenden Speicheradressen (etwa infolge der zufälligen Anordnung des Adressraums durch Address Space Layout Randomization [ASLR]) häufig zu Speicherzugriffsverletzungen des jeweiligen Arbeitsprozesses. Das Betriebssystem beendet den betroffenen Prozess daraufhin mit dem Signal SIGSEGV (Segmentation Fault). Treffen zahlreiche derartige Anfragen gleichzeitig auf den Server, stürzen die verfügbaren PHP-FPM-Arbeitsprozesse rascher ab, als der übergeordnete Verwaltungsprozess neue Instanzen nachstarten kann. Für Kunden und Geschäftspartner ist der Webdienst in dieser Zeit nicht mehr erreichbar (502 Bad Gateway oder 504 Gateway Timeout), was zu unmittelbaren Umsatzeinbußen und Reputationsschäden führen kann.

5. Strukturierte Schutzmaßnahmen, Patch-Management und Härtung

5.1 Primäre Maßnahme: Aktualisierung der PHP-Laufzeitumgebung

Die PHP Group hat am 21. Oktober 2026 korrigierte Versionen für alle unterstützten Entwicklungszweige veröffentlicht. Laut Changelog beheben diese beide Schwachstellen unter dem Eintrag „Avoid state corruption via bailout“: Zustände, die bei einem Abbruch über zend_bailout() inkonsistent zurückbleiben konnten, werden abgesichert.

Hinweis zu Distributionspaketen und Hersteller-Trackern:
Debian, Ubuntu und RHEL-Derivate portieren Sicherheitskorrekturen in ihre eigenen Paketversionen zurück, ohne die PHP-Versionsnummer anzuheben (Ubuntu 24.04 LTS liefert beispielsweise PHP 8.3.6). Ob ein System bereinigt ist, lässt sich daher nicht allein über php -v anhand der obigen Tabelle beurteilen. Maßgeblich sind die Sicherheitshinweise des jeweiligen Herstellers (DSA, DLA, USN, RHSA) und die dort genannte Paketversion:

• Debian Security Tracker: CVE-2026-109618 | CVE-2026-109619
• Ubuntu Security: CVE-2026-109618 | CVE-2026-109619
• Red Hat Customer Portal: CVE-2026-109618 | CVE-2026-109619

Erforderlicher Neustart der Dienste nach der Aktualisierung:
Nach dem Einspielen der aktualisierten Betriebssystempakete müssen sämtliche persistenten PHP-Dienste neu gestartet werden, bei mod_php also der Apache-Webserver. Andernfalls verbleiben die verwundbaren Programmversionen weiterhin im Arbeitsspeicher aktiv:

# Beispiel für Debian- und Ubuntu-Server
sudo apt-get update && sudo apt-get install --only-upgrade 'php*'

# Installierte Paketversionen mit dem Sicherheitshinweis des Herstellers abgleichen
dpkg -l 'php*' | grep '^ii'

# Vorhandene PHP-Dienste ermitteln und neu starten
systemctl list-units --type=service 'php*'
sudo systemctl restart php8.4-fpm   # bzw. php8.2-fpm, php8.3-fpm, php8.5-fpm
sudo systemctl restart apache2      # erforderlich bei mod_php

5.2 Kurzfristige Konfigurationsmaßnahmen zur Risikoreduktion (Übergangsmaßnahmen)

Sofern auf einzelnen Produktivsystemen vor der Einspielung des Software-Updates ein Wartungsfenster oder ein Kompatibilitätstest erforderlich ist, sollten durch den IT-Betrieb oder den betreuenden IT-Dienstleister zeitnah folgende Härtungsmaßnahmen in der PHP-Konfiguration umgesetzt werden:

1. Administratives Erzwingen von memory_limit = -1 (Primäre Konfigurationsmaßnahme zu CVE-2026-109618)

Laut Advisory ist das administrativ erzwungene Aufheben des Speicherlimits die wichtigste Konfigurationsmaßnahme gegen CVE-2026-109618: Ohne Grenzwert kommt es beim Einlesen der Anfrage nicht mehr zum Abbruch über zend_bailout() an der Speichergrenze. Die Maßnahme ist allerdings nicht vollständig und verlagert das Risiko auf die Verfügbarkeit, da ein einzelner Prozess nun den gesamten Arbeitsspeicher belegen kann. Sie sollte daher mit einer Speichergrenze auf Ebene der Control Groups (cgroup memory.max, etwa über systemd oder Container-Limits) kombiniert werden, die bei Überschreitung den Prozess beendet, statt Speicheranforderungen fehlschlagen zu lassen.

; php.ini
memory_limit = -1

; PHP-FPM-Pool (z. B. /etc/php/8.3/fpm/pool.d/www.conf): nicht durch Anwendungen oder .user.ini überschreibbar
php_admin_value[memory_limit] = -1

; Apache mod_php (Server- oder VirtualHost-Konfiguration, nicht über .htaccess überschreibbar)
php_admin_value memory_limit -1

# Speichergrenze für den PHP-FPM-Dienst über systemd (cgroup memory.max)
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryMax=4G

Prozessgrenzen über RLIMIT_AS oder RLIMIT_DATA (etwa ulimit -v oder LimitAS= in systemd) sind dagegen zu vermeiden: Sie lassen Speicheranforderungen fehlschlagen und lösen damit genau den verwundbaren Pfad aus.

2. Deaktivierung von session.upload_progress auf Serverebene (Adressiert einen bestätigten Pfad von CVE-2026-109619)

Durch das Abschalten der Upload-Fortschrittsverfolgung wird unterbunden, dass eingehende Multipart-Anfragen mit dem Parameter PHP_SESSION_UPLOAD_PROGRESS vor dem Start des Anwendungsskripts auf den veralteten Status im Sitzungsmodul zugreifen. Das Advisory empfiehlt, die Funktion auch nach dem Update deaktiviert zu lassen, sofern sie nicht benötigt wird. Die Maßnahme allein reicht jedoch nicht aus.

Konfiguration in der zentralen php.ini (z. B. /etc/php/8.3/fpm/php.ini):

[Session]
session.upload_progress.enabled = Off
session.upload_progress.cleanup = On

Erzwingung in der PHP-FPM-Pool-Konfiguration (z. B. /etc/php/8.3/fpm/pool.d/www.conf) bzw. in der Apache-Konfiguration bei mod_php:
Durch die Verwendung von php_admin_flag wird zusätzlich ausgeschlossen, dass die Einstellung durch verzeichnisspezifische .user.ini-Dateien (PHP-FPM) bzw. .htaccess-Dateien (mod_php) wieder aktiviert werden kann:

; PHP-FPM-Pool
php_admin_flag[session.upload_progress.enabled] = off

; Apache mod_php
php_admin_flag session.upload_progress.enabled off

3. Deaktivierung von fatal_error_backtraces unter PHP 8.5 (Adressiert den bestätigten Auslöser von CVE-2026-109619)

Unter PHP 8.5 beseitigt das Abschalten der Fehler-Aufrufstapel bei Fatal Errors laut Advisory den bestätigten Auslöser der Codeausführung über CVE-2026-109619:

; php.ini (nur PHP 8.5)
fatal_error_backtraces = Off

4. Restriktive Begrenzung von Anfragegröße und Multipart-Parametern (Erschwert die Ausnutzung von CVE-2026-109618)

Um es Angreifern zu erschweren, über eine große Anzahl von Multipart-Segmenten, Kopfzeilen oder verschachtelten Feldnamen den Speicherverbrauch gezielt in die Höhe zu treiben, sollten die Ressourcenlimits auf das betrieblich notwendige Maß reduziert werden. Das Advisory empfiehlt zudem, die tatsächliche (dekodierte) Größe des Anfragekörpers bereits am vorgelagerten Webserver oder Proxy zu begrenzen:

; Empfohlene Härtungsparameter in der php.ini (Werte an die eigenen Formulare anpassen)
file_uploads = On                  ; Auf 'Off' setzen, sofern die Anwendung keine Datei-Uploads benötigt
upload_max_filesize = 10M          ; Auf das fachlich erforderliche Minimum begrenzen
post_max_size = 12M                ; Konservativ, geringfügig oberhalb von upload_max_filesize ansetzen
max_file_uploads = 5               ; Standardwert 20; leere Datei-Felder werden nicht mitgezählt
max_multipart_body_parts = 100     ; Anzahl der Segmente im Multipart-Body (ab PHP 8.0.28 / 8.1.16 / 8.2.3)
max_input_vars = 500               ; Standardwert 1000; nur senken, soweit die Formulare es zulassen
max_input_nesting_level = 16       ; Standardwert 64; begrenzt verschachtelte Feldnamen

Die Anzahl der Kopfzeilen je Multipart-Teil lässt sich in PHP nicht begrenzen; hier hilft nur eine vorgelagerte WAF oder ein Reverse-Proxy.

5. Erneuerung der Arbeitsprozesse

Das regelmäßige Ersetzen von Arbeitsprozessen senkt die Erfolgsquote von CVE-2026-109619, beseitigt die Schwachstelle aber nicht. Werte wie 200 Anfragen pro Prozess haben kaum Schutzwirkung, da der Angriff nur zwei aufeinanderfolgende Anfragen im selben Prozess benötigt. Das Advisory empfiehlt daher, sofern die Leistung es zulässt, jeden Arbeitsprozess nach einer einzigen Anfrage zu ersetzen:

; In /etc/php/*/fpm/pool.d/www.conf
pm.max_requests = 1

Bei Apache mit mod_php wirkt MaxConnectionsPerChild 1 vergleichbar, bezieht sich allerdings auf Verbindungen; über eine Keep-Alive-Verbindung können weiterhin mehrere Anfragen im selben Prozess landen.

6. Weitere Hinweise aus dem Advisory

• Durch Angreifer auslösbare Fatal Errors und Zeitüberschreitungen in der Anwendung beseitigen; Zeitüberschreitungen sind dabei wie Fatal Errors zu behandeln.
• Diagnosemeldungen aus INI-Einstellungen vermeiden, die vor dem Anfragestart angewendet werden (.htaccess, .user.ini), ebenso Meldungen beim Beenden von Erweiterungen und Diensten.
• Wo die Anwendung keine Multipart-Formulare benötigt, multipart/form-data-Anfragen bereits am Webserver oder an der WAF abweisen (siehe Abschnitt 6).
• Systeme, die sich nicht kurzfristig aktualisieren lassen, sollten nach Empfehlung von CERT-EU vom Internet getrennt werden oder vorübergehend nur eine statische Wartungsseite ausliefern.
• Nach jeder Konfigurationsänderung alle PHP-Arbeitsprozesse neu starten.

5.3 Typische Fehlannahmen bei der Absicherung und wie man sie vermeidet

In der betrieblichen Praxis treten bei vergleichbaren Laufzeitschwachstellen regelmäßig drei Fehlannahmen auf, die bei der Maßnahmenplanung berücksichtigt werden sollten:

1. Übersehen isolierter Container- und Nebensysteme: Häufig wird zwar der primäre Webserver aktualisiert, während PHP-Laufzeitumgebungen in Docker-Containern, internen Verwaltungsoberflächen (z. B. phpMyAdmin, Monitoring-Systeme) oder auf Entwicklungs- und Staging-Servern mit Anbindung an das interne Netz ungepatcht bleiben. Ein vollständiges Asset-Inventar gemäß ISO/IEC 27001 Control 5.9 ist daher Voraussetzung für eine wirksame Bereinigung.
2. Ausbleibender Neustart von PHP-FPM nach Konfigurationsänderungen: Änderungen an der php.ini oder das Einspielen neuer Pakete werden erst wirksam, wenn der Dienst php-fpm bzw. bei mod_php der Webserver neu gestartet wird.
3. Alleiniges Vertrauen auf Signaturfilter: Da CVE-2026-109618 über unterschiedlich aufgebaute HTTP-Anfragen ausgelöst werden kann, die eine Speichererschöpfung herbeiführen, kann eine Web Application Firewall zwar bekannte Standard-Exploits abfangen, ersetzt jedoch nicht die Korrektur des Speichermanagers im PHP-Binärprogramm.

6. Beispiele für Web-Application-Firewall- und Netzwerkschutzregeln

Als vorgelagerte Verteidigungsschicht (Virtual Patching) können Web Application Firewalls (WAF), Reverse-Proxys sowie Systeme zur Angriffserkennung (Intrusion Detection System [IDS] / Intrusion Prevention System [IPS]) verdächtige HTTP-Anfragen herausfiltern, bevor diese an den PHP-Interpreter weitergeleitet werden. Der Schwerpunkt liegt dabei auf dem Blockieren des Parameters PHP_SESSION_UPLOAD_PROGRESS sowie dem Abweisen fehlerhaft formatierter oder nicht benötigter multipart/form-data-Anfragen.

Die Signaturen adressieren vor allem den Upload-Progress-Pfad von CVE-2026-109619. Für CVE-2026-109618 gibt es kein eindeutiges Anfragemerkmal; hier wirken nur Größen- und Strukturgrenzen sowie das Abweisen nicht benötigter Multipart-Anfragen. Die Regeln blockieren zudem eine legitim genutzte Upload-Fortschrittsanzeige und sollten vor dem Produktivbetrieb im reinen Protokollmodus getestet werden.

6.1 ModSecurity, OWASP Core Rule Set und Coraza

Für Webserver (Apache, Nginx, IIS) mit integriertem ModSecurity (ab Version 2.9.6 bzw. libmodsecurity ab Version 3.0.8) oder Coraza können folgende Regeln eingebunden werden (Voraussetzung ist die aktivierte Prüfung des Anfragekörpers über SecRequestBodyAccess On). Die Regel-IDs liegen im für lokale Regeln vorgesehenen Bereich 1 bis 99.999 und sind bei Bedarf an das eigene Nummernschema anzupassen:

# =====================================================================
# WAF-Schutzregeln für CVE-2026-109619 (PHP2Shell, Upload-Progress-Pfad)
# =====================================================================

# Regel 1: Abweisen von POST-Anfragen, die den Parameter PHP_SESSION_UPLOAD_PROGRESS enthalten
SecRule ARGS_POST_NAMES|FILES_NAMES "@rx (?i)^php_session_upload_progress$" \
    "id:61901,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    t:none,\
    msg:'PHP2Shell Exploit-Versuch erkannt: Parameter PHP_SESSION_UPLOAD_PROGRESS (CVE-2026-109619)',\
    logdata:'Erkannter Parameter: %{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\
    severity:'CRITICAL',\
    tag:'application-multi',\
    tag:'language-php',\
    tag:'CVE-2026-109619'"

# Regel 2: Prüfung der Kopfzeilen der einzelnen Multipart-Teile auf PHP_SESSION_UPLOAD_PROGRESS
# Erfasst auch abweichende Schreibweisen im Content-Disposition-Header.
# Hinweis: In ModSecurity 2.x ist REQUEST_BODY bei multipart/form-data nicht befüllt; maßgeblich ist
# daher MULTIPART_PART_HEADERS (erfordert ModSecurity >= 2.9.6 bzw. libmodsecurity >= 3.0.8)
SecRule REQUEST_HEADERS:Content-Type "@rx (?i)multipart/form-data" \
    "id:61902,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    t:none,\
    chain,\
    msg:'PHP2Shell Exploit-Versuch erkannt: Multipart Upload Progress Trigger (CVE-2026-109619)',\
    severity:'CRITICAL',\
    tag:'CVE-2026-109619'"
    SecRule MULTIPART_PART_HEADERS "@rx (?i)name\s*=\s*[\"\']?PHP_SESSION_UPLOAD_PROGRESS[\"\']?" "t:none"

# Regel 3: Blockieren strukturell fehlerhafter Multipart-Anfragen
# Entspricht weitgehend Regel 200003 aus modsecurity.conf-recommended und ist nur zu ergänzen,
# falls diese nicht aktiv ist. Wohlgeformte Angriffsanfragen werden dadurch nicht erkannt.
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:61801,\
    phase:2,\
    deny,\
    status:400,\
    log,\
    t:none,\
    msg:'Multipart-Validierung fehlgeschlagen: strukturell fehlerhafte Anfrage',\
    logdata:'Multipart Strict Error: %{MULTIPART_STRICT_ERROR} (%{REQBODY_PROCESSOR_ERROR_MSG})',\
    severity:'CRITICAL',\
    tag:'multipart-strict'"

6.2 Cloudflare Web Application Firewall (Custom Rules)

Cloudflare hat für die bekannten Angriffsmuster eigene WAF-Regeln bereitgestellt, die für alle Kunden einschließlich des kostenfreien Tarifs gelten, bezeichnet diese aber selbst als Übergangslösung. Sie schützen nur Verkehr, der tatsächlich über Cloudflare geleitet wird; ein direkt erreichbarer Ursprungsserver bleibt angreifbar. Ergänzend lässt sich unter Security -> WAF -> Custom rules folgende benutzerdefinierte Filterregel mit der Aktion Block einrichten (setzt die Verfügbarkeit der Anfragekörper-Prüfung http.request.body.raw im jeweiligen Tarif voraus; der Anfragekörper wird nur bis zu einer tarifabhängigen Größe geprüft):

(
  http.request.method eq "POST" and
  lower(http.request.headers["content-type"][0]) contains "multipart/form-data" and
  lower(http.request.body.raw) contains "php_session_upload_progress"
)

Sofern eine Webanwendung auf bestimmten öffentlichen Pfaden (wie /login.php oder /xmlrpc.php) grundsätzlich keine Datei-Uploads entgegennimmt, empfiehlt es sich, multipart/form-data-Anfragen auf diese Pfade bereits an der WAF pauschal abzuweisen. Bei Anwendungen mit zentralem Einstiegspunkt (Front Controller, etwa Laravel, Symfony, Shopware oder Magento) laufen dagegen sämtliche Anfragen einschließlich der Uploads über index.php; eine pauschale Sperre dieses Pfads legt alle Uploads lahm.

6.3 Nginx Reverse-Proxy und Webserver-Härtung

Auf Systemen, die den Webserver Nginx ohne zusätzliches ModSecurity-Modul vor PHP-FPM einsetzen, kann die Angriffsfläche durch eine strikte Begrenzung der Anfragegröße sowie das Unterbinden von Multipart-Anfragen auf Endpunkten ohne Upload-Funktion verringert werden:

# 1. Begrenzung der maximal zulässigen Größe des HTTP-Anfragekörpers
client_max_body_size 12m;
client_body_buffer_size 128k;

# 2. Abweisen von multipart/form-data auf Skripten, die keine Datei-Uploads verarbeiten
#    (nicht auf den Front Controller index.php anwenden; die Regex-Location muss vor der
#    allgemeinen PHP-Location "location ~ \.php$" stehen, da Nginx die erste passende verwendet)
location ~ ^/(login|xmlrpc|api/auth)\.php$ {
    if ($content_type ~* "multipart/form-data") {
        return 403;
    }
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

# 3. Notmaßnahme bis zum Update, sofern vertretbar (bricht sämtliche Uploads und Multipart-Formulare):
#    im server-Block
if ($content_type ~* "multipart/form-data") {
    return 403;
}

6.4 Netzwerkerkennung mit Suricata (Intrusion Detection and Prevention)

Für die Überwachung des internen und externen Datenverkehrs durch ein Security Operations Center (SOC) kann folgende Suricata-Signatur eingesetzt werden, um Ausnutzungsversuche über das Sitzungsmodul zu protokollieren oder zu unterbinden. Die Signatur-ID liegt im für lokale Regeln üblichen Bereich 1.000.000 bis 1.999.999:

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any ( \
    msg:"LOCAL WEB_SERVER Possible PHP2Shell Exploit Attempt: PHP_SESSION_UPLOAD_PROGRESS in Multipart (CVE-2026-109619)"; \
    flow:established,to_server; \
    http.method; content:"POST"; \
    http.content_type; content:"multipart/form-data"; nocase; \
    http.request_body; content:"PHP_SESSION_UPLOAD_PROGRESS"; nocase; \
    classtype:web-application-attack; \
    reference:cve,2026-109619; \
    sid:1061901; \
    rev:1; \
)

Grenzen der Netzwerkerkennung:

• Bei HTTPS sieht Suricata den Anfrageinhalt nur, wenn der Sensor hinter der TLS-Terminierung (etwa zwischen Reverse-Proxy und Webserver) platziert ist oder der Verkehr anderweitig entschlüsselt wird.
• Suricata untersucht den Anfragekörper standardmäßig nur bis zur Größe von request-body-limit (Standardwert 100 KiB in der libhtp-Konfiguration). Angreifer können das Feld durch vorangestellte Fülldaten hinter diese Grenze verschieben; der Wert sollte daher an post_max_size angenähert werden.

7. Erkennung einer Kompromittierung und forensische Prüfschritte

Da die Ausnutzung von CVE-2026-109618 und CVE-2026-109619 innerhalb des C-Laufzeitkerns erfolgt, erscheinen erfolgreiche oder fehlgeschlagene Angriffe in der Regel nicht in den Anwendungsprotokollen des jeweiligen CMS oder Frameworks. Stattdessen hinterlassen sie charakteristische Kompromittierungsindikatoren, sogenannte Indicators of Compromise (IoC), in den Prozess-, Kernel- und Webserver-Protokollen.

7.1 Auswertung von Prozessabstürzen in System- und Kernel-Protokollen

Bei dem Versuch, über Speicherkorruption oder Use-After-Free-Zustände die Programmausführung zu übernehmen, treten aufgrund abweichender Speicheradressen häufig Abstürze einzelner PHP-Arbeitsprozesse mit einer Speicherzugriffsverletzung (Signal 11, SIGSEGV) oder einem Speicherverwaltungsabbruch (Signal 6, SIGABRT, oft begleitet von der Meldung zend_mm_heap corrupted) auf. Abstürze können auch harmlose Ursachen wie fehlerhafte Erweiterungen haben; sie sind ein Indiz, kein Beweis.

Überprüfung der Apache-Protokolldateien bei mod_php (höchstes Risiko laut Advisory):

# Debian/Ubuntu: /var/log/apache2/error.log*, RHEL: /var/log/httpd/error_log*
sudo zgrep -E "exit signal (Segmentation fault|Aborted)|zend_mm_heap corrupted" /var/log/apache2/error.log*

Überprüfung der PHP-FPM-Protokolldateien:

# Debian/Ubuntu: /var/log/php*-fpm.log*, RHEL: /var/log/php-fpm/error.log*
sudo zgrep -E "SIGSEGV|SIGABRT|signal 11|signal 6|core dumped|zend_mm_heap corrupted" /var/log/php*-fpm.log*

Beispiel für einen verdächtigen Protokolleintrag bei Ausnutzungsversuchen:

[21-Oct-2026 18:14:02] WARNING: [pool www] child 41892 exited on signal 11 (SIGSEGV) after 12.401823 seconds from start
[21-Oct-2026 18:14:03] WARNING: [pool www] child 41895 exited on signal 11 (SIGSEGV - core dumped) after 8.110492 seconds from start

Überprüfung der Linux-Kernel-Protokolle (dmesg und journalctl):

sudo dmesg -T | grep -iE "segfault|php-fpm|apache2|httpd"
sudo journalctl -k --since "7 days ago" | grep -iE "segfault.*php"

Beispiel für einen zugehörigen Kernel-Eintrag:

[Wed Oct 21 18:14:02 2026] php-fpm8.3[41892]: segfault at 7f9a40000018 ip 000055d8b1a4e210 sp 00007ffc8e1b2940 error 4 in php-fpm8.3[55d8b1800000+412000]

7.2 Identifikation verdächtiger Speichererschöpfung in PHP-Fehlerprotokollen

Um den fehlerhaften Rücksprung über zend_bailout() bei CVE-2026-109618 auszulösen, muss der Angreifer gezielt eine Überschreitung des memory_limit herbeiführen. Ein deutlicher Hinweis auf einen Angriffsversuch liegt vor, wenn in den Fehlerprotokollen gehäuft Meldungen über erschöpften Arbeitsspeicher auftreten, die als Ort in Unknown on line 0 ausweisen. Diese Ortsangabe deutet darauf hin, dass der Fehler außerhalb eines laufenden Skripts eingetreten ist, typischerweise beim Einlesen der HTTP-Anfrage; sie tritt allerdings auch in der Abschlussphase einer Anfrage auf.

Für CVE-2026-109619 sind zusätzlich gehäufte Fatal Errors anderer Art auffällig, etwa Parse-Fehler, fehlgeschlagene require-Aufrufe oder Zeitüberschreitungen (Maximum execution time). Das Advisory empfiehlt, die Protokolle mit error_reporting = E_ALL auszuwerten, weist aber darauf hin, dass unauffällige Protokolle keinen Nachweis der Sicherheit darstellen.

sudo zgrep -hE "Allowed memory size of|Maximum execution time|PHP Fatal error|PHP Parse error" /var/log/php* /var/log/apache2/error.log* /var/log/nginx/error.log* 2>/dev/null

Typisches Muster eines vor dem Skriptstart ausgelösten Speicherabbruchs:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in Unknown on line 0

7.3 Korrelation von Zugriffsprotokollen des Webservers

Treten in den Systemprotokollen Abstürze oder Vorab-Speicherfehler auf, sollten die zugehörigen Zeitstempel mit den Zugriffsprotokollen (Access-Logs) des Webservers abgeglichen werden. Verdächtig sind insbesondere rasche Abfolgen von POST-Anfragen derselben Quell-IP-Adresse, die mit den HTTP-Statuscodes 500 (Internal Server Error), 502 (Bad Gateway) oder 499 (Client Closed Request) enden:

# Auswertung der Nginx-Zugriffsprotokolle (Combined-Format) auf abgebrochene POST-Anfragen,
# einschließlich bereits komprimierter Rotationen
sudo zcat -f /var/log/nginx/access.log* | awk '$6 ~ /"POST/ && ($9 == 500 || $9 == 502 || $9 == 499)'

# Apache: /var/log/apache2/access.log* bzw. /var/log/httpd/access_log* (Status 499 kommt dort nicht vor)
sudo zcat -f /var/log/apache2/access.log* | awk '$6 ~ /"POST/ && ($9 == 500 || $9 == 502)'

7.4 Überprüfung laufender Prozesse, Systemaufrufe und des Dateisystems

Um festzustellen, ob ein Angriff bereits zu einer Codeausführung oder der Hinterlegung von Schadprogrammen geführt hat, empfehlen sich folgende technische Prüfschritte:

1. Kontrolle des Prozessbaums auf ungewöhnliche Unterprozesse

In vielen Umgebungen startet ein PHP-Arbeitsprozess im regulären Betrieb keine Kommandozeilen-Interpreter (sh, bash), Netzwerkwerkzeuge (curl, wget, nc, socat) oder Skriptumgebungen (python, perl). Es gibt jedoch legitime Ausnahmen, etwa mail() (startet /bin/sh -c sendmail), Bild- und Dokumentkonvertierungen (ImageMagick, Ghostscript, ffmpeg) oder Hintergrundaufgaben von Anwendungen wie Nextcloud. Auffälligkeiten sind daher gegen eine zuvor erhobene Baseline des Normalbetriebs zu bewerten.

# Darstellung des Prozessbaums ausgehend vom PHP-FPM-Hauptprozess (bei mod_php: pgrep -o apache2 bzw. httpd)
pstree -p -u $(pgrep -o php-fpm)

# Suche nach ungewöhnlichen Prozessen unter der Kennung des Webserver-Benutzers (Debian/Ubuntu: www-data, RHEL: apache/nginx)
ps -ef | awk '$1 ~ /^(www-data|apache|nginx)$/ && $8 !~ /(php-fpm|apache2|httpd|nginx)/ {print $0}'

2. Überwachung von Programmstarts über das Linux-Audit-Subsystem (auditd)

Mit einer Regel für den Linux-Audit-Dienst (auditd) lassen sich sämtliche Programmaufrufe (Systemaufrufe execve und execveat), die unter der Benutzerkennung des Webservers (z. B. User-ID 33 für www-data unter Debian und Ubuntu) erfolgen, nachvollziehbar protokollieren:

# Erfassen von Programmstarts durch den Benutzer www-data (UID 33; unter RHEL UID mittels 'id -u apache' bestimmen)
sudo auditctl -a always,exit -F arch=b64 -S execve -S execveat -F uid=33 -k php_rce_monitor
sudo auditctl -a always,exit -F arch=b32 -S execve -S execveat -F uid=33 -k php_rce_monitor
# (auditctl-Regeln gelten nur bis zum Neustart; dauerhaft unter /etc/audit/rules.d/ hinterlegen)

# Auswertung der aufgezeichneten Ereignisse
sudo ausearch -k php_rce_monitor -i

3. Prüfung des Dateisystems und der Arbeitsspeicher-Deskriptoren

# 1. Suche nach neu angelegten oder veränderten PHP-Dateien im Webverzeichnis seit dem Leak (20.10.2026)
#    ctime statt mtime, da sich die Änderungszeit (mtime) mit touch nachträglich fälschen lässt
sudo find /var/www -type f -name "*.php*" -newerct "2026-10-20" -ls

# 2. Kontrolle temporärer Verzeichnisse auf abgelegte Dateien des Webserver-Benutzers
sudo find /tmp /var/tmp /dev/shm -user www-data -ls

# 3. Überprüfung geplanter Aufgaben (Crontabs) und hinterlegter SSH-Schlüssel
sudo crontab -u www-data -l
sudo ls -la /var/www/.ssh/

# 4. Prüfung auf gelöschte, aber im Arbeitsspeicher noch geöffnete Dateideskriptoren über alle PHP-FPM-Prozesse
#    (-a verknüpft die Bedingungen mit UND; bei mod_php -c apache2 bzw. -c httpd verwenden)
#    OPcache hält in jedem Prozess eine gelöschte Sperrdatei (.ZendSem.*) offen; diese ist unverdächtig
sudo lsof -a +L1 -c php-fpm | grep -v ZendSem
# Alternativ über das /proc-Dateisystem für sämtliche laufenden PHP-FPM-Prozesskennungen (PID):
for pid in $(pgrep -f php-fpm); do sudo ls -l /proc/$pid/fd 2>/dev/null | grep "(deleted)" | grep -v ZendSem; done | sort -u

7.5 Organisatorisches Vorgehen und Meldepflichten bei bestätigtem Befall

Ergeben die technischen Prüfungen Hinweise auf eine erfolgreiche Ausnutzung (beispielsweise unautorisierte Unterprozesse, veränderte Skriptdateien oder verdächtige ausgehende Netzwerkverbindungen), sollte nach einem strukturierten Incident-Response-Prozess vorgegangen werden:

1. Isolierung und Beweissicherung: Das betroffene System sollte vom öffentlichen Netzwerk getrennt werden, ohne den Server sofort auszuschalten, damit flüchtige Beweismittel im Arbeitsspeicher (RAM-Abbild, Prozesslisten, offene Netzwerkverbindungen) für die forensische Untersuchung gesichert werden können.
2. Einbindung von Krisenstab und Experten: Information des internen Security Incident Response Teams (SIRT), der Geschäftsführung sowie des Datenschutzbeauftragten.
3. Wahrung gesetzlicher Meldefristen: Prüfen und Auslösen der gesetzlichen Meldungen, insbesondere der 24-Stunden-Frühwarnung an das zuständige CSIRT nach § 34 NISG 2026 bei erheblichen Cybersicherheitsvorfällen (§ 35 NISG 2026 in Verbindung mit § 5 NISV 2026) sowie der 72-Stunden-Meldung nach Art. 33 DSGVO, sofern die Kompromittierung personenbezogener Daten voraussichtlich zu einem Risiko für die betroffenen Personen führt.
4. Neuaufbau und Rotation von Zugangsdaten: Nach einer bestätigten RCE reicht ein bloßes Einspielen des PHP-Updates nicht aus. Sämtliche auf dem Server gespeicherten Passwörter, Datenbank-Zugangsdaten, API-Schlüssel und Sitzungsschlüssel müssen als kompromittiert betrachtet und erneuert werden.

8. Fazit und konkrete Handlungsempfehlungen für das Management

Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 verdeutlichen, dass kritische Sicherheitsrisiken nicht allein aus individuellem Anwendungscode entstehen, sondern auch in weit verbreiteten Basiskomponenten der Server-Infrastruktur auftreten können. Für eine geordnete Steuerung des Risikos empfehlen sich für Geschäftsführung, CISO und IT-Leitung folgende vier Schritte:

Unterstützung durch Authenta

Die Authenta GmbH unterstützt Geschäftsführungen, interne IT-Abteilungen und betreuende Systemhäuser bei der strukturierten Bewertung und Bewältigung kritischer Schwachstellen: von der unabhängigen Überprüfung der exponierten Systemlandschaft im Rahmen eines GAP- & Risiko-Audits über die Konzeption von Patch-, Härtungs- und Überwachungsvorgaben bis zur kontinuierlichen Begleitung und Nachweisführung als Chief Information Security Officer as a Service (CISOaaS). Die gesetzliche Verantwortung für die Einhaltung der Sicherheits- und Meldepflichten verbleibt bei der Einrichtung und ihren Leitungsorganen; die operative technische Umsetzung erfolgt durch die interne IT-Abteilung oder den beauftragten IT-Dienstleister.

• Standortbestimmung & GAP-Audit anfragen (Modul START)
• Schwachstellen-Governance und Patching etablieren (Modul C.3)
• Kontinuierliche Begleitung durch CISO as a Service (Modul A.12)

Quellen und Rechtsgrundlagen

• Hersteller-Sicherheitstracker für Distributionspakete:
• Debian: CVE-2026-109618 und CVE-2026-109619
• Ubuntu: CVE-2026-109618 und CVE-2026-109619
• Red Hat: CVE-2026-109618 und CVE-2026-109619
• PHP Group Security Advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618, „RCE via OOM corruption“) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, „RCE via stale global state“) vom 21. Oktober 2026 (https://github.com/php/php-src/security/advisories) sowie Changelog zu PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (https://www.php.net/ChangeLog-8.php).
• National Vulnerability Database (NVD) / MITRE: Einträge zu CVE-2026-109618 und CVE-2026-109619 (jeweils CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419).
• CERT-EU: Security Advisory 2026-018 zu CVE-2026-109618 und CVE-2026-109619 (Oktober 2026).
• Technische Forschungsberichte und Lagebilder: Koordinierte Schwachstellenanalysen zu „PHP2Shell“ von Calif, Wiz Research und OpenAI sowie Lagebilder von Sansec, Tenable und watchTowr (Oktober 2026).
• Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026): BGBl. I Nr. 94/2025, insbesondere §§ 31, 32, 34 und 35.
• Netz- und Informationssystemsicherheits-Verordnung (NISV 2026): BGBl. II Nr. 290/2026, §§ 2 bis 7.
• Durchführungsverordnung (EU) 2024/2690: Technische und methodische Anforderungen an Risikomanagementmaßnahmen, Art. 2 samt Anhang.
• Datenschutz-Grundverordnung (DSGVO): Verordnung (EU) 2016/679, insbesondere Art. 32, 33 und 34.
• Cyber Resilience Act (CRA): Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
• ISO/IEC 27001:2022: Informationssicherheit, Cybersicherheit und Schutz der Privatsphäre, insbesondere Annex A Control 8.8 (Management technischer Schwachstellen) und Control 8.15 (Protokollierung).

Dieser Fachbeitrag dient der allgemeinen sicherheitsfachlichen Information und ersetzt keine Rechtsberatung im Einzelfall.