Wie wir CVE-2026-111497 in neun PHP-Versionen ausgeschlossen haben

Wichtigste Erkenntnisse

• Der „Endless Lifecycle Support“ von TuxCare für PHP unter Windows (Versionen 5.2 bis 8.2) ist von CVE-2026-111497 nicht betroffen.
• Ein Update ist nicht erforderlich, da die Builds von TuxCare keinen Brotli-Code enthalten und deren libcurl niemals Brotli aushandelt.
• Binärscans, Überprüfungen der libcurl-Funktionen, Live-HTTP-Tests und ein Test zum Side-Loading von DLLs bestätigten das Ergebnis.
• Die Upstream-Windows-Builds von php.net ab PHP 8.2.31 enthalten Brotli und erfordern die am 26. Oktober neu erstellten Builds von php.net.

CVE-2026-111497 deckte eine schwerwiegende Sicherheitslücke im Brotli-Decoder auf, der von mehreren beliebten Softwareplattformen verwendet wird, darunter auch einige PHP-Builds für Windows. PHP reagierte am 26. Oktober mit aktualisierten Windows-Paketen. Allerdings enthielt nicht jeder PHP-Build von vornherein den anfälligen Code.

Der „Endless Lifecycle Support“ (ELS) von TuxCare für PHP bietet Builds für Windows, die die Versionen 5.2 bis 8.2 abdecken und nicht für die Sicherheitslücke CVE-2026-111497 anfällig sind. Diese Builds enthielten von vornherein keine Brotli-Unterstützung, sodass für diese spezielle Sicherheitslücke kein Patch erforderlich ist.

Diese Schlussfolgerung basierte nicht auf Versionsnummern oder Annahmen bezüglich Abhängigkeiten. Zwei Ingenieure von TuxCare untersuchten die tatsächlichen Release-Pakete und führten vier verschiedene Tests durch, um zu überprüfen, dass Brotli weder geladen noch verwendet werden konnte.

Hier erfahren Sie, was sie herausgefunden haben und wie Sie die Brotli-Unterstützung in Ihrer eigenen PHP-Umgebung überprüfen können.

Was ist von CVE-2026-111497 tatsächlich betroffen?

Veröffentlicht am 22. Oktober 2026, 111497 ist ein Pufferüberlauf (genauer gesagt ein Schreibvorgang außerhalb des zulässigen Bereichs) im Brotli-Decoder von Google, c/dec/decode.c, und die betroffenen Versionen sind Brotli 1.0.3 bis 1.0.9, 1.1.0 und 1.2.0. Wenn es einem Angreifer gelingt, einen anfälligen Decoder dazu zu bringen, einen speziell gestalteten Brotli-Stream zu verarbeiten, kann dies zu einer Speicherbeschädigung, einer Offenlegung von Speicherdaten, einem Absturz oder möglicherweise zur Ausführung von Code führen.

Google hat die Schwachstelle nach CVSS 4.0 mit 9,2 bewertet, und es sind bereits öffentliche Proof-of-Concept-Exploits im Umlauf. Am 27. Oktober hat die CISA die Schwachstelle in ihren Katalog „Known Exploited Vulnerabilities“ aufgenommen, und die bisher gemeldeten Ausnutzungsversuche richteten sich gegen Node.js. Korrekturen sind in den Versionen Brotli 1.0.10, 1.1.1 und 1.2.1 enthalten.

Brotli ist allgegenwärtig. Browser, Webserver, Node.js, .NET und zahlreiche HTTP-Clients nutzen es, weshalb die CVE in so vielen Sicherheitshinweisen verschiedener Anbieter auftauchte, darunter auch in denen von PHP. Doch eine Zeile in einem PHP-Sicherheitshinweis bedeutet nicht, dass jede PHP-Binärdatei den Decoder enthält.

Warum einige PHP-Builds für Windows betroffen sind

In PHP führt der Weg zu Brotli über die cURL-Erweiterung, ext/curl. Wenn libcurl mit Brotli kompiliert wurde und ein Skript die automatische Dekomprimierung aktiviert, gibt libcurl Folgendes an: br in der Accept-Encoding Header und dekodiert alles, was zurückkommt. Die automatische Dekomprimierung ist in cURL standardmäßig deaktiviert, kann jedoch von Anwendungen und HTTP-Client-Bibliotheken aktiviert werden. Danach muss ein böswilliger Server lediglich mit einem manipulierten Datenstrom antworten.

Die wichtigste Änderung unter Windows erfolgte im PHP 8.2.31, als beim Upstream-Build begonnen wurde, curl mit Brotli zu verknüpfen (php-src-Commit 0c6fc66848, ext/curl/config.w32). Seit dieser Version werden die offiziellen Windows-ZIP-Dateien von php.net ausgeliefert brotlidec.dll und brotlicommon.dll. Frühere offizielle Pakete, darunter 8.1.33/8.1.34 und 8.2.29/8.2.30, tun dies nicht. Aus diesem Grund bezieht sich die Sicherheitsmitteilung des PHP-Projekts nur auf die Zweige 8.2 bis 8.5. Am 26. Oktober stellte php.net neu kompilierte Windows-Pakete (8.2.35-1, 8.3.36-1, 8.4.27-1 und 8.5.12-1) bereit, die die korrigierte Version von Brotli 1.2.1 enthalten.

Die ELS-Builds von TuxCare liegen eher am Anfang dieser Änderung. Unsere 8.2-Reihe basiert auf 8.2.29 und unsere 8.1-Reihe auf 8.1.33, und die älteren Reihen sind bereits um Jahre älter. Dennoch reichte ein einfacher Basisvergleich allein nicht aus, um den Fall abzuschließen.

Erhalten Sie unbegrenzten Lifecycle-Support für PHP → 

Welche Versionen von ELS für PHP unter Windows sind davon betroffen?

Keines davon. Keine der ELS-Builds für PHP unter Windows enthält Brotli in ihren Binärdateien oder bietet Brotli-Unterstützung über libcurl.

Das ist eine Feststellung bezüglich der von uns bereitgestellten PHP-Laufzeitumgebung, keine pauschale Aussage über alles, was auf dem Host installiert ist.

Wie wir die tatsächlichen Release-Builds überprüft haben

Die Einschätzung „nicht anfällig“ ist nur so gut wie die Beweise, auf denen sie beruht. Daher haben zwei unserer Ingenieure die ausgelieferten Release-Artefakte parallel geprüft. Eine fehlende DLL beweist nicht, dass Brotli nicht irgendwo eingebunden oder auf andere Weise ladbar ist, weshalb sie vier Tests durchgeführt haben.

Wir haben die Binärdateien nach Brotli-Code durchsucht

Jeder Brotli-Decoder verfügt über ein großes, charakteristisches statisches Wörterbuch. Wir haben jede .dll und .exe Ich habe die aktuellen Release-ZIP-Dateien danach durchsucht und in keinem Build auch nur eine Übereinstimmung gefunden. Auch ist in keinem der Pakete eine Brotli-DLL enthalten.

Wir haben libcurl gefragt, was es unterstützt

Bei jedem Build, curl_version() meldet die Brotli-Funktion nicht. Die darin enthaltene libcurl php_curl wurde ohne diese Option kompiliert. Das sagt mehr aus als jede Suche nach Dateinamen, denn es spiegelt wider, wozu der HTTP-Client tatsächlich in der Lage ist.

Wir haben trotzdem eine Brotli-Antwort gesendet

Einstellung CURLOPT_ENCODING Die Angabe einer leeren Zeichenkette weist libcurl an, alle von ihr unterstützten Kodierungen anzubieten. Es wurden folgende angeboten: deflate, gzip und nein br. Dann haben wir dem System eine Brotli-kodierte Antwort aufgezwungen. Bei den Versionen 5.6 bis 8.2 hat libcurl dies mit dem Fehler 61 abgelehnt, „libcurl unterstützt die Inhaltskodierungen deflate und gzip“. Bei den Versionen 5.2 und 5.4 wurde der Body unverschlüsselt zurückgegeben. Die beiden Gruppen verhalten sich unterschiedlich, aber in keinem der beiden Fälle gelangten die Brotli-Daten zu einem Decoder.

Wir haben die DLLs selbst dort abgelegt.

Eine Frage blieb noch offen: Was wäre, wenn bereits Brotli-DLLs auf dem Rechner vorhanden wären? Könnte PHP diese zur Laufzeit erkennen?

Die Importprüfung ergab ein negatives Ergebnis. Unsere php_curl.dll spielt keine Rolle brotlidec.dll, und keine Binärdatei bezieht sich auf brotlidec oder brotlicommon namentlich. Wir haben es trotzdem versucht – sich allein auf eine Importtabelle zu verlassen, kam uns etwas zu einfach vor. Wir haben kopiert brotlidec.dll und brotlicommon.dll aus dem offiziellen php.net-Paket 8.2.35-1 in den PHP-Ordner, die ext Ordner und System32, dann haben wir die Tests mit unseren Builds 8.1 und 8.2 erneut durchgeführt. Es hat sich nichts geändert. Brotli wurde weiterhin nicht angeboten, und der Versuch, eine Brotli-Antwort zu erzwingen, schlug weiterhin mit Fehler 61 fehl.

So überprüfen Sie die Brotli-Unterstützung auf Ihrem eigenen PHP-Host

Wenn Sie den „Endless Lifecycle Support for PHP“ von TuxCare unter Windows nutzen, können Sie die libcurl-Komponente selbst überprüfen. Führen Sie dazu den folgenden Befehl mit der PHP-Ausführungsdatei aus, die Sie überprüfen möchten:

<?php
$v = curl_version();
echo 'libcurl ', $v['version'], PHP_EOL;

// CURL_VERSION_BROTLI exists on PHP 7.3+; its value is 1 << 23
$brotli = defined('CURL_VERSION_BROTLI') ? CURL_VERSION_BROTLI : (1 << 23);
echo 'Brotli: ', ($v['features'] & $brotli) ? 'YES' : 'no', PHP_EOL;

Bei jedem hier behandelten ELS-Build lautet die letzte Zeile Brotli: no. Dabei werden jedoch nur die kompilierten Funktionen von libcurl überprüft, nicht die übrige Software auf dem Rechner.

Wo das Urteil „nicht gefährdet“ endet

Dieses Urteil bezieht sich ausschließlich auf TuxCares ELS für PHP unter Windows in den Versionen 5.2 bis 8.2 und auf nichts anderes. Ein Webserver-Modul, Node.js, .NET, ein Browser oder ein eigenständiges curl auf demselben Server können über ein eigenes Brotli verfügen und müssen separat überprüft werden. Node.js sollte als Erstes überprüft werden, da das darin enthaltene Brotli in den Versionsreihen 22.x, 24.x und 26.x betroffen ist; Korrekturen sind in den Versionen 22.23.4, 24.22.1 und 26.12.1 enthalten. Die separate PHP-Brotli-Erweiterung enthält, sofern Sie sie installiert haben, ebenfalls einen eigenen Decoder (behoben in 0.21.1). In allen anderen Fällen aktualisieren Sie die betroffenen Brotli-Versionen auf 1.0.10, 1.1.1 oder 1.2.1.

Verwenden Sie ein Upstream-Windows-Paket von php.net ab Version 8.2.31? Dann enthält Ihr Build tatsächlich Brotli, und Sie sollten sich an die Empfehlung des PHP-Projekts halten. Die Lösung ist ein -1-Neubau für Ihren Zweig. Da sich der PHP-Quellcode nicht geändert hat, zeigt „php -v“ vor und nach dem Neuaufbau dieselbe Versionsnummer an; lediglich das Erstellungsdatum ändert sich (8.2.35 meldet „built: Oct 20 2026“, 8.2.35-1 meldet „built: Oct 26 2026“). Die direkte Überprüfung erfolgt über `curl_version()[‘brotli_version’]`: Das ursprüngliche 8.2.35-Paket gibt `brotli/1.2.0` zurück, der 8.2.35-1-Neubau gibt `brotli/1.2.1` zurück.

Warum es wichtig ist, das Gegenteil zu beweisen

Der Großteil der Sicherheitsarbeit bei einer Laufzeitumgebung am Ende ihres Lebenszyklus besteht darin, die betroffenen Schwachstellen zu identifizieren und zu beheben. Der andere Teil besteht darin, nachzuweisen, welche Schwachstellen nicht betroffen sind, damit Ihr Team kein Wartungsfenster für ein nicht vorhandenes Problem verschwendet oder einen Scanner auf unbestimmte Zeit auf der Suche nach offenen Schwachstellen laufen lässt.

Was CVE-2026-111497 betrifft, so weisen alle vier Tests in dieselbe Richtung, sodass Teams, die diese Builds verwenden, das Ergebnis „nicht anfällig“ dokumentieren und den Eintrag schließen können. Diese und andere CVEs für alle TuxCare-Produkte können Sie im TuxCare CVE Tracker nachschlagen.

Haben Sie Fragen zu ELS für PHP unter Windows? Wenden Sie sich an einen unserer PHP-Patching-Experten.

Erhalten Sie unbegrenzten Lifecycle-Support für PHP → 

Häufig gestellte Fragen

Ist php -v Kann ich feststellen, ob mein Windows-PHP den Brotli-Fix enthält?

Nicht direkt. php.nethat in seinen am 26. Oktober veröffentlichten Windows-Builds Brotli aktualisiert, ohne den PHP-Quellcode zu verändern, sodass ein gepatchtes 8.2.35-1-Paket weiterhin 8.2.35 anzeigt. Lediglich das Erstellungsdatum ändert sich von 20. Oktober auf 26. Oktober 2026. Um eine direkte Antwort zu erhalten, führen Sie folgenden Befehl aus: `php -r “echo curl_version()[‘brotli_version’];”`. „brotli/1.2.1“ bedeutet, dass der Decoder korrigiert wurde; „brotli/1.2.0“ bedeutet, dass Sie den Neuaufbau noch benötigen.

Wird CVE-2026-111497 ausgenutzt?

Ja. Die CISA hat die Schwachstelle am 27. Oktober in den Katalog „Known Exploited Vulnerabilities“ aufgenommen, und Sicherheitsanbieter haben seitdem von Ausnutzungsversuchen gegen Node.js berichtet. Das bedeutet jedoch nicht, dass PHP für Windows ausgenutzt wird, und die ELS-Builds von TuxCare für PHP unter Windows enthalten den anfälligen Decoder überhaupt nicht.

Müssen Kunden, die TuxCare ELS für PHP unter Windows nutzen, irgendetwas unternehmen?

Nicht für diese CVE. Die hier behandelten Builds (Versionen 5.2 bis 8.2) erfordern kein Update, daher können Sie das Ergebnis „nicht anfällig“ dokumentieren und das Scanner-Ticket schließen.