Kritische PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 – was Unternehmen jetzt tun müssen
Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken veröffentlicht, die unauthentifizierte Remote Code Execution auf Webservern ermöglichen. Betreiber von PHP-Lösungen und Webseiten müssen auf PHP Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren oder sich vom Anbieter bestätigen lassen, dass der Fix in ihrem Paket enthalten ist.
Um was geht es, und wie kritisch ist es?
Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619, in der Fachpresse als PHP2Shell bezeichnet, erreichen nach CVSS 4.0 jeweils 9,2 von 10 Punkten. Das BSI hat sie in seiner Warnung (Link) mit Kritikalität 3 (Orange) eingestuft. Sie liegen im PHP-Interpreter selbst und betreffen deshalb jede PHP-Installation, die Webanfragen bedient, unabhängig davon, ob darauf WordPress, ein Onlineshop oder eine Eigenentwicklung läuft. Ein Update des Content-Management-Systems ersetzt die PHP-Korrektur nicht.Dieser Beitrag fasst den Stand vom 23. Oktober 2026 zusammen, nennt die konkreten Schritte für Betreiber und erklärt, was die Lage über den Zustand des Schwachstellenmanagements in vielen Unternehmen verrät.
Welche PHP-Versionen und Systeme betroffen sind
Nach dem Security Advisory des PHP-Projekts (Link) sind alle PHP-Installationen gefährdet, die Webanfragen bedienen. Genannt werden PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed, wobei das Risiko bei mod_php am höchsten eingeschätzt wird. Korrigiert wurden die Versionszweige 8.5, 8.4, 8.3 und 8.2:
- PHP 8.5: Korrigierte Version 8.5.12, aktiv unterstützt
- PHP 8.4: Korrigierte Version 8.4.27, aktiv unterstützt
- PHP 8.3: Korrigierte Version 8.3.36, nur Sicherheitsupdates
- PHP 8.2: Korrigierte Version 8.2.35, Security-Support endet am 31. Dezember 2026
- PHP 8.1, 8.0, 7.4: Keine reguläres Release, Upgrade einplanen
Für PHP 8.1 und ältere Versionen gibt es vom PHP-Projekt keine regulären Updates mehr. Wer solche Versionen betreibt, ist auf Backports seines Distributors oder LTS-Anbieters angewiesen oder muss auf eine unterstützte Version wechseln. Zwei technische Besonderheiten werden in der Praxis oft übersehen. Linux-Distributionen liefern den Fix häufig unter der alten Versionsnummer aus, weshalb die Ausgabe von php -v allein nichts über den Patchstand aussagt, sondern der Paket-Changelog mit den CVE-Nummern maßgeblich ist (Hostspezial).
Wichtig: Ein Paket-Update wirkt erst, nachdem PHP-FPM beziehungsweise der Apache-Server neu gestartet wurde!
Die beiden Schwachstellen kurz erklärt
CVE-2026-109618 entsteht bei der Behandlung von Out-of-Memory-Situationen. PHP kann dabei unterbrochen werden, während interne Anfragedaten nur teilweise initialisiert sind, und die anschließende Bereinigung behandelt diese Daten als gültig.
CVE-2026-109619
CVE-2026-109619 beruht auf einem veralteten internen Zustand: Anfragebezogene Daten können überleben, nachdem der zugrunde liegende Speicher freigegeben wurde, und eine spätere Anfrage im selben Worker kann sie verwenden. In beiden Fällen ist Codeausführung ohne Anmeldung möglich.
Was Betreiber jetzt tun sollten
Eile ist geboten, auch wenn die Berichte zur Ausnutzung nicht einheitlich sind. Nach Help Net Security registrierte Amazon Threat Intelligence bereits am 17. Oktober 2026, vier Tage vor der Veröffentlichung, einen Ausnutzungsversuch in einem Honeypot. Die BSI-Vorabmeldung kannte laut Drohnen.de noch keine bestätigten Angriffe. Wer wartet, bis sich die Lage klar darstellt, verliert Zeit, die Angreifer nutzen.
Die Betreiber sollten somit jetzt sofort den Patchstand prüfen, und alte Patchstände erneuern.
Die folgenden Schritte geben eine erste Orientierung, und sollten im Einzelfall vor Anwendung auf der jeweiligen Umgebung geprüft werden, ACONO übernimmt hierzu keine Haftung oder Ergebnisverantwortung und hat die Schritte rein informativ dargestellt:
1. Bestand erfassen.
Feststellen, wo PHP läuft: auf eigenen Webservern, in Container-Images, in Shops und Content-Management-Systemen, auf Appliances und bei externen Hostern. Bei extern betriebenen Websites den Anbieter kontaktieren und den Patchstand bestätigen lassen.
2. Patchstand prüfen. Maßgeblich ist nicht nur die Versionsnummer, sondern der Paket-Changelog mit den CVE-Nummern, weil Distributionen den Fix zurückportieren.
3. Aktualisieren und neu starten. Auf eine korrigierte Version wechseln und PHP-FPM beziehungsweise den Apache-Server neu starten. Container-Images müssen neu gebaut und ausgerollt werden.
4. Auf Kompromittierung prüfen. Auf neue oder geänderte PHP-Dateien seit dem 17. Oktober 2026, unbekannte Cronjobs des Webbenutzers und Shell-Prozesse unter dem Webbenutzer achten. Ein unauffälliges Access-Log ist laut Hostspezial keine Entwarnung, denn ein Angriff kann mit Status 200 enden.
5. Veraltete Versionen ablösen. PHP 8.1 und älter erhalten keine regulären Updates, PHP 8.2 verliert Ende 2026 den Security-Support.
Lässt sich nicht sofort patchen, ist die Einschränkung der öffentlichen Erreichbarkeit die sicherste Übergangslösung. Die vom PHP-Projekt genannten Workarounds mindern das Risiko nur: ein deaktivierter Upload-Fortschritt (session.upload_progress.enabled=0) gegen CVE-2026-109619, memory_limit=-1 und ein niedriges post_max_size gegen CVE-2026-109618, jeweils in der Server- oder FPM-Konfiguration und mit Neustart der Worker. Das PHP-Projekt stellt ausdrücklich klar, dass sie ein Update nicht ersetzen.
Sie wissen nicht genau, wo in Ihrem Unternehmen PHP läuft oder wer dafür zuständig ist?
Was die PHP-Lücke über Schwachstellenmanagement zeigt
Patchmanagement ist nicht nur eine IT Aufgabe, sondern vor allem ein zentrales Governance Thema
Das Patch-Angebot war bei dieser Lücke nicht das Problem, die Korrekturen lagen am Tag der Warnung vor. Entscheidend ist, wie schnell ein Unternehmen weiß, wo betroffene Software läuft, wer dafür verantwortlich ist und welche Geschäftsprozesse daran hängen. Wenn ein Ausnutzungsversuch bereits vier Tage vor der Veröffentlichung beobachtet wurde, bleibt für die Bestandsaufnahme keine Zeit mehr, sie muss vorher erfolgt sein.
Verantwortlich ist die Geschäftsleitung, somit zwingende Verankerung in der Governance
Der rechtliche Rahmen verlangt das ausdrücklich. § 30 Abs. 2 Nr. 5 BSIG fordert Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, „einschließlich Management und Offenlegung von Schwachstellen“. Nach § 38 BSIG muss die Geschäftsleitung die Maßnahmen einführen und ihre Einhaltung überwachen. Die Norm ISO 27001 adressiert dasselbe über den Anhang A, etwa mit der Kontrolle 5.9 zum Inventar der Werte und der Kontrolle 8.8 zum Umgang mit technischen Schwachstellen. Welche dieser Kontrollen gelten und warum, hält die Erklärung zur Anwendbarkeit (Statement of Applicability) fest.
In der Praxis stehen dahinter drei Bausteine: Der erste ist ein gepflegtes Inventar der Systeme und Komponenten mit Verantwortlichen, damit die Frage „Wo läuft PHP?“ innerhalb von Minuten für die Geschäftsführung beantwortet werden kann. Der zweite ist ein definierter Ablauf, der eine Schwachstelle bewertet, eine Maßnahme mit Frist und Verantwortlichem zuweist und die Umsetzung nachweist. Der dritte ist die Verknüpfung mit den Geschäftsprozessen, denn nur so lässt sich entscheiden, welche Systeme zuerst gepatcht werden müssen, wenn nicht alles gleichzeitig geht. Die Verbindung mit den Geschäftsprozessen wird initial z.B. im Prozessmanagement angelegt, und im Rahmen des ITSCM sowie über die CMDB wird dann die Verknüpfung der Systeme bis auf Datenbankebene gesteuert.
Ein einfacher Test zeigt, wo ein Unternehmen steht: Könnten Sie an einem Freitagnachmittag innerhalb einer Stunde sagen, welche Ihrer Systeme PHP einsetzen, in welcher Version, wer dafür zuständig ist und welche Prozesse davon abhängen? Wenn das nicht gelingt, hat die aktuelle Lücke ein Problem sichtbar gemacht, das die nächste Lücke wieder treffen wird.
Wie ACONO Sie in der Governance, im Schwachstellenmanagement und ISMS unterstützt
ACONO Design, konfiguriert und implementiert und betreibt Informationssicherheits-Managementsysteme z.B. mit TopEase nach ISO 27001 und NIS2 weiter und begleitet Unternehmen bei den Anforderungen aus NIS2. Unser Ausgangspunkt ist dabei immer das Zielbild und nicht das Werkzeug: Wir klären zuerst, welche Systeme, Prozesse und Verantwortlichkeiten zum Geltungsbereich gehören, und richten Technik und Dokumentation danach aus. Zu unserem Team gehören Informationssicherheitsbeauftragte (TÜV) und ISO-27001-Auditoren (TÜV). Wir führen selbst keine Zertifizierungsaudits durch, wissen aber aus eigener Qualifikation, worauf ein Auditor achtet und welche Nachweise er sehen will.
Im Kontext der benannten Schwachstellen bedeutet unsere Unterstützung konkret:
a) Aufbau eines Inventars der Prozesse, Systeme, Komponenten und Dienstleister mit klar benannten Verantwortlichen
b) Ein dokumentierter Ablauf für den Umgang mit Schwachstellen, von der Bewertung über die Maßnahme bis zum Nachweis
c) Verknüpfung der Systeme mit den Geschäftsprozessen und deren Schutzbedarf, damit bei einer akuten Lücke die Prioritäten feststehenEine Erklärung zur Anwendbarkeit und Nachweise, die einem Audit standhalten
Bei den Werkzeugen sind wir systemunabhängig. Wir haben Managementsysteme für kleine und Mittelständische Unternehmen bereits von Word/Excel, über Confluence / Jira umgesetzt. Für Mittelständische sowie größere, technisch komplexere oder regulatorische anspruchsvollere Unternehmen empfiehlt sich die Einführung einer GRC Plattform wie TopEase. Die ACONO ist preferred Partner der F24 AG für TopEase GRC, dessen Konzeption, Einführung und Betrieb im Managed Service wir auf Wunsch unserer Mandanten.
Sie wissen nicht genau, wo in Ihrem Unternehmen PHP läuft oder wer dafür zuständig ist?
Häufige Fragen zu PHP2Shell
Bin ich von PHP2Shell betroffen?
Betroffen sein kann jede PHP-Installation, die Webanfragen bedient, also auch Websites und Onlineshops auf Basis von PHP-Systemen wie WordPress. Prüfen Sie die PHP-Version beziehungsweise den Paket-Changelog Ihres Servers. Bei einer extern gehosteten Website lassen Sie sich den Patchstand vom Hoster bestätigen.
Welche PHP-Version ist sicher?
Korrigiert wurden PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Bei Linux-Distributionen kann der Fix unter einer älteren Versionsnummer enthalten sein, dann belegt der Paket-Changelog mit den CVE-Nummern den Stand. Nach dem Update muss PHP-FPM beziehungsweise der Apache-Server neu gestartet werden.
Reicht ein Update von WordPress oder meinem CMS?
Nein. Die Lücken liegen im PHP-Interpreter, nicht im CMS. Ein CMS-Update ersetzt die PHP-Korrektur nicht.
Kann ich die Lücke mit Einstellungen entschärfen?
Teilweise und nur übergangsweise. Das PHP-Projekt nennt unter anderem session.upload_progress.enabled=0, memory_limit=-1 und ein niedriges post_max_size, stellt aber klar, dass diese Maßnahmen ein Update nicht ersetzen und die Installation nicht sicher machen.
Woran erkenne ich eine mögliche Kompromittierung?
Hinweise sind neue oder geänderte PHP-Dateien seit dem 17. Oktober 2026, unbekannte Cronjobs des Webbenutzers sowie Shell-Prozesse wie sh, bash, curl oder wget unter dem Webbenutzer. Ein unauffälliges Access-Log ist keine Entwarnung. Die Aufzählung ist nicht abschließend und final. Bei Verdacht sollten Sie Fachleute hinzuziehen.
Was bedeutet das für NIS2-pflichtige Unternehmen?
Das Schwachstellenmanagement gehört nach § 30 Abs. 2 Nr. 5 BSIG zu den Risikomanagementmaßnahmen, für deren Umsetzung und Überwachung die Geschäftsleitung verantwortlich ist. Ob ein konkreter Angriff als erheblicher Sicherheitsvorfall zu melden ist, muss im Einzelfall bewertet werden. Gemeldet wird mit einer Frühwarnung innerhalb von 24 Stunden, einer Meldung innerhalb von 72 Stunden und einer Abschlussmeldung nach spätestens einem Monat.
Hinweis zu Stand und Haftung: Dieser Beitrag gibt den Informationsstand vom 23. Oktober 2026, 10:00 Uhr (MESZ), wieder. Die Lage zu CVE-2026-109618 und CVE-2026-109619 ist derzeit dynamisch, entwickelt sich laufend, Angaben von Herstellern und Behörden können sich ändern oder präzisiert werden. Der Beitrag dient der allgemeinen Information und ersetzt weder eine individuelle Beratung noch eine Prüfung Ihrer Systeme. Prüfen Sie vor dem Einspielen von Updates und vor Änderungen an Konfigurationen die aktuellen Hinweise des PHP-Projekts, Ihres Hosting-Anbieters oder Distributors und des BSI, und testen Sie Änderungen, soweit möglich, vor dem produktiven Einsatz.
Trotz sorgfältiger Recherche übernehmen wir keine Gewähr für Vollständigkeit, Richtigkeit und Aktualität. Eine Haftung für Schäden, die aus der Anwendung der Informationen entstehen, ist ausgeschlossen, soweit gesetzlich zulässig. Dieser Beitrag stellt keine Rechtsberatung dar. ACONO ist eine GRC-Beratung und bietet keinen technischen Support für PHP-Installationen, Webshops oder Hosting. Genannte Produkte, Marken und Unternehmen sind Eigentum der jeweiligen Inhaber und werden ausschließlich zu Informationszwecken genannt.