Kritische PHP-Sicherheitslücken (CVE-2026-109618 und CVE-2026-109619): Was passiert ist und was Sie tun müssen

Am 21. Oktober 2026 hat das PHP-Projekt Korrekturen für zwei kritische Lücken veröffentlicht, und CERT-EU hat am selben Tag die Warnmeldung 2026-018 herausgegeben. Beide Lücken sind mit 9,2 bewertet, und beide werden als Codeausführung aus der Ferne ohne Anmeldung beschrieben. Wenn Sie eine WordPress-Seite, einen Shop oder eine andere PHP-Anwendung betreiben, betrifft Sie das, und die Abhilfe ist ein Update, keine Einstellung. Dieser Artikel erklärt, was bekannt ist, wie der Angriff hineinkommt und was Sie tun sollten. Stand: 22. Oktober 2026, nach Fassung 1.1 der CERT-EU-Meldung.

Was passiert ist

PHP hat am 20. Oktober eine Sicherheitsversion angekündigt und die Korrekturen am 21. Oktober um 13:30 UTC veröffentlicht. CERT-EU nennt seine Meldung „Critical Vulnerabilities in PHP“ und führt zwei CVEs auf: CVE-2026-109618 und CVE-2026-109619, jeweils mit der Bewertung 9,2. CERT-EU schreibt außerdem, dass die technischen Einzelheiten inzwischen öffentlich besprochen werden und erste Beispielprogramme zum Nachweis (Proof of Concept) im Umlauf sind. Die Meldung bestätigt keine Angriffe in freier Wildbahn, sagt aber, dass es dadurch wahrscheinlicher wird, dass Angreifer die Lücken bereits ausnutzen. Behandeln Sie es als dringend.

Wer betroffen ist

Betroffen ist jede PHP-Fassung unterhalb der korrigierten in einem unterstützten Zweig sowie jeder Zweig, der das Ende seiner Laufzeit erreicht hat.

CERT-EU nennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Nach Einschätzung des PHP-Teams trägt mod_php das höchste Risiko. Auch Produkte, die PHP einbetten, können betroffen sein; CERT-EU verweist dafür auf eine Liste des niederländischen NCSC am Ende dieses Artikels. Jede Installation, die Webanfragen bedient, zählt, ob sie ein Upload-Formular hat oder nicht.

Wie ein Angreifer die erste Lücke erreicht

Niemand muss sich anmelden. Nach Angaben von CERT-EU zeigt ein vorgeführter Angriff, dass eine einzige Anfrage ohne Anmeldung genügt, um den Angriff auszulösen, bevor irgendein Anwendungscode läuft. Das übersehen die meisten: Es spielt keine Rolle, ob Ihr WordPress aktuell ist, ob Ihre Plugins gepatcht sind oder ob Ihr Kontaktformular geschützt ist. Die Anfrage erreicht zuerst die PHP-Laufzeit.

Die erste Lücke, CVE-2026-109618, funktioniert so:

1. Eine Anfrage trifft bei einer Adresse ein, die PHP bedient. Keine Anmeldung, kein Konto.
2. PHP beginnt, den Inhalt der Anfrage zu lesen. CERT-EU nennt als Beispiel das Verarbeiten von formularbasierten Datei-Uploads.
3. PHP setzt sein memory_limit mit longjmp() durch. Wird die Grenze überschritten, springt es aus dem heraus, was es gerade tat, und beendet die Anfrage.
4. Geschieht das mitten beim Aufbau interner Anfragedaten, sind diese Daten nur halb aufgebaut.
5. Die anschließende Aufräumarbeit behandelt die ungültigen Daten als gültig und gibt Speicher frei, der nie initialisiert wurde. Dieser Speicher kann noch Daten früherer Zuweisungen enthalten, die der Angreifer kontrolliert hat.
6. Von dort beschreibt die Meldung Codeausführung auf dem Server.

Wie ein Angreifer den letzten Schritt lenkt, beschreiben wir bewusst nicht. Es genügt zu wissen, dass der Einstieg nicht Ihre Anwendung ist, und deshalb kann nichts innerhalb Ihrer Anwendung ihn aufhalten.

Die zweite Lücke: Zustand, der seinen Speicher überlebt

CVE-2026-109619 ist ein anderer Mechanismus mit demselben Ergebnis. PHP hält für jede Anfrage einen internen Zustand. Nach bestimmten Fehlern, etwa einem schweren Fehler (Fatal Error), kann dieser Zustand bestehen bleiben, obwohl der Speicher darunter freigegeben wurde. Die nächste Anfrage, die derselbe Worker bearbeitet, kann diesen veralteten Zustand dann verwenden, bevor er auf normalem Weg zurückgesetzt wird. Der Angreifer braucht zwei Anfragen, die auf demselben Worker landen; CERT-EU bewertet das Ergebnis wie bei der ersten Lücke: Codeausführung aus der Ferne.

Was Sie heute tun sollten

1. Finden Sie heraus, welche PHP-Version Ihre Seite tatsächlich bedient. php -v auf der Kommandozeile zeigt die Version der Kommandozeile, die von der Ihres Webservers abweichen kann. Prüfen Sie php-fpm -v, Ihr Hosting-Panel oder eine Seite, die phpinfo() aufruft. Bei Shared Hosting fragen Sie Ihren Anbieter.
2. Aktualisieren Sie auf eine korrigierte Version: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Distributionen übernehmen Korrekturen oft zurück, ohne die Versionsnummer zu ändern; suchen Sie deshalb die CVE-Nummern in der Sicherheitsmeldung Ihres Anbieters. In Containern bauen Sie aus einem aktualisierten Basis-Image neu. Das PHP-Team weist darauf hin, dass rpms.remirepo.net am Tag der Veröffentlichung noch keine Updates hatte, und empfiehlt Pakete der Distribution oder einen Bau aus dem Quellcode.
3. Starten Sie jeden PHP-Worker neu. Ein Update auf der Platte ändert keine Prozesse, die bereits laufen. Starten Sie PHP-FPM oder den Webserver neu und prüfen Sie danach die laufende Version noch einmal.
4. Wenn Sie heute nicht aktualisieren können, trennen Sie den Server von öffentlichen Netzen, bis die Korrektur eingespielt und geprüft ist. CERT-EU sagt klar, dass nur ein Update diese Lücken vollständig behebt.
5. Wenn Sie PHP 8.1 oder älter einsetzen, fragen Sie Ihren Anbieter nach der Rückportierung oder wechseln Sie auf einen unterstützten Zweig. Diese Versionen erhalten keine regulären Updates.

Gegenmaßnahmen, die das Risiko senken, aber nicht beheben

CERT-EU führt Maßnahmen auf, die einen Angriff erschweren. Die Meldung sagt ausdrücklich, dass sie eine Installation nicht sicher machen. Nutzen Sie sie, während Sie das Update vorbereiten, nicht anstelle davon.

• Gegen CVE-2026-109618: Setzen Sie memory_limit=-1 so, dass Anwendungen es nicht überschreiben können, zum Beispiel mit php_admin_value im FPM-Pool, und prüfen Sie, dass kein Pool-, Verzeichnis- oder Anwendungseintrag wieder eine endliche Grenze setzt. Setzen Sie ein niedriges post_max_size (8M ohne Uploads, 32M mit) und halten Sie upload_max_filesize darunter. Begrenzen Sie Anfragegröße, Feldanzahl, Multipart-Teile, Anzahl der Kopfzeilen und Verschachtelungstiefe am Webserver oder Proxy. Nutzen Sie eine Speichergrenze des Containers oder der cgroup als Verfügbarkeitsgrenze, aber nicht RLIMIT_AS oder RLIMIT_DATA, die den verwundbaren Zuweisungsfehler auslösen können.
• Gegen CVE-2026-109619: Setzen Sie session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in einer Serverkonfiguration, die vor dem Verarbeiten der Anfrage greift (nicht mit ini_set() oder .user.ini), und starten Sie alle Worker neu. Setzen Sie bei PHP 8.5 zusätzlich fatal_error_backtraces=0. Entfernen Sie ungültige oder veraltete Einstellungen pro Anfrage, die vor der Initialisierung Meldungen ausgeben, und beheben Sie schwere Fehler und Zeitüberschreitungen, die ein Angreifer erreichen kann.

Was SilentShield hier kann und was nicht

Das ist kein Bot-Problem, und wir sagen das lieber, als eine Produktseite etwas anderes vermuten zu lassen. Der Angriff trifft die PHP-Laufzeit, bevor etwas von uns, ein CAPTCHA, ein Plugin oder eine Firewall-Regel innerhalb Ihrer Anwendung die Anfrage sieht. Ein Bot-Schutz an einem Formular hält ihn nicht auf, und niemand sollte Ihnen sagen, dass er das tut. Die einzige vollständige Abhilfe ist das PHP-Update.

Die SilentShield-API und das Dashboard sind nicht in PHP geschrieben. Das WordPress-Plugin und das PHP-SDK laufen in Ihrem eigenen PHP, dort muss das Update also auf Ihrem Server geschehen. Nach dem Update ist der gewohnte Schutz vor Bots und Formular-Spam so nützlich wie zuvor; er war nur nie die Antwort auf dieses Problem.

Quellen

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP-Ankündigung vom 20. Oktober 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: Produkte, die PHP einbetten