Sicherheit

PHP für Windows: Schon wieder ein Sicherheitsupdate wegen kritischer Brotli-Lücke

KI-Generiertes Foto

Kaum sind die letzten Sicherheitsupdates installiert, müssen Nutzer von PHP erneut nachbessern. Nur fünf Tage nach den letzten kritischen Patches hat das PHP-Team am 26. Oktober 2026 neue Installationspakete veröffentlicht. Diesmal steckt das Problem allerdings nicht direkt in PHP, sondern in der mitgelieferten Kompressionsbibliothek Brotli.

Die Schwachstelle mit der Kennung CVE-2026-111497 ist ernst zu nehmen. Unter bestimmten Bedingungen können Angreifer Speicherbereiche manipulieren und möglicherweise eigenen Schadcode ausführen.

Besonders unangenehm: Auch Anwendungen, die selbst keinen direkten Zugriff auf Brotli benötigen, können betroffen sein. Entscheidend ist, wie sie HTTP-Antworten verarbeiten.

Warum PHP schon wieder ein Sicherheitsupdate benötigt

Bereits am 21. Oktober hatte das PHP-Team mehrere Sicherheitsversionen veröffentlicht. Damals standen zwei kritische Schwachstellen im Mittelpunkt, die unter bestimmten Umständen eine nicht authentifizierte Ausführung von Schadcode über das Netzwerk ermöglichten.

Eigentlich sollte damit erst einmal Ruhe sein. Doch bei der Überprüfung der Windows-Pakete zeigte sich ein weiteres Problem.

Die offiziellen PHP-Versionen für Windows enthielten noch Brotli 1.2.0. Genau diese Version ist von einer neu entdeckten Sicherheitslücke betroffen.

Brotli wird unter anderem verwendet, um Daten bei der Übertragung über das Internet zu komprimieren. Das spart Bandbreite und beschleunigt beispielsweise den Austausch von Webseiteninhalten oder API-Antworten.

Das Problem liegt beim Entpacken entsprechend präparierter Daten. Durch einen Fehler im Decoder kann es zu unerlaubten Schreibzugriffen auf Speicherbereiche kommen. Im schlimmsten Fall lässt sich dieser Fehler zur Ausführung von Schadcode ausnutzen.

Google stuft die Schwachstelle mit 9,2 von 10 Punkten nach CVSS 4.0 als kritisch ein.

Diese PHP-Versionen sind betroffen

Das PHP-Team hat die offiziellen Windows-Pakete für vier Versionszweige neu erstellt.

Folgende aktualisierte Builds stehen seit dem 26. Oktober 2026 zur Verfügung:

PHP-VersionNeuer Windows-Build
PHP 8.58.5.12-1
PHP 8.48.4.27-1
PHP 8.38.3.36-1
PHP 8.28.2.35-1

Alle vier Pakete enthalten jetzt die korrigierte Bibliothek Brotli 1.2.1.

Interessant ist dabei, dass PHP selbst nicht erneut verändert werden musste. Der Quellcode entspricht weiterhin den Sicherheitsversionen vom 21. Oktober. Lediglich die mitgelieferten Komponenten wurden aktualisiert.

Das erklärt auch die etwas ungewöhnlichen Versionsnummern mit der zusätzlichen Endung -1.

Warum php -v zur Kontrolle nicht ausreicht

Wer nach dem Update über die Kommandozeile php -v aufruft, wird möglicherweise überrascht sein.

Die angezeigte PHP-Version bleibt nämlich unverändert. Auch nach dem Austausch des Windows-Pakets meldet sich beispielsweise weiterhin PHP 8.5.12.

Ob tatsächlich der korrigierte Build installiert wurde, lässt sich deshalb nicht allein anhand dieser Ausgabe feststellen.

Stattdessen sollte man die verwendete Installationsdatei kontrollieren und deren SHA-256-Prüfsumme mit den Angaben auf der offiziellen PHP-Downloadseite vergleichen.

Gerade bei manuell gepflegten Windows-Installationen ist das wichtig. Ein vermeintlich aktueller Versionsstand bedeutet hier nicht automatisch, dass auch alle Sicherheitskorrekturen enthalten sind.

Wie kann die Brotli-Sicherheitslücke ausgenutzt werden?

Die eigentliche Schwachstelle befindet sich in der Dekomprimierung von Brotli-Daten.

Ein mögliches Angriffsszenario sieht so aus:

Eine PHP-Anwendung ruft Informationen von einem externen Server ab. Dieser liefert eine manipulierte, mit Brotli komprimierte HTTP-Antwort zurück.

Ist die automatische Dekomprimierung aktiviert, verarbeitet die verwundbare Bibliothek diese Daten. Dabei kann der Speicherfehler ausgelöst werden.

Ein erfolgreicher Angriff könnte im schlimmsten Fall dazu führen, dass fremder Programmcode im Kontext des betroffenen Prozesses ausgeführt wird.

Wichtig ist allerdings die Unterscheidung: Nicht jede PHP-Installation ist automatisch über das Netzwerk angreifbar.

Für das beschriebene Szenario muss die Anwendung entsprechende Daten empfangen und die automatische Dekomprimierung über die betroffene Komponente nutzen.

Besonders interessant: cURL und Guzzle

In PHP spielt dabei die weitverbreitete cURL-Erweiterung eine entscheidende Rolle.

cURL wird häufig verwendet, um externe APIs anzusprechen, Dateien herunterzuladen oder Daten mit anderen Webdiensten auszutauschen.

Die automatische Dekomprimierung ist bei cURL grundsätzlich deaktiviert. PHP-Anwendungen können sie allerdings über die Option CURLOPT_ENCODING aktivieren.

Und genau hier wird es interessant.

Viele Entwickler arbeiten nicht unmittelbar mit cURL, sondern verwenden HTTP-Bibliotheken wie Guzzle.

Guzzle übernimmt zahlreiche Einstellungen automatisch. Dazu gehört bei Verwendung des cURL-Handlers standardmäßig auch die automatische Verarbeitung komprimierter HTTP-Antworten.

Dadurch können Anwendungen die betroffene Funktion nutzen, ohne dass Entwickler die Brotli-Unterstützung ausdrücklich aktiviert haben.

Das ist für mich einer der wichtigsten Punkte an dieser Sicherheitsmeldung: Es reicht nicht immer, nur den eigenen Anwendungscode zu betrachten. Auch die Standardeinstellungen eingesetzter Bibliotheken können darüber entscheiden, ob eine Schwachstelle erreichbar ist.

Was sollten PHP-Nutzer unter Windows jetzt tun?

Wer PHP unter Windows einsetzt, sollte die aktualisierten Pakete möglichst zeitnah installieren.

Dabei würde ich folgendermaßen vorgehen:

  1. PHP-Installation prüfen: Feststellen, welche PHP-Version verwendet wird und ob sie aus den offiziellen Windows-Builds stammt.

  2. Aktuelles Paket herunterladen: Den passenden Build mit der Endung -1 von der offiziellen PHP-Webseite beziehen.

  3. Paket kontrollieren: Die veröffentlichte SHA-256-Prüfsumme überprüfen.

  4. Installation aktualisieren: Die betroffenen PHP-Dateien und mitgelieferten Bibliotheken gemäß dem eigenen Installationsverfahren austauschen.

  5. Dienste neu starten: Sicherstellen, dass Webserver und PHP-Prozesse tatsächlich die aktualisierten Komponenten laden.

  6. Anwendungen testen: Besonders HTTP-Clients, API-Verbindungen und andere Funktionen überprüfen, die externe Daten abrufen.

Wer PHP über eine Entwicklungsumgebung oder ein Komplettpaket eines Drittanbieters installiert hat, sollte zusätzlich prüfen, ob dessen Anbieter bereits aktualisierte Versionen bereitstellt.

Das offizielle PHP-Update ersetzt schließlich nicht automatisch jede separat ausgelieferte Brotli-Bibliothek.

Übergangslösung, wenn ein Update noch nicht möglich ist

Nicht überall lassen sich Sicherheitsupdates sofort einspielen. Gerade produktive Anwendungen benötigen häufig zunächst einen kurzen Funktionstest.

Für solche Fälle gibt es zumindest eine vorübergehende Möglichkeit, das Risiko zu reduzieren.

In Anwendungen mit direkter cURL-Nutzung sollte die automatische Dekomprimierung deaktiviert bleiben. Dazu darf CURLOPT_ENCODING nicht mit einem aktivierenden Wert gesetzt werden.

Bei Guzzle lässt sich die automatische Verarbeitung komprimierter Antworten über folgende Einstellung abschalten:

'decode_content' => false

Das verhindert die automatische Dekomprimierung, betrifft allerdings nicht nur Brotli, sondern auch andere Kompressionsverfahren wie gzip.

Entsprechende Antworten werden dann nicht mehr automatisch entpackt. Anwendungen müssen daher darauf geprüft werden, ob sie mit diesen Daten umgehen können.

Wichtig: Allein das Entfernen von br aus dem HTTP-Header Accept-Encoding ist keine zuverlässige Schutzmaßnahme. Ein Server kann trotzdem Brotli-komprimierte Daten zurückliefern.

Die Deaktivierung ist außerdem ausdrücklich nur als Übergangslösung gedacht. Das eigentliche Sicherheitsupdate sollte dadurch nicht ersetzt werden.

Gibt es bereits bekannte Angriffe?

Die technische Gefahr ist keineswegs nur theoretisch.

Sicherheitsforscher von Imperva konnten die Schwachstelle bereits bei einem offiziellen Node.js-Build zur Ausführung von Code ausnutzen. Dafür waren allerdings mehrere Versuche notwendig.

Für PHP selbst sind in der offiziellen Sicherheitsmeldung bislang keine konkreten Angriffe dokumentiert.

Das bedeutet aber nicht, dass Entwarnung gegeben werden kann. Die Schwachstelle befindet sich in einer Bibliothek, die auch von anderen Anwendungen und Laufzeitumgebungen eingesetzt wird.

Neben PHP haben deshalb unter anderem Node.js und Bun entsprechende Sicherheitsupdates veröffentlicht.

Entdeckt wurde die Brotli-Schwachstelle von Sicherheitsforschern bei OpenAI. Die korrigierten Brotli-Versionen erschienen bereits am 21. Oktober 2026.

Fazit: Kleines Versionsdetail, großes Sicherheitsrisiko

Das zweite PHP-Sicherheitsupdate innerhalb weniger Tage zeigt, wie wichtig auch die Abhängigkeiten einer Software sind.

PHP selbst muss nicht zwangsläufig einen Programmierfehler enthalten, damit eine Installation angreifbar wird. Schon eine verwundbare Bibliothek im Installationspaket kann ausreichen.

Besonders tückisch finde ich in diesem Fall die unveränderte PHP-Versionsnummer. Wer ausschließlich auf php -v schaut, könnte sich bereits auf dem aktuellen Sicherheitsstand wähnen, obwohl noch die alte Brotli-Version verwendet wird.

Für Windows-Nutzer ist die Konsequenz deshalb ziemlich eindeutig: Die neu erstellten PHP-Pakete vom 26. Oktober gehören auf die Update-Liste.

Panik ist nicht notwendig, Abwarten ohne Prüfung aber ebenso wenig sinnvoll. Vor allem Anwendungen mit externen API-Anbindungen und automatischer HTTP-Dekomprimierung sollten genauer unter die Lupe genommen werden.

Letztlich ist es wieder einmal eine Erinnerung daran, dass sichere Software nicht nur aus aktuellem Anwendungscode besteht. Die Bibliotheken darunter gehören genauso dazu.

Quellen