21. Oktober 2026· 11 Min. Lesezeit· Sandor Farkas

CVE-2026-109618: Kritische PHP-Lücken jetzt schließen

SicherheitPHPCVESicherheitslücken

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen. Sie tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Noch am selben Tag warnte CERT-EU, das IT-Sicherheitsteam der EU-Institutionen. Die Security Advisory 2026-018 enthält eine klare Empfehlung: sofort patchen.

Beide Lücken haben eine Bewertung von 9,2 von 10 Punkten. Angreifer können damit unter Umständen eigenen Code auf Ihrem Server ausführen. Einen Login brauchen sie dafür nicht. Beispielcode für den Angriff ist bereits im Umlauf.

Betreiben Sie eine Website, einen Onlineshop oder ein Kundenportal auf PHP? Dann betrifft Sie diese Meldung sehr wahrscheinlich. Dieser Artikel erklärt das Problem und zeigt, was Sie jetzt konkret tun sollten.

In den Medien heißen die beiden Lücken inzwischen PHP2Shell. Ein Lagebild für Unternehmen bietet unser Beitrag PHP2Shell: Was Unternehmen jetzt wissen und tun müssen.

Was ist bei PHP passiert?

PHP ist die Programmiersprache hinter einem großen Teil des Webs. WordPress, Shopware, TYPO3, Magento und Nextcloud laufen darauf. Dazu kommen unzählige Eigenentwicklungen. Auch viele Geräte nutzen PHP im Hintergrund, etwa Netzwerkgeräte und Verwaltungsoberflächen.

Der Fehler steckt in PHP selbst. Ihr eigener Code oder ein WordPress-Plugin ist also nicht die Ursache. Weil die Sprache selbst betroffen ist, ist die Reichweite so groß.

Zwei Fachbegriffe tauchen in den Meldungen immer wieder auf. Ein CVE (Common Vulnerabilities and Exposures) ist eine öffentliche Kennnummer für eine bekannte Sicherheitslücke. Mehr dazu steht in unserem Glossar unter Was ist ein CVE?. RCE steht für Remote Code Execution. Dabei bringt jemand aus dem Internet Ihren Server dazu, seine Befehle auszuführen. Das ist die gefährlichste Art von Sicherheitslücke.

Warum sind diese Lücken so gefährlich?

Bei den meisten Sicherheitslücken braucht ein Angreifer einen Ansatzpunkt. Das kann ein schwaches Passwort oder ein veraltetes Plugin sein. Hier ist das anders.

Laut PHP-Team genügt eine einzige präparierte Anfrage aus dem Internet. Ein Benutzerkonto oder Passwort braucht der Angreifer nicht.

Dazu kommt der Zeitpunkt des Angriffs. Die Lücken liegen in der Phase, in der PHP eine Anfrage entgegennimmt. Ihr eigener Code läuft in diesem Moment noch gar nicht. Schutzmechanismen in der Anwendung greifen deshalb nicht. Ein Login-Schutz oder ein Sicherheits-Plugin in WordPress hilft hier nichts.

Und es gibt bereits Angriffscode. CERT-EU weist auf sogenannte Proof-of-Concepts hin. Das sind Beispielprogramme, die zeigen, wie sich eine Lücke ausnutzen lässt. Eine aktive Ausnutzung war bei Veröffentlichung noch nicht bestätigt. CERT-EU hält sie aber für wahrscheinlich.

Was passiert, wenn Sie nicht patchen?

Angreifer suchen selten gezielt nach Ihrem Unternehmen. Sie scannen das Internet automatisch nach verwundbaren Servern. Bei Lücken dieser Schwere beginnen solche Scans erfahrungsgemäß nach wenigen Tagen. Oft geht es schneller.

Gelingt der Angriff, hat der Angreifer die Rechte des PHP-Prozesses. Er kann Kundendaten auslesen oder Schadsoftware auf dem Server ablegen. Oft dient ein übernommener Server auch als Sprungbrett ins interne Netz.

Dazu kommt die rechtliche Seite. Die DSGVO (Datenschutz-Grundverordnung) verlangt einen angemessenen Schutz personenbezogener Daten. Ein Datenleck müssen Sie in der Regel binnen 72 Stunden der Aufsichtsbehörde melden. Dann steht schnell die Frage im Raum, warum ein verfügbares Update fehlte.

Was steckt technisch dahinter?

Sie müssen die Details nicht verstehen, um richtig zu handeln. Für Interessierte folgt hier die Kurzfassung.

CVE-2026-109618: Fehler bei Speichermangel

PHP arbeitet mit einem Speicherlimit pro Anfrage. Erreicht eine Anfrage das Limit, bricht PHP die Verarbeitung ab. Passiert das in einem ungünstigen Moment, sind interne Daten erst halb vorbereitet. Ein Beispiel ist das Einlesen eines Datei-Uploads. Beim Aufräumen hält PHP diese unfertigen Daten für gültig. Dabei kann PHP Speicher freigeben, in dem noch Daten des Angreifers stehen.

CVE-2026-109619: Veraltete Daten im Arbeitsprozess

PHP verarbeitet viele Anfragen nacheinander im selben Arbeitsprozess. Fachleute nennen diesen Prozess Worker. Nach bestimmten Fehlern bleiben Verweise auf bereits freigegebenen Speicher bestehen. Ein Beispiel ist ein schwerer Programmabbruch, ein sogenannter Fatal Error. Die nächste Anfrage im selben Worker kann diese veralteten Daten nutzen. Das passiert, bevor PHP sie regulär zurücksetzt.

In beiden Fällen kann ein Angreifer so die Kontrolle über den Prozess übernehmen.

Welche PHP-Versionen sind betroffen?

Betroffen sind praktisch alle PHP-Versionen, die Webanfragen verarbeiten. Diese Versionen schließen die Lücken:

PHP-Zweig	Betroffen	Sichere Version	Status
PHP 8.5	alle Versionen vor 8.5.12	8.5.12	aktiv unterstützt
PHP 8.4	alle Versionen vor 8.4.27	8.4.27	aktiv unterstützt
PHP 8.3	alle Versionen vor 8.3.36	8.3.36	nur noch Sicherheitsupdates
PHP 8.2	alle Versionen vor 8.2.35	8.2.35	Sicherheitsupdates bis 31. Dezember 2026
PHP 8.1 und älter	alle	kein offizielles Update	End of Life, nur Backports

Wie PHP auf dem Server eingebunden ist, spielt keine Rolle. Betroffen sind PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei Apache mit mod_php. Für diese Variante wurde ein vollständiger Angriff bereits vorgeführt.

Denken Sie auch an Software, die PHP mitbringt. Viele Appliances, Netzwerkgeräte und Verwaltungsoberflächen enthalten eine eigene PHP-Version. Die niederländische Cybersicherheitsbehörde NCSC-NL pflegt dazu eine Liste potenziell betroffener Produkte. Die Liste ist ausdrücklich unvollständig. Als Ausgangspunkt taugt sie trotzdem.

Was Sie jetzt tun sollten

Schritt 1: Herausfinden, wo PHP läuft

Der erste Schritt klingt einfach. In der Praxis ist er es selten. Welche Server, Webspaces und Geräte in Ihrem Unternehmen nutzen PHP? Und welche Version läuft jeweils?

Auf einem Server mit Kommandozeile zeigt dieser Befehl die Version:

php -v

Die Kommandozeile kann allerdings eine andere Version nutzen als der Webserver. Verlässlicher ist ein Blick in die Paketverwaltung oder die Webserver-Konfiguration. Bei Shared Hosting zeigt meist die Oberfläche des Anbieters die aktive Version.

Viele Unternehmen haben diesen Überblick nicht vollständig. Unser Artikel zum Software-Inventar zeigt, wie Sie die Liste dauerhaft aufbauen. Für heute reicht eine schnelle Bestandsaufnahme.

Schritt 2: Updates einspielen

Das Update ist die einzige vollständige Lösung. Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wie das geht, hängt von Ihrer Umgebung ab.

Auf Linux-Servern mit Paketen der Distribution geht es meist am schnellsten. Laut PHP-Team haben die Distributionen die Patches vorab erhalten. Prüfen Sie, ob aktualisierte Pakete bereitstehen, und spielen Sie diese ein.

Wer PHP aus dem Remi-Repository (rpms.remirepo.net) bezieht, muss aufpassen. Dort gab es am Veröffentlichungstag noch keine Updates. Das PHP-Team empfiehlt den Wechsel auf Distributionspakete oder einen eigenen Build.

In Docker-Umgebungen aktualisieren Sie das Basis-Image und bauen die Container neu. Ein laufender Container aktualisiert sich nicht von selbst.

Bei Shared oder Managed Hosting liegt das Update beim Anbieter. Fragen Sie nach, ob und wann er die neuen Versionen einspielt. Lassen Sie sich die Antwort schriftlich geben.

Für Appliances und Netzwerkgeräte hilft nur ein Firmware-Update des Herstellers. Verfolgen Sie dessen Sicherheitsmeldungen in den nächsten Tagen genau.

Nach jedem Update müssen alle PHP-Prozesse neu starten. Bei PHP-FPM starten Sie den FPM-Dienst neu, bei mod_php den Apache. Sonst läuft weiter der alte Code im Speicher.

Schritt 3: Sonderfall PHP 8.1 und älter

Für PHP 8.1, 8.0, 7.4 und ältere Versionen gibt es keine regulären Updates mehr. Diese Versionen haben ihr End of Life erreicht. Das PHP-Projekt pflegt sie also nicht mehr.

Diesmal gibt es trotzdem eine Ausnahme. Das PHP-Sicherheitsteam hat minimale Korrekturen für PHP 7.4, 8.0 und 8.1 veröffentlicht. Diese liegen als Quellcode vor. Sie richten sich an Betreiber, die PHP selbst kompilieren. Einige Distributionen und Anbieter von Langzeit-Support liefern außerdem eigene Backports. Bei einem Backport überträgt ein Anbieter eine Korrektur nachträglich in eine alte Version. Wie solche Angebote funktionieren, beschreibt unser Artikel zu kommerziellem Langzeit-Support.

Diese Backports lösen das aktuelle Problem. Die nächste Lücke kommt trotzdem. Ob dann wieder jemand Backports liefert, ist offen. Wer noch auf PHP 8.1 oder älter läuft, sollte jetzt ein PHP-Upgrade planen. Über die Jahre hat sich hier ein Risiko angesammelt, das jetzt sichtbar wird.

Auch PHP 8.2 hat nicht mehr viel Zeit. Diese Version bekommt jetzt noch ein Update. Ab dem 31. Dezember 2026 gibt es keine Sicherheitsupdates mehr. Mehr dazu lesen Sie in unserem Beitrag zum PHP 8.2 End of Life.

Schritt 4: Übergangsmaßnahmen, wenn das Update warten muss

Manchmal lässt sich ein Update nicht sofort einspielen. Vielleicht wartet ein Gerät auf die Firmware des Herstellers. Oder ein Wartungsfenster muss erst abgestimmt werden. Für diese Fälle nennt das PHP-Team Maßnahmen, die bekannte Angriffswege erschweren.

Diese Maßnahmen machen Ihren Server nicht sicher. Sie verkleinern nur die Angriffsfläche für die bisher bekannten Wege. Das Update bleibt Pflicht.

Gegen CVE-2026-109619 helfen zwei Einstellungen:

; in php.ini oder in der Konfiguration des FPM-Pools
session.upload_progress.enabled = 0

; nur bei PHP 8.5 zusätzlich
fatal_error_backtraces = 0

Diese Werte müssen in der php.ini, im FPM-Pool oder in der Serverkonfiguration stehen. Eine Änderung per ini_set() im Code oder per .user.ini reicht nicht. Starten Sie danach alle Worker neu.

Das PHP-Team rät außerdem, veraltete oder ungültige Einstellungen zu entfernen. Gemeint sind Einstellungen, die bei jeder Anfrage Warnmeldungen erzeugen. Die Meldungen nur auszublenden, etwa über display_errors, hilft nicht. Beheben Sie zudem Fehler, die ein Angreifer gezielt auslösen kann. Dazu zählen Abstürze und Zeitüberschreitungen bei Uploads oder Importen.

Gegen CVE-2026-109618 empfiehlt das PHP-Team mehrere Schritte:

Heben Sie das Speicherlimit mit memory_limit = -1 auf. Setzen Sie den Wert so, dass die Anwendung ihn nicht überschreiben kann. Das geht etwa über php_admin_value im FPM-Pool oder in der Apache-Konfiguration. Keine andere Ebene darf wieder ein festes Limit setzen.
Begrenzen Sie die Größe von Anfragen. Ohne Datei-Uploads empfiehlt das PHP-Team post_max_size = 8M, mit Uploads 32M. Der Wert upload_max_filesize muss jeweils kleiner sein.
Setzen Sie Limits am Webserver oder Proxy. Das betrifft die Größe von Anfragen und die Zahl der Formularfelder, Header und Upload-Teile. Die Grenzen müssen auch Anfragen ohne Längenangabe erfassen.
Begrenzen Sie den Speicher von außen über Container- oder cgroup-Limits. Cgroups sind eine Linux-Funktion, die den Ressourcenverbrauch von Prozessen begrenzt. Nutzen Sie dafür nicht RLIMIT_AS oder RLIMIT_DATA. Diese Grenzen können genau den Fehler auslösen, den Sie vermeiden wollen.

Das aufgehobene Speicherlimit wirkt zunächst widersinnig. Die Lücke wird aber genau dann ausgelöst, wenn PHP sein eigenes Limit erreicht. Ohne Limit fällt dieser Auslöser weg. Die Begrenzung von außen verhindert, dass ein einzelner Prozess den Server lahmlegt.

Prüfen Sie die Nebenwirkungen, bevor Sie alles ausrollen. Zu niedrige Upload-Grenzen brechen zum Beispiel große Importe ab.

Schritt 5: Nach Spuren eines Angriffs suchen

War Ihr Server einige Tage ungepatcht erreichbar? Dann lohnt nach dem Update ein genauer Blick. Diese Anzeichen sollten Sie stutzig machen:

viele abgebrochene Anfragen oder Speicherfehler in den Logs von PHP und Webserver
unerwartet abgestürzte PHP-Worker
neue oder veränderte PHP-Dateien im Webverzeichnis
unbekannte Prozesse oder ausgehende Verbindungen vom Webserver

Das NCSC-NL-Repository enthält einen eigenen Bereich zur Erkennung und Abwehr. Bei konkretem Verdacht sollten Sie Fachleute hinzuziehen. Einen kompromittierten Server rettet man selten, indem man verdächtige Dateien löscht.

Checkliste für heute

Alle Systeme mit PHP auflisten, auch Webspaces und Geräte.
Die PHP-Version je System prüfen.
Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren.
Danach alle PHP-Prozesse neu starten.
Für PHP 8.1 und älter einen Backport besorgen und das Upgrade planen.
Wo kein Update möglich ist, Übergangsmaßnahmen setzen und testen.
Die Logs der letzten Tage auf Auffälligkeiten prüfen.

Was dieser Vorfall über Wartung zeigt

Solche Meldungen kommen ohne Vorwarnung. Dann zählt jede Stunde. Wer erst klären muss, welche Server es gibt, verliert Zeit. Das Gleiche gilt für die Fragen, wer Zugang hat und welche Version läuft. In dieser Zeit suchen automatisierte Scanner bereits das Internet ab.

Mit einer laufenden Software-Wartung sind diese Fragen vorher beantwortet. Sie kennen Ihre Systeme und haben ein erprobtes Update-Verfahren. Von neuen Lücken erfahren Sie früh. Wie diese Überwachung funktioniert, zeigt unser Artikel zum CVE-Monitoring in der Praxis.

Besonders hart trifft es Betreiber alter PHP-Versionen. Für sie gibt es diesmal noch Notlösungen. Beim nächsten Mal gibt es die vielleicht nicht.

Fazit: Spielen Sie das Update heute ein

CVE-2026-109618 und CVE-2026-109619 gehören zu den ernstesten PHP-Lücken der letzten Jahre. Ein Angriff braucht keinen Login und nur eine einzige Anfrage. Beispielcode für den Angriff ist bereits bekannt.

Die Updates stehen bereit. Auf den meisten Servern ist das Einspielen in wenigen Minuten erledigt. Warten Sie damit nicht bis zum nächsten regulären Wartungstermin.

Sie wissen nicht genau, welche Ihrer Systeme betroffen sind? Oder Ihre Anwendung läuft noch auf PHP 8.1 oder älter? Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir helfen bei der Bestandsaufnahme und beim Patchen. Auf Wunsch prüfen wir Ihr System danach mit einem Sicherheits-Audit.