PHP-CVE-2026-109618/109619: Schutzmaßnahmen

In der PHP-Kern-Engine wurden die Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 veröffentlicht, die durch abnormale Beendigungen und die Verwaltung des Anforderungsstatus eine nicht authentifizierte Ausführung beliebigen Codes (RCE) aus der Ferne ermöglichen. Das Problem betrifft nicht Webanwendungen wie WordPress oder gnuboard, sondern beruht auf Speicherbeschädigung und Use-After-Free-Fehlern in der PHP-Laufzeit-Engine selbst. Für die Behebung sollten Sie umgehend auf eine Version mit den Sicherheits-Patches wie PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren und die Worker-Prozesse neu starten.

Eine Aktualisierung der Webanwendung allein schützt nicht vor der PHP-Engine-Sicherheitslücke

Am 21. Oktober 2026 (UTC) veröffentlichte das PHP-Entwicklungsteam zwei Sicherheitslücken, die nach CVSS v4.0 mit einem Risiko von 9,2 bewertet wurden. Angreifer können ohne Anmeldung allein durch das Senden einer manipulierten HTTP-Anforderung beliebigen Code auf dem Server ausführen.

Die Fehler befinden sich in der PHP-Kernschicht, die Webanforderungen analysiert und Speicher bereinigt. Daher bleibt eine Website angreifbar, wenn die PHP-Laufzeit selbst veraltet ist, auch wenn das CMS und die Plug-ins der Website aktuell gehalten werden. Besonders in Umgebungen mit der Standardkonfiguration von Apache mit mod_php soll die Codeausführung bereits mit einer einzigen Anforderung möglich sein, bevor der Code der Webanwendung ausgeführt wird.

Bei einem erfolgreichen Angriff erlangt der Eindringling die Berechtigungen des Systemkontos, unter dem der PHP-Prozess ausgeführt wird. Dadurch erhält er nicht unmittelbar Root-Berechtigungen, kann jedoch beispielsweise eine Webshell im Webroot-Verzeichnis erstellen oder in Konfigurationsdateien hinterlegte Datenbank-Zugangsdaten auslesen, um interne Daten zu stehlen oder zu manipulieren. Wenn mehrere Websites auf einem Server dasselbe PHP-FPM-Ausführungskonto gemeinsam verwenden, besteht außerdem das Risiko, dass sich die Kompromittierung einer Website auf andere Websites auf dem Server ausbreitet.

Prinzip der Speicherbeschädigung und des Use-After-Free bei abnormalen Beendigungen

Beide Sicherheitslücken entstehen, weil der Speicher in einer Ausnahmesituation während der Verarbeitung einer Anforderung nicht sicher bereinigt wird. Die Auslösebedingungen und internen Abläufe unterscheiden sich jedoch.

CVE-2026-109618 (Speicherbeschädigung bei der Verarbeitung einer Überschreitung des Speicherlimits): Wenn PHP während der Verarbeitung einer Anforderung das zulässige Speicherlimit (Out-Of-Memory) überschreitet, ruft es longjmp() auf und bricht die Ausführung sofort ab. Wird die Verarbeitung angehalten, bevor die internen Anforderungsdatenstrukturen vollständig initialisiert sind, bleibt ein unvollständiger Zustand bestehen, ohne zurückgesetzt zu werden. Die anschließend ausgeführte Bereinigungsroutine (cleanup) vertraut auf diesen nicht initialisierten Speicher als gültige Daten und greift darauf zu, was zu Speicherbeschädigung und entfernter Codeausführung führen kann.

CVE-2026-109619 (Use-After-Free durch Verweis auf freigegebenen Speicher einer vorherigen Anforderung): Einige globale Zustände oder Fehlerbehandlungszustände in PHP verweisen vorübergehend auf einen Speicherbereich, der einer einzelnen Anforderung gehört. Wird eine Anforderung aufgrund eines schwerwiegenden Fehlers (fatal error) oder Speichermangels abnormal beendet, kann der eigentliche Speicher freigegeben werden, während die interne Zeigerreferenz darauf nicht initialisiert wird und bestehen bleibt. In Umgebungen wie PHP-FPM oder mod_php, in denen Worker-Prozesse wiederverwendet werden, verarbeitet derselbe Worker anschließend eine weitere HTTP-Anforderung. Beim erneuten Lesen des bereits freigegebenen Speicherbereichs (Use-After-Free) kann so ein Pfad zur Codeausführung entstehen.

Die offizielle Sicherheitsmitteilung nennt als bestätigte Pfade für CVE-2026-109619 die Funktion zur Anzeige des Fortschritts von Sitzungs-Uploads (session.upload_progress), Konfigurationswarnungen, die vor der Initialisierung der Anforderung ausgegeben werden, sowie den Backtrace schwerwiegender Fehler in PHP 8.5 (fatal_error_backtraces). Sie weist jedoch darauf hin, dass auch nach der Blockierung dieser Pfade weitere Varianten bestehen bleiben.

Patch-Status der PHP-Versionen und Auswirkung je nach Ausführungsumgebung

Betroffen sind PHP-Versionen 8.2 bis 8.5, die älter als die korrigierten Versionen sind. Für das nicht mehr unterstützte PHP 8.1 und ältere Versionen sind keine offiziellen Updates des PHP-Projekts vorgesehen. Betroffen sind alle Installationen, die Webanforderungen verarbeiten, darunter PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed. In der offiziellen Mitteilung wird mod_php als besonders gefährdet eingestuft. Red Hat klassifiziert PHP-FPM als bedingt betroffen, wenn der entsprechende Pfad auf Anwendungsebene genutzt wird.

Geprüfte Umgebung: Am 22. Oktober 2026 wurde in einer Linux-Server-Umgebung mit dem Remi-Repository PHP 8.4.26 auf 8.4.27 aktualisiert. Anschließend wurden der Neustart der PHP-FPM-Worker und die Verarbeitung von Webanforderungen überprüft.

Vorgehen zur Paketaktualisierung und Anwendung von PHP-FPM-Abmilderungen

Das PHP-Entwicklungsteam weist darauf hin, dass sich nicht alle Angriffspfade allein durch Konfigurationsänderungen blockieren lassen. Die einzige vollständige Lösung besteht in der Aktualisierung auf eine korrigierte Patch-Version. Zusätzlich können Sie nicht benötigte Funktionen deaktivieren, um die Angriffsfläche weiter zu reduzieren.

1. PHP-Paketaktualisierung installieren
   Aktualisieren Sie die Pakete über den Paketmanager des Betriebssystems auf die korrigierte Version der verwendeten PHP-Reihe, beispielsweise 8.4.27 bei PHP 8.4. Prüfen Sie nach der Installation zunächst die CLI-Version im Terminal.

   php -v

   Nach Ausführung des Befehls werden beispielsweise die aktualisierte Versionsnummer PHP 8.4.27 (cli) und das Build-Datum angezeigt. Die CLI-Version und die Version des PHP-Prozesses, der tatsächlich mit dem Webserver verbunden ist, können jedoch voneinander abweichen. Führen Sie daher unbedingt den nächsten Schritt aus.

2. PHP-FPM-Konfiguration zur Verringerung der Angriffsfläche anpassen (optional und vorübergehende Abmilderung)
   Wenn die Aktualisierung nicht sofort möglich ist oder Sie eine zusätzliche Schutzschicht einrichten möchten, sichern Sie php.ini oder die PHP-FPM-Pool-Konfigurationsdatei, beispielsweise /etc/php-fpm.d/www.conf, und passen Sie die folgenden Einträge an.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Durch die Deaktivierung von session.upload_progress.enabled lässt sich der bestätigte sitzungsbasierte Angriffspfad blockieren. Wenn Sie post_max_size reduzieren – beispielsweise auf 8M in Umgebungen ohne Datei-Uploads oder auf 32M in Umgebungen mit Datei-Uploads –, werden Versuche erschwert, durch große Anforderungen einen Speichermangel herbeizuführen. Berücksichtigen Sie dabei die Größe zusätzlicher Multipart-Header und setzen Sie upload_max_filesize etwas niedriger als post_max_size. In PHP-8.5-Umgebungen sollten Sie zusätzlich fatal_error_backtraces = 0 festlegen.

3. Syntax der PHP-FPM-Konfiguration prüfen und Prozesse neu starten
   Speichern Sie die Konfiguration, testen Sie sie auf Syntaxfehler und starten Sie anschließend den PHP-FPM-Dienst neu.

   php-fpm -t
   systemctl restart php-fpm

   Wenn bei der Ausführung von php-fpm -t kein Konfigurationsproblem vorliegt, wird die Meldung NOTICE: configuration file ... test is successful angezeigt. Durch den Neustart der Worker-Prozesse werden die bisher im Speicher verbliebenen veralteten Worker beendet und der neue Patch sowie die neue Konfiguration übernommen.

4. Tatsächlich verwendete Version über eine Webanforderung prüfen
   Rufen Sie die Registerkarte „Site-Status (Site Health)“ in WordPress oder eine Diagnose-Seite für die Webserver-Anbindung auf. Prüfen Sie, ob der PHP-FPM-Worker, der Webanforderungen verarbeitet, mit einer korrigierten Version wie 8.4.27 antwortet. Falls Sie für die Prüfung vorübergehend eine PHP-Diagnosedatei erstellt haben, löschen Sie sie unmittelbar danach, damit keine Systeminformationen nach außen gelangen.

Vorgehen bei Verzögerungen oder Nebenwirkungen der Konfigurationsänderung

Pakete lassen sich wegen einer verspäteten Spiegelung in Drittanbieter-Repositorys wie Remi nicht herunterladen

Unmittelbar nach einem dringenden Sicherheits-Patch kann es durch hohe Auslastung oder Verzögerungen bei der Synchronisierung vorkommen, dass Aktualisierungspakete in Drittanbieter-Repositorys wie rpms.remirepo.net nicht sofort verfügbar sind oder nur langsam heruntergeladen werden. In der offiziellen Mitteilung wird darauf hingewiesen, dass am Tag der Veröffentlichung möglicherweise noch kein Update in diesem von Freiwilligen betriebenen Repository bereitsteht. Es wird empfohlen, auf Distributionspakete oder einen Build aus dem Quelltext auszuweichen.

In diesem Fall können Sie in der Repository-Konfiguration direkt eine normal erreichbare, synchronisierte Spiegelserver-Adresse festlegen und die Aktualisierung durchführen. Auch bei einer manuellen Änderung des Spiegels muss die GPG-Signaturprüfung (gpgcheck=1) aktiviert bleiben, um Paketmanipulationen zu verhindern. Falls kein Spiegel verwendet werden kann, nutzen Sie das offizielle Backport-Paket der OS-Distribution oder kompilieren Sie den Quelltext selbst.

Vorsicht vor Speichermangel (OOM) oder abgelehnten Uploads nach Anwendung der Abmilderung

Die offizielle Mitteilung nennt memory_limit = -1 (unbegrenzt) als Abmilderung für CVE-2026-109618, wenn eine sofortige Aktualisierung nicht möglich ist, und empfiehlt zugleich eine Speicherbegrenzung für Container oder cgroups. Wird das Speicherlimit jedoch auf einem Server mit knappem physischem Speicher aufgehoben, kann eine einzelne Anforderung den gesamten Serverspeicher verbrauchen. Der OOM-Killer des Betriebssystems könnte dann wichtige Daemons zwangsweise beenden und einen Ausfall verursachen. Diese Einstellung ist nur als vorübergehende Maßnahme bis zur Aktualisierung gedacht. Nach dem Update auf eine korrigierte Version sollten Sie sicherheitshalber zum ursprünglichen Speicherlimit zurückkehren.

Wenn Sie außerdem post_max_size gegenüber dem bisherigen Wert, beispielsweise 64 MB, reduzieren, prüfen Sie zunächst die Dateiübertragungsmethode der Website. Websites, auf denen große Sicherungsdateien oder Plug-ins direkt über eine Administrationsseite hochgeladen werden, können dadurch Uploads blockieren. Wird die Übertragung großer Dateien dagegen über SFTP oder rsync durchgeführt oder ist das anwendungsseitige Limit bereits auf höchstens 30 MB gesetzt, hat eine Reduzierung des PHP-Upload-Limits auf 32 MB keine Auswirkungen auf den Dienst.

Wenn PHP-FPM-Worker nach einem PHP-Versionsupgrade gelegentlich unerwartet beendet werden, sollten Sie auch die JIT-Kompilierung (Just-In-Time) von OPcache prüfen. Die JIT-Funktion, beispielsweise opcache.jit=1255, steht nicht in direktem Zusammenhang mit dieser Sicherheitslücke. Wenn es jedoch bei früheren Versionswechseln Stabilitätsprobleme gab, können Sie sie mit opcache.jit=off in der Konfigurationsdatei deaktivieren, um Abstürze zu vermeiden.

Häufig gestellte Fragen

Ist das Problem behoben, wenn ich WordPress oder die Plug-ins auf die neueste Version aktualisiere?

Nein. Die Sicherheitslücke befindet sich in der PHP-Kern-Engine und tritt auf, bevor WordPress oder ein Sicherheits-Plug-in ausgeführt wird. Eine Web Application Firewall wie Cloudflare oder AWS WAF kann bekannte Angriffsmuster vorübergehend blockieren. Für eine grundlegende Behebung muss jedoch die PHP-Version des Servers über den Hosting-Anbieter oder den Serveradministrator aktualisiert werden.

Ist der Betrieb sicher, wenn ich session.upload_progress.enabled deaktiviere und nicht aktualisiere?

Nein. Laut offizieller Mitteilung blockiert diese Einstellung nur den bestätigten Sitzungs-Pfad, nicht aber andere Varianten. Außerdem muss die Einstellung vor der Interpretation der Anforderung in php.ini, im FPM-Pool oder in der Serverkonfiguration gesetzt werden, nicht über ini_set() oder die FPM-Datei .user.ini. Alle Worker müssen anschließend neu gestartet werden. Eine vollständige Behebung ist nur durch die Installation des Patches möglich.

Kann ich nach Abschluss des Patch-Updates ohne weitere Prüfung direkt in den produktiven Betrieb gehen?

Das Update verhindert künftige Angriffe, zeigt jedoch nicht, ob eine frühere Kompromittierung stattgefunden hat. Prüfen Sie daher auch nach der Aktualisierung, ob bereits ein Eindringen erfolgt ist. Suchen Sie in den Webverzeichnissen nach kürzlich ungewöhnlich erstellten oder geänderten PHP-Dateien, etwa Webshells. Untersuchen Sie außerdem die Zugriffs- und PHP-Fehlerprotokolle auf ungewöhnlich große POST-Anforderungen oder wiederholte Speichermangel-Fehler.

Wie sollte ich in Container- oder Cloud-Image-Umgebungen vorgehen?

Eine Aktualisierung der Pakete auf dem Host ändert nicht automatisch die PHP-Laufzeit, die im Container enthalten ist. Bauen Sie daher das Container-Image mit einem Basis-Image neu, in dem eine korrigierte Version – 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 – enthalten ist, und stellen Sie es anschließend erneut bereit.

Quellen

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (Koreanisch)