PHP-Sicherheitslücke CVE-2026-109618: So schließen Sie sie

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen: CVE-2026-109618 und CVE-2026-109619. Beide erlauben Angreifern ohne Anmeldung, über das Netz Code auf dem Webserver auszuführen (CVSS 9,2). Die einzige vollständige Abhilfe ist das Update auf PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 und danach ein Neustart aller PHP-Prozesse.

Hier lesen Sie, wie Sie in wenigen Minuten prüfen, ob Ihre Website betroffen ist, das Update einspielen und nachweisen, dass kein alter PHP-Prozess mehr läuft. Wir haben die Updates am selben Abend auf unseren eigenen Servern eingespielt; die Prüfschritte unten stammen aus dieser Arbeit.

Was muss ich jetzt tun?

Sie betreiben einen eigenen Server oder vServer:

1. PHP-Version prüfen (Abschnitt unten).
2. Update für jede installierte PHP-Version einspielen.
3. PHP-FPM bzw. Apache neu starten.
4. Nachweisen, dass kein alter PHP-Prozess mehr läuft.
5. Spuren eines Angriffs prüfen, falls der Server länger offen war.

Ihre Website liegt bei einem Hoster (Shared Hosting, WordPress-Hosting):

1. PHP-Version Ihrer Website im Hosting-Panel oder in WordPress nachsehen.
2. Beim Hoster nachfragen, ob das Update eingespielt und PHP neu gestartet wurde.
3. Läuft Ihre Seite noch auf PHP 8.1 oder älter: im Panel auf PHP 8.3 oder neuer umstellen.

Was ist passiert?

Das PHP-Projekt hat am 21. Oktober 2026 um 14:00 UTC die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht. Die Meldung auf php.net trägt den Titel „Critical remote code execution vulnerabilities, update now“. Für Sie heißt das: Seit diesem Nachmittag sind die Lücken öffentlich dokumentiert, und jeder Server ohne Update ist ein bekanntes Ziel.

Welche PHP-Versionen sind betroffen?

Betroffen sind alle Versionen vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Sicher sind genau diese vier Versionen und jede spätere.

Für PHP 8.1 und älter verweist php.net an den jeweiligen Anbieter. Ob ein Anbieter den Fix zurückportiert hat, muss er selbst belegen. Der sichere Weg ist der Wechsel auf PHP 8.3 oder neuer, denn PHP 8.2 bekommt laut php.net nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.

Wie prüfe ich meine PHP-Version?

Entscheidend ist die Version, mit der Ihre Website läuft, nicht die auf der Kommandozeile. Beide können verschieden sein, weil oft mehrere PHP-Versionen parallel installiert sind.

• Hosting-Panel (Plesk, cPanel): Die PHP-Version steht meist in den Einstellungen der jeweiligen Domain.
• WordPress: „Werkzeuge → Website-Zustand → Bericht → Server“ zeigt die Version, mit der die Seite tatsächlich läuft.
• Eigener Server (Debian, Ubuntu): php-fpm8.4 -v zeigt die Version des FPM-Dienstes, dpkg -l 'php8.4*' die installierten Pakete. Bei Plesk liegt jede Version unter /opt/plesk/php/<Version>/bin/php.

Distributionen übernehmen den Fix teilweise in ihre eigene Versionsnummer, etwa mit einem Zusatz wie ~deb12u1. Maßgeblich ist dann der Sicherheitshinweis der Distribution, nicht die reine Upstream-Nummer.

Wie gefährlich ist die Lücke für meine Website?

Die Lücke ist ernst, weil ein Angriff weder ein Konto noch einen Klick des Opfers braucht. Alle Angaben in diesem Abschnitt stammen aus den beiden Advisories und der Meldung auf php.net (Quellen unten).

• Apache mit mod_php: Hier ist der Angriff vollständig nachgewiesen. Eine Anfrage ohne Anmeldung kann ihn auslösen, bevor Ihr Anwendungscode überhaupt läuft. Ein Sicherheits-Plugin in WordPress hilft deshalb nicht.
• PHP-FPM (typisch bei nginx und vielen Hostern) und php-cgi: ebenfalls gefährdet. Für FPM ist die Lücke im Quelltext belegt, ein vollständiger Angriff wurde nicht vorgeführt.
• FrankenPHP und LiteSpeed: ebenfalls auf der Liste der gefährdeten Installationen.

Ausgelöst wird CVE-2026-109618 zum Beispiel über ein präpariertes Formular mit Datei-Upload (multipart), das PHP den Speicher erschöpfen lässt. Ein erfolgreicher Angreifer läuft mit den Rechten des Webserver-Kontos. Damit kann er in der Regel Dateien der Website ändern und die Datenbankzugänge aus der Konfiguration lesen.

Ist das ein Zero Day?

Nach den veröffentlichten Angaben nicht im strengen Sinn. Weder die Advisories noch php.net melden, dass die Lücken vor dem Patch ausgenutzt wurden. Das PHP-Projekt hatte sich am 20. Oktober aber vorbehalten, früher zu veröffentlichen, falls Angriffe auftauchen. Seit dem 21. Oktober sind die technischen Details öffentlich, und das Zeitfenster bis zu ersten Angriffen ist erfahrungsgemäß kurz.

Wie schließe ich die PHP-Sicherheitslücke?

Sie schließen die Lücke in drei Schritten: Update einspielen, PHP-Prozesse neu starten, Erfolg messen. Der zweite Schritt wird am häufigsten vergessen.

1. PHP-Update einspielen

Auf Debian und Ubuntu kommt das Update über die Paketverwaltung, beim Hosting-Panel (Plesk, cPanel) über dessen Updatefunktion:

sudo apt update
sudo apt install --only-upgrade 'php8.4*'

Ersetzen Sie 8.4 durch Ihre Version, und wiederholen Sie den Schritt für jede installierte PHP-Version. Auch eine Version, die gerade keine Website nutzt, kann noch als Dienst laufen.

2. PHP-FPM neu starten

Ein Update ersetzt nur die Dateien auf der Platte. Laufende PHP-Prozesse arbeiten weiter mit der alten, verwundbaren Version im Speicher. Deshalb gehört nach jedem Update ein Neustart dazu:

sudo systemctl restart php8.4-fpm   # PHP-FPM
sudo systemctl restart apache2      # nur bei mod_php

3. Prüfen, ob wirklich die neue Version läuft

Am zuverlässigsten suchen Sie nach Prozessen, die noch eine gelöschte, also alte PHP-Datei geladen haben:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*(deleted)'
sudo grep -l 'libphp.*(deleted)' /proc/*/maps 2>/dev/null

Bleiben beide Ausgaben leer, läuft kein PHP-Prozess mehr mit der alten Version. Auf Debian und Ubuntu zeigt sudo needrestart -r l zusätzlich, welche Dienste noch alte Bibliotheken nutzen. Mit diesem Weg haben wir auf unseren Servern Prozesse gefunden, die ohne Neustart weiter alten Code ausgeführt hätten.

4. Spuren prüfen

War Ihr Server länger ohne Update erreichbar, lohnt ein Blick auf diese drei Stellen:

• Protokolle: Das Advisory zu CVE-2026-109619 nennt die Logs von Apache, PHP-FPM und Reverse-Proxy, zum Beispiel PHP-Warnungen vor dem eigentlichen Skript oder „Maximum execution time exceeded“. Ein fehlender Eintrag ist laut Advisory aber kein Beweis für Sicherheit.
• Geänderte Dateien: find /var/www -name '*.php' -newermt '2026-10-21' listet PHP-Dateien, die seit dem 21. Oktober geändert wurden. Eigene Deploys tauchen dort auch auf, verdächtig ist alles, was Sie nicht zuordnen können.
• Upload-Ordner: PHP-Dateien in Ordnern, die nur Bilder und Dokumente enthalten sollten (bei WordPress wp-content/uploads), sind ein Alarmzeichen.

Was tun, wenn ich nicht sofort updaten kann?

Dann können Sie die Angriffsfläche verkleinern, aber nicht schließen. Laut php.net machen diese Abschwächungen eine Installation „nicht sicher“. Sie sind eine Brücke bis zum Update. Alle Punkte stammen aus den beiden Advisories, und jede Einstellung wirkt erst nach einem Neustart der PHP-Prozesse.

• Formulareingaben begrenzen:
  • post_max_size klein halten und die Anfragegröße schon am Webserver oder Proxy begrenzen.
  • max_input_vars und max_input_nesting_level senken.
  • Die Zahl der Uploads und der Formularteile begrenzen.
• Datei-Uploads sperren, wo keine gebraucht werden: Nutzt die Anwendung keine multipart-Formulare, kann der Webserver sie abweisen.
• Upload-Fortschritt abschalten: session.upload_progress.enabled=0. Das ist auch nach dem Patch sinnvoll, wenn Sie die Funktion nicht brauchen.
• Worker kurz leben lassen: pm.max_requests=1 in PHP-FPM begrenzt, wie lange alter Zustand in einem Prozess überlebt. Das kostet Leistung.
• Speichergrenze aufheben (klingt falsch, ist aber so): memory_limit=-1 ist die wichtigste Einstellung gegen CVE-2026-109618, aber ausdrücklich unvollständig. Sie nimmt dem Angreifer die vorhersehbare Grenze, an der er den Speichermangel auslöst. Der Preis: Eine einzelne Anfrage kann dann so viel Speicher belegen, wie der Server hat.
• Kein RLIMIT_AS oder RLIMIT_DATA: Diese Grenzen lassen die Speicheranforderung scheitern und führen genau in den verwundbaren Pfad.

Häufige Fragen zur PHP-Sicherheitslücke

Ist WordPress von der PHP-Lücke betroffen?

Ja, wenn die Website auf einer ungepatchten PHP-Version läuft. Die Lücke steckt in PHP selbst, nicht in WordPress, einem Plugin oder einem Theme. Ein WordPress-Update schließt sie nicht.

Muss ich jede installierte PHP-Version einzeln aktualisieren?

Ja. Jeder Zweig (8.2, 8.3, 8.4, 8.5) ist ein eigenes Paket mit eigenem Dienst. Auf Servern mit Hosting-Panel liegen oft mehrere Versionen nebeneinander, und jede braucht ihr Update und ihren Neustart.

Reicht ein Neustart des Webservers?

Bei PHP-FPM nicht: nginx oder Apache neu zu starten, lädt PHP nicht neu. Neu starten müssen Sie den FPM-Dienst jeder Version, also zum Beispiel php8.3-fpm und php8.4-fpm.

Woran erkenne ich, dass mein Hoster PHP neu gestartet hat?

Von außen gar nicht sicher. Fragen Sie ausdrücklich nach Update und Neustart. In WordPress zeigt der Website-Zustand nach dem Neustart die neue Versionsnummer.

Gibt es eine Konfiguration, die die Lücke vollständig schließt?

Nein. Beide Advisories nennen das Update als einzige vollständige Abhilfe.

Unterstützung beim Patchen

Sie betreiben mehrere Server oder ein individuelles PHP-Projekt und wollen sicher sein, dass wirklich nichts mehr mit alter Version läuft? In einem Code- und Sicherheits-Audit prüfen wir Ihre Anwendung und ihre Laufzeitumgebung. Für eine schnelle Einschätzung erreichen Sie uns über das Kontaktformular.

Quellen

• GitHub Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• php.net: Upcoming Critical PHP Security Release (20.10.2026)
• php.net: PHP 8.2.35 Released (mit Hinweis auf das Supportende am 31.12.2026)

Stand: 22. Oktober 2026. Allgemeine technische Information ohne Gewähr; prüfen Sie die Schritte vor dem Einsatz auf Ihrem System.