PHP’s Windows rebuilds bring a Brotli fix the runtime number cannot show

On October 26, 2026, PHP published rebuilt Windows packages containing a security fix for Brotli, a compression library. The new packages retain the same PHP runtime versions as the source releases they replace. That makes this a dependency repair worth tracking separately: the familiar version number alone cannot tell you whether this particular Windows package update was installed. [1]

The upstream Brotli 1.2.1 release identifies CVE-2026-111497 as an out-of-bounds write that permits remote code execution. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on October 27. Those are dated developments being explained here on November 4, rather than a new vulnerability discovered this morning. [2] [3]

A small suffix carries a meaningful change

PHP lists the updated Windows builds as 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1. They contain Brotli 1.2.1. The project explains that the -1 suffix marks a Windows package rebuild with changed dependencies; the PHP source release and reported runtime version remain unchanged. [1]

Our operational interpretation is that package identity deserves a place alongside runtime identity in a maintenance record. A dashboard might accurately report PHP 8.4.27 while leaving the Windows rebuild unresolved. The dashboard has answered a narrower question than the change owner needed. Version numbers are useful witnesses, but this one needs somebody to ask a follow-up.

PHP’s Windows download page also distinguishes architecture and thread-safety variants. That reinforces a practical point for release owners: the replacement artifact needs to match the application’s actual hosting arrangement. A package’s security relevance and its suitability for a particular installation are separate decisions, both of which belong in the deployment review. [5]

The relevant input can arrive in an HTTP response

The PHP notice identifies a specific route to the decoder: the cURL extension with automatic HTTP response decompression enabled. cURL disables that feature by default, but applications and HTTP client libraries can enable it. The notice therefore calls for attention to how the application makes requests, beyond whether the extension is present. [1]

The libcurl documentation describes how its encoding option enables automatic response decoding. A setting that accepts all encodings supported by a particular build can include Brotli when that support is present. It also distinguishes enabling decoding from merely adding an Accept-Encoding header. Those details matter when interpreting what a client library actually does. [4]

Consider a hypothetical supplier integration that fetches product information through an HTTP client. The client may arrange compression support for efficiency, so the business code receives ordinary decoded content. In that example, the relevant review includes the response-handling library and its underlying decoder. Looking only at the page where a customer submits an order would miss the part of the workflow under discussion.

This illustration does not establish that any supplier response is malicious or that a particular application is vulnerable. Our interpretation is simply that outbound integrations belong in the exposure discussion. The application is a client in that exchange, but it is still processing bytes supplied by another system.

Known exploitation is important context, with a clear limit

CISA’s catalog records exploitation of the Brotli vulnerability and describes possible memory disclosure, service disruption and code execution from a crafted compressed stream. Its entry identifies the open-source component as something that can appear in multiple products. That entry does not by itself identify a compromised PHP installation or demonstrate that every Windows application reaches the decoder. [3]

For prioritization, we would combine that evidence with the vendor’s affected-path description and the installation’s real package contents. A default setting is useful context; an unexamined assumption that every application preserves that default is less useful. The person responsible for the integration and the person responsible for the Windows package may need to compare notes.

The repair deserves its own completion evidence

Our recommendation is to retain evidence of the replacement package and the process that uses it, together with a representative successful integration check. Normal compressed responses and ordinary error handling both matter to the business workflow. This is a release-management implication of the advisory, rather than a claim that a generic smoke test proves a decoder is secure.

The earlier PHP patch discussion covers the October core advisories and the importance of vendor context. This Windows rebuild concerns a different vulnerability in a bundled dependency. Completing the earlier core update should therefore lead to a fresh question about the package rebuild, with its own answer and evidence. [6]

The useful lesson is precise: a maintained application includes the libraries inside its distribution as well as the runtime on its label. Tracking that distinction makes a small packaging detail visible before it disappears into a reassuring green status box. Here, the extra suffix earns its space in the change record.