CVE-2026-109618 und -109619: Notfallplan für Ihre PHP-Server

21. Oktober 2026#CVE-2026-109618

Sandor Farkas

Gründer & Lead Developer

Experte für Softwareentwicklung und Legacy-Code-Optimierung

Die meisten Sicherheitslücken, über die wir mit Kunden sprechen, stecken in einem Plugin, einer Bibliothek oder einem Stück eigenem Code. CVE-2026-109618 und CVE-2026-109619 sind anders. Sie sitzen im PHP-Interpreter selbst, also in der Schicht, auf der Ihre gesamte Anwendung läuft. Das PHP-Projekt hat diese Woche korrigierte Versionen veröffentlicht, und CERT-EU, das Sicherheitsteam der EU-Institutionen, hat am 21. Oktober 2026 mit der Security Advisory 2026-018 nachgezogen. Die Empfehlung dort ist unmissverständlich: sofort patchen.

Beide Lücken sind mit 9,2 von 10 Punkten bewertet. Ein Angreifer braucht kein Benutzerkonto, kein Passwort und keine Schwachstelle in Ihrem Code. Eine einzige präparierte HTTP-Anfrage kann ausreichen, um eigenen Code auf dem Server auszuführen. Öffentlicher Beispielcode, der die Ausnutzung demonstriert, ist bereits im Umlauf.

Dieser Beitrag ist kein Hintergrundartikel, sondern ein Arbeitsplan. Er ist danach sortiert, was in den ersten Stunden, im Laufe des Tages und in den nächsten Wochen passieren sollte.

Kurz eingeordnet: Warum Ihr Code Sie hier nicht schützt

Wenn eine Anfrage bei einem PHP-Server ankommt, passiert einiges, bevor die erste Zeile Ihrer Anwendung läuft. PHP liest Header, Formularfelder und Datei-Uploads ein, verteilt Speicher und bereitet die Umgebung vor. Genau in dieser Phase liegen beide Fehler. Ein Login-Formular, eine Firewall-Regel in Symfony oder ein Sicherheits-Plugin in WordPress kommt gar nicht erst zum Zug.

Bei CVE-2026-109618 geht es um das Speicherlimit pro Anfrage. Erreicht eine Anfrage dieses Limit in einem ungünstigen Moment, etwa mitten im Einlesen eines Uploads, bricht PHP ab und räumt anschließend Datenstrukturen auf, die nur halb fertig sind. Dabei kann Speicher freigegeben werden, in dem noch vom Angreifer kontrollierte Daten liegen.

Bei CVE-2026-109619 geht es um langlebige Arbeitsprozesse. PHP-FPM und vergleichbare Setups bearbeiten viele Anfragen nacheinander im selben Prozess. Nach bestimmten schweren Fehlern, zum Beispiel einem Fatal Error, bleiben Verweise auf bereits freigegebenen Speicher übrig. Die nächste Anfrage im selben Prozess kann darauf zugreifen, bevor PHP aufräumt.

Das Ergebnis ist in beiden Fällen dasselbe: Der Angreifer kann im schlimmsten Fall den PHP-Prozess übernehmen und hat damit dessen Rechte. Das heißt Zugriff auf Datenbank-Zugangsdaten in der Konfiguration, auf hochgeladene Dateien, auf Kundendaten und oft auch einen Ausgangspunkt ins interne Netz.

Eine bestätigte, breite Ausnutzung gab es zum Zeitpunkt der Veröffentlichung noch nicht. CERT-EU hält sie aber für wahrscheinlich, und die Erfahrung mit vergleichbaren Lücken zeigt, dass automatisierte Scans nach verwundbaren Servern innerhalb weniger Tage anlaufen.

Die ersten Stunden: herausfinden, wo überall PHP läuft

Die eigentliche Arbeit beginnt selten mit dem Update, sondern mit der Frage, wo es überhaupt eingespielt werden muss. In den meisten Unternehmen, mit denen wir arbeiten, ist die ehrliche Antwort darauf länger als erwartet. Neben der offensichtlichen Website gibt es oft einen Shop auf einem anderen Server, ein internes Tool, das ein ehemaliger Mitarbeiter gebaut hat, eine Staging-Umgebung, die noch öffentlich erreichbar ist, und Geräte, in denen PHP unbemerkt mitläuft.

Gehen Sie diese Kategorien durch:

Eigene Server und VMs mit Website, Shop, Kundenportal oder API
Container-Umgebungen, in denen PHP Teil eines Docker-Images ist
Shared oder Managed Hosting, bei dem der Anbieter die PHP-Version verwaltet
Staging-, Test- und Altsysteme, die niemand mehr aktiv nutzt, die aber noch erreichbar sind
Appliances und Netzwerkgeräte, deren Verwaltungsoberfläche auf PHP basiert

Für die letzte Gruppe hat die niederländische Cybersicherheitsbehörde NCSC-NL eine Übersicht potenziell betroffener Produkte gestartet. Sie ist ausdrücklich unvollständig, aber ein guter Startpunkt, um Herstellerlisten abzugleichen.

Beim Prüfen der Version gibt es eine Falle. php -v auf der Kommandozeile zeigt die CLI-Version, und die ist nicht zwingend dieselbe, die Ihr Webserver nutzt. Auf vielen Servern sind mehrere PHP-Versionen parallel installiert. Verlässlicher ist es, direkt den laufenden Dienst zu fragen:

# Version der installierten FPM-Binaries (Name je nach Distribution)
php-fpm8.3 -v

# Welche PHP-Pakete sind tatsächlich installiert?
dpkg -l | grep -E '^ii\s+php'      # Debian/Ubuntu
rpm -qa | grep -i php              # RHEL/Alma/Rocky

# In Docker: Version im laufenden Container
docker exec <container> php -v

Bei Shared Hosting steht die aktive Version meist im Kundenbereich des Anbieters. Wenn Sie das nicht selbst prüfen können, ist jetzt der richtige Moment für eine kurze Nachricht an Ihren Entwickler oder Ihre Agentur. Wie schnell und konkret die Antwort ausfällt, sagt übrigens viel darüber aus, wie gut Ihr System betreut wird. Mehr dazu, wer für solche Updates eigentlich zuständig ist, lesen Sie in unserem Beitrag Sicherheitsupdates für Unternehmenssoftware: Wer haftet, wenn kein Entwickler mehr da ist.

Priorisieren Sie danach. Ganz oben stehen Systeme, die direkt aus dem Internet erreichbar sind und Datei-Uploads oder Formulare annehmen. Laut PHP-Team ist das Risiko bei Apache mit mod_php am höchsten, weil dort eine vollständige Angriffskette bereits vorgeführt wurde. Betroffen sind aber alle gängigen Betriebsarten: PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed.

Im Laufe des Tages: auf eine gepatchte Version aktualisieren

Ein Update ist die einzige Maßnahme, die beide Lücken tatsächlich schließt. Diese Versionen enthalten die Korrekturen:

Ihre Version	Mindestens aktualisieren auf	Support-Status
PHP 8.5.x	8.5.12	aktiv unterstützt
PHP 8.4.x	8.4.27	aktiv unterstützt
PHP 8.3.x	8.3.36	Sicherheitsupdates
PHP 8.2.x	8.2.35	31. Dezember 2026
PHP 8.1 und älter	kein regulärer Release verfügbar	End of Life (siehe unten)

Wie das Update konkret aussieht, hängt von Ihrer Umgebung ab.

Pakete der Linux-Distribution. Das ist meist der schnellste Weg. Die großen Distributionen haben die Korrekturen laut PHP-Team vorab bekommen, aktualisierte Pakete sollten also bereitstehen oder in Kürze folgen. Eine Ausnahme ist das beliebte Remi-Repository (rpms.remirepo.net): Dort waren am Veröffentlichungstag noch keine Updates verfügbar. Das PHP-Team rät in diesem Fall, auf Distributionspakete umzusteigen oder selbst zu bauen.

Docker und Container. Ein Container aktualisiert sich nicht von selbst. Ziehen Sie das neue Basis-Image, bauen Sie Ihr Anwendungs-Image neu und rollen Sie es aus. Prüfen Sie dabei, ob Ihr Dockerfile auf einen festen Patch-Tag wie php:8.3.30-fpm gepinnt ist. Dann bringt ein Rebuild allein nichts, der Tag muss angehoben werden. Bei FrankenPHP gilt dasselbe, und wer es im Einsatz hat, findet in unserem Artikel zu FrankenPHP im Produktionsbetrieb mehr zur Image-Strategie.

Shared und Managed Hosting. Hier liegt das Update beim Anbieter. Fragen Sie aktiv nach, statt zu warten, und lassen Sie sich Datum und Version schriftlich bestätigen. Das ist auch später gegenüber Kunden, Versicherern oder Prüfern ein brauchbarer Nachweis.

Appliances und Geräte. Hier können Sie selbst nichts aktualisieren. Beobachten Sie die Sicherheitsmeldungen des Herstellers und schränken Sie bis zum Firmware-Update ein, wer die Verwaltungsoberfläche erreichen kann.

Ein Punkt wird nach Updates erstaunlich oft vergessen: Die laufenden Prozesse müssen neu starten. Solange ein FPM-Pool oder ein Apache mit mod_php nicht neu gestartet wurde, läuft weiter die alte, verwundbare Version im Speicher. Starten Sie den FPM-Dienst beziehungsweise Apache neu und prüfen Sie danach über eine phpinfo()-Seite oder Ihre Monitoring-Daten, welche Version tatsächlich ausgeliefert wird. Entfernen Sie eine solche phpinfo()-Seite direkt danach wieder.

Wenn Sie noch auf PHP 8.1, 8.0 oder 7.4 laufen

Für diese Versionen gibt es keine regulären Releases mehr, sie haben ihr End of Life erreicht. Diesmal hat das PHP-Sicherheitsteam trotzdem eine Ausnahme gemacht und minimale Korrekturen für 7.4, 8.0 und 8.1 als Quellcode veröffentlicht. Die sind für Betreiber gedacht, die PHP selbst kompilieren. Zusätzlich liefern einige Distributionen mit Langzeit-Support und kommerzielle Anbieter eigene Backports, also nachträglich in die alte Version übertragene Korrekturen.

Damit ist das akute Problem lösbar. Das eigentliche Problem bleibt aber bestehen. Bei der nächsten kritischen Lücke gibt es vielleicht keine Ausnahme, und dann stehen Sie mit einer Version da, für die niemand mehr einen Patch schreibt. Wenn dieser Vorfall Sie auf einer dieser Versionen erwischt hat, ist das ein guter Anlass, das Upgrade nicht länger aufzuschieben. Die Abwägung zwischen Upgrade und bezahltem Langzeit-Support haben wir in Jetzt upgraden oder für Extended Support zahlen? aufgeschrieben, und was eine veraltete PHP-Version insgesamt kostet, in Noch auf PHP 8.1 oder älter?.

Auch PHP 8.2 bekommt jetzt noch einen regulären Patch, aber nicht mehr lange. Der Sicherheitssupport endet am 31. Dezember 2026. Wer heute auf 8.2.35 aktualisiert, ist für diese Lücken geschützt, sollte das nächste Upgrade aber bereits einplanen. Mehr dazu im Beitrag PHP 8.2 End of Life am 31. Dezember 2026.

Wenn das Update warten muss: Übergangsmaßnahmen

Manchmal geht es nicht sofort. Ein Gerät wartet auf Firmware, ein Hoster reagiert nicht, ein Kunde erlaubt Änderungen nur im abgestimmten Wartungsfenster. Für diese Fälle hat das PHP-Team Einstellungen veröffentlicht, die die bisher bekannten Angriffswege erschweren. Sie ersetzen das Update nicht. Sie verkleinern die Angriffsfläche, bis es eingespielt ist.

Gegen CVE-2026-109619 sollen der Upload-Fortschritt der Session-Erweiterung und, unter PHP 8.5, die Backtraces bei Fatal Errors abgeschaltet werden:

; php.ini oder FPM-Pool, nicht per ini_set() oder .user.ini
session.upload_progress.enabled = 0

; zusätzlich nur unter PHP 8.5
fatal_error_backtraces = 0

Diese Werte wirken nur, wenn sie auf Server-Ebene gesetzt werden, also in der php.ini, in der Pool-Konfiguration oder in der Webserver-Konfiguration. Danach müssen alle Worker neu starten. Außerdem empfiehlt das PHP-Team, Konfigurationswerte aufzuräumen, die bei jeder Anfrage Warnungen erzeugen, etwa veraltete oder ungültige Direktiven. Die Warnungen mit display_errors nur auszublenden, reicht nicht. Ebenso sollten Fehler behoben werden, die ein Angreifer bewusst provozieren kann, zum Beispiel Abstürze oder Timeouts bei Uploads und Importen.

Gegen CVE-2026-109618 ist die Empfehlung ungewöhnlicher. Weil die Lücke genau dann ausgelöst wird, wenn PHP sein eigenes Speicherlimit erreicht, soll dieses Limit wegfallen und durch Grenzen ersetzt werden, die außerhalb von PHP greifen:

memory_limit = -1 setzen, und zwar so, dass die Anwendung den Wert nicht überschreiben kann, etwa mit php_admin_value im FPM-Pool oder in der Apache-Konfiguration
Anfragegrößen begrenzen: laut PHP-Team post_max_size = 8M ohne Uploads, 32M mit Uploads, und upload_max_filesize jeweils darunter
am Webserver oder Reverse Proxy Limits für Anfragegröße, Anzahl der Formularfelder, Header und Multipart-Teile setzen, die auch Anfragen ohne Content-Length erfassen
den Speicher des Prozesses von außen über Container- oder cgroup-Limits begrenzen, ausdrücklich nicht über RLIMIT_AS oder RLIMIT_DATA, da diese denselben Fehler auslösen können

Testen Sie diese Änderungen, bevor Sie sie breit ausrollen. Engere Upload-Grenzen brechen zum Beispiel große CSV-Importe oder Medien-Uploads ab, und ohne äußeres Speicherlimit kann ein einzelner Prozess den Server lahmlegen.

Nach dem Patch: prüfen, ob schon jemand drin war

Wenn ein System mehrere Tage ungepatcht im Netz stand, ist das Update nicht das Ende der Arbeit. Ein Angreifer, der vorher erfolgreich war, bleibt auch nach dem Update im System. Achten Sie in den Logs der letzten Tage auf:

auffällig viele abgebrochene Anfragen oder Speicherfehler in PHP- und Webserver-Logs
PHP-Worker, die unerwartet abgestürzt oder neu gestartet sind
neue oder kürzlich veränderte PHP-Dateien in Webverzeichnissen und Upload-Ordnern
unbekannte Prozesse oder ausgehende Verbindungen vom Webserver aus

Das NCSC-NL-Repository enthält zusätzlich Hinweise zur Erkennung. Bei einem konkreten Verdacht sollten Sie den Server nicht selbst „aufräumen“. Ein kompromittiertes System wird in aller Regel neu aufgesetzt, und Zugangsdaten, die auf dem Server lagen, werden ausgetauscht. Denken Sie auch an die DSGVO: Wurden personenbezogene Daten abgegriffen, ist eine Meldung an die Aufsichtsbehörde meist innerhalb von 72 Stunden fällig.

Die nächsten Wochen: aus dem Vorfall lernen

Lücken dieser Schwere kündigen sich nicht an. Teams, die heute in wenigen Stunden fertig waren, hatten vorher drei Dinge: eine aktuelle Liste ihrer Systeme samt Versionen, einen klaren Verantwortlichen für Updates und einen erprobten Weg, eine neue PHP-Version auszurollen. Teams, die den Tag mit Suchen verbracht haben, hatten mindestens eines davon nicht.

Wenn Sie das zweite Team waren, nehmen Sie den Vorfall als Anlass, diese drei Dinge nachzuziehen. Unsere jährliche End-of-Life-Checkliste hilft beim Inventar. Für den Rest braucht es meist kein großes Projekt, sondern eine feste Zuständigkeit und ein paar Stunden Arbeit pro Monat.

Checkliste zum Abhaken

Alle Systeme mit PHP erfassen, inklusive Staging, Altsysteme und Geräte.
Die tatsächlich vom Webserver genutzte Version prüfen, nicht nur php -v.
Internet-erreichbare Systeme mit Uploads und Formularen zuerst patchen.
Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren.
FPM bzw. Apache neu starten und die ausgelieferte Version kontrollieren.
Für PHP 8.1 und älter einen Backport einspielen und das Upgrade terminieren.
Wo kein Update möglich ist, Übergangsmaßnahmen setzen und testen.
Logs der letzten Tage auf Auffälligkeiten durchsehen.

Wo wir helfen können

Wenn Sie nicht sicher sind, welche Ihrer Systeme betroffen sind, wenn Ihre Anwendung noch auf PHP 8.1 oder älter läuft oder wenn Sie nach dem Update eine zweite Meinung zu verdächtigen Logeinträgen möchten, melden Sie sich unter hello@wolf-tech.io oder über unser Kontaktformular. Wir helfen bei der Bestandsaufnahme und beim Patchen, und auf Wunsch planen wir mit Ihnen das Upgrade Ihres Legacy-Systems oder prüfen den Zustand der Anwendung in einem Code- und Sicherheits-Audit.