PHP-Windows-Update behebt kritische Brotli-Schwachstelle, die code execution ermöglicht
Das PHP-Windows-Update für PHP 8.2 bis 8.5 ersetzt in den offiziellen Paketen des Projekts eine anfällige Kopie von Brotli, einer Bibliothek zur Komprimierung von Daten. Laut PHP kann CVE-2026-111497, eine Kennung aus dem öffentlichen System Common Vulnerabilities and Exposures zur Erfassung einer Sicherheitslücke, memory corruption verursachen und einem Angreifer potenziell code execution auf einem betroffenen System ermöglichen.
Laut PHP ist die Schwachstelle über cURL erreichbar, eine Softwarebibliothek, die Anwendungen für Webanfragen verwenden, wenn cURL bei einer HTTP response automatic decompression durchführt. HTTP ist das Protokoll für den Austausch von Webanfragen und -antworten. Bei automatic decompression fordert eine Anwendung komprimierte Inhalte von einem entfernten Server an und entpackt diese anschließend für die Anwendung. cURL aktiviert dieses Verhalten nicht standardmäßig, doch PHP-Anwendungen und HTTP-client-Bibliotheken können es einschalten.
In PHP-Code aktiviert die Option CURLOPT_ENCODING automatic decompression. Wird dieser Option ein leerer Wert übergeben, akzeptiert cURL jedes unterstützte Komprimierungsformat. Für einen Angriff wäre eine speziell präparierte komprimierte Antwort von einem Server erforderlich, den die PHP-Anwendung kontaktiert. Anwendungen, die Inhalte von externen oder anderweitig nicht vertrauenswürdigen Servern abrufen, sind daher ein wichtiger Bestandteil des von PHP beschriebenen Expositionsszenarios.
Guzzle, eine PHP-Bibliothek zum Senden von HTTP-Anfragen, verwendet laut dem Code der Releases 7.16.1 und 8.3.1 standardmäßig diesen leeren CURLOPT_ENCODING-Wert, wenn Anfragen über cURL gesendet werden. Ausgehend von diesem Verhalten und der Erklärung von PHP erfüllt eine Anwendung mit den Standardeinstellungen von Guzzle die Voraussetzung zum Erreichen der Schwachstelle, wenn sie auf den betroffenen Windows-Paketen läuft. The Hacker News erklärte, diesen Pfad nicht auf einem Windows-System getestet zu haben.
Die korrigierten Pakete sind PHP 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1. Sie erscheinen fünf Tage nach den Releases vom 21. Oktober, die zwei PHP2Shell-Schwachstellen für remote code execution behoben hatten. remote code execution bedeutet, dass ein Angreifer ein anfälliges System dazu bringen kann, Anweisungen auszuführen. Die neu erstellten Pakete behalten denselben PHP-Quellcode und damit diese früheren Fehlerbehebungen bei, ersetzen jedoch die mitgelieferte Komprimierungsbibliothek durch Brotli 1.2.1.
Administratoren müssen auf den Paket-Build achten, statt sich auf die normale PHP-Versionsanzeige zu verlassen. Der Befehl php -v zeigt vor und nach dem Austausch dieselbe Version an, weil sich die PHP-Quellcodeversion nicht geändert hat. Der neue Build ist stattdessen am -1 im Dateinamen zu erkennen, beispielsweise php-8.5.12-1-nts-Win32-vs17-x64.zip, sowie am SHA-256-Wert auf der Downloadseite von PHP. SHA-256 ist ein digitaler Fingerabdruck, der mit einer heruntergeladenen Datei verglichen werden kann, um zu prüfen, ob das vorgesehene Paket heruntergeladen wurde.
PHP veröffentlicht außerdem eine software bill of materials, also eine Liste der Komponenten, die in jedem Paket enthalten sind. Die Listen für die vorherigen x64 Non Thread Safe-Builds aller vier unterstützten Entwicklungszweige nennen Brotli 1.2.0, das betroffen ist. x64 bezeichnet einen 64-Bit-Build, während Non Thread Safe ein PHP-Pakettyp für Umgebungen ist, die keine thread-safety-Unterstützung von PHP benötigen.
Die Schweregradeinschätzungen unterscheiden sich, weil verschiedene Versionen des Common Vulnerability Scoring System oder CVSS verwendet werden. Google bewertete die Schwachstelle mit 9,2 von 10 und stufte sie gemäß CVSS 4.0 als Critical ein. Red Hat bewertete sie mit 8,1 und stufte sie gemäß CVSS 3.1 als Important ein.
In den genannten Informationen gab es keine bestätigte Ausnutzung. Forschern von Imperva gelang über dieselbe Brotli-Schwachstelle code execution bei einem offiziellen Node.js-Build, ihr Test erforderte jedoch mehrere Versuche. Die Mitteilung von PHP meldet keine Angriffe. Eine Einschätzung der Cybersecurity and Infrastructure Security Agency oder CISA vom 23. Oktober verzeichnete keine Ausnutzung, und die Schwachstelle war zum Stand der Aktualisierung dieses Tages nicht im Known Exploited Vulnerabilities-Katalog von CISA enthalten.
Forscher von OpenAI entdeckten die Schwachstelle, und Google veröffentlichte bei ihrer Bekanntgabe am 21. Oktober die korrigierten Brotli-Versionen 1.2.1, 1.1.1 und 1.0.10. Node.js, Bun und andere Software, die eine eigene Kopie von Brotli mitliefert, haben ebenfalls Fehlerbehebungen veröffentlicht. Für die offiziellen Windows-Pakete von PHP empfiehlt PHP, die neu erstellten Downloads zu installieren.
Die Mitteilung von PHP nennt keinen workaround für Systeme, die noch nicht aktualisiert werden können. OpenAI empfiehlt, automatic decompression für Brotli in HTTP clients zu deaktivieren, bis die korrigierte Software installiert ist. Zudem warnt OpenAI, dass das bloße Entfernen von br, dem Brotli-Wert im Accept-Encoding-request header, einen Server nicht daran hindert, eine mit Brotli komprimierte Antwort zu senden.
Bei PHP-Anwendungen, die cURL direkt verwenden, bedeutet diese Empfehlung, CURLOPT_ENCODING nicht zu setzen, da cURL die Antwort andernfalls nicht dekomprimiert. Bei Guzzle können Anwendungen die request option decode_content auf false setzen. Dadurch wird die gesamte automatic response decoding deaktiviert, sodass auch mit gzip komprimierte Antworten komprimiert bleiben und entsprechend verarbeitet werden müssen. Websitebetreiber, die PHP nicht selbst verwalten, sollten ihren Hosting- oder IT-Anbieter fragen, ob die betroffenen Windows-Pakete installiert sind und ob das neu erstellte Paket eingespielt wurde. Organisationen, die bei der Überprüfung betroffener Umgebungen externe Unterstützung benötigen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen.
Die unmittelbare Priorität besteht darin, den betroffenen Windows-Build zu ersetzen und das neue Paket anhand des Dateinamens und des SHA-256-Werts zu überprüfen. Nur php -v zu prüfen, reicht nicht aus, da die angezeigte PHP-Version nach diesem Security-Rebuild unverändert bleibt.