How We Ruled Out CVE-2026-111497 Across Nine PHP Versions

Key Takeaways

• TuxCare’s Endless Lifecycle Support for PHP on Windows, versions 5.2 through 8.2, is not affected by CVE-2026-111497.
• No update is needed because TuxCare’s builds ship no Brotli code and their libcurl never negotiates Brotli.
• Binary scans, libcurl feature checks, live HTTP tests and a DLL side-loading test all confirmed the result.
• Upstream php.net Windows builds from PHP 8.2.31 onward do ship Brotli and need php.net’s October 26 rebuilds.

CVE-2026-111497 exposed a serious vulnerability in the Brotli decoder used by several popular software platforms, including some PHP for Windows builds. PHP responded with updated Windows packages on October 26. But not every PHP build contained the vulnerable code in the first place.

TuxCare’s Endless Lifecycle Support (ELS) for PHP delivers builds for Windows covering versions 5.2 through 8.2 that are not vulnerable to CVE-2026-111497. These builds never included Brotli support, so there’s nothing to patch for this particular flaw.

That conclusion wasn’t based on version numbers or assumptions about dependencies. Two TuxCare engineers examined the actual release packages and ran four different tests to verify that Brotli couldn’t be loaded or used.

Here’s what they found, and how to check Brotli support in your own PHP environment.

What CVE-2026-111497 actually affects

Published on October 22, 2026, CVE-2026-111497 is a buffer overflow (an out-of-bounds write, to be exact) in Google’s Brotli decoder, c/dec/decode.c, and the affected releases are Brotli 1.0.3 through 1.0.9, 1.1.0 and 1.2.0. If an attacker can get a vulnerable decoder to process a crafted Brotli stream, the result can be memory corruption, memory disclosure, a crash, or potentially code execution.

Google scored it 9.2 under CVSS 4.0, and public proof-of-concept exploits are already out. On October 27, CISA added it to its Known Exploited Vulnerabilities catalog, and the exploitation attempts reported so far have targeted Node.js. Fixes are in Brotli 1.0.10, 1.1.1 and 1.2.1.

Brotli is everywhere. Browsers, web servers, Node.js, .NET and plenty of HTTP clients use it, which is why the CVE turned up on so many vendor advisories, PHP’s included. But a line in a PHP advisory doesn’t mean every PHP binary carries the decoder.

Why some PHP for Windows builds are affected

In PHP, the road to Brotli runs through the cURL extension, ext/curl. If libcurl is compiled with Brotli and a script turns on automatic decompression, libcurl advertises br in the Accept-Encoding header and decodes whatever comes back. Automatic decompression is off by default in cURL, but applications and HTTP client libraries can switch it on. After that, a malicious server only has to answer with a crafted stream.

The key change on Windows came in PHP 8.2.31, when the upstream build started linking curl against Brotli (php-src commit 0c6fc66848, ext/curl/config.w32). From that release on, the official php.net Windows zips ship brotlidec.dll and brotlicommon.dll. Earlier official packages, including 8.1.33/8.1.34 and 8.2.29/8.2.30, don’t. That’s why the PHP project’s advisory only covers the 8.2 through 8.5 branches. On October 26, php.net followed up with rebuilt Windows packages (8.2.35-1, 8.3.36-1, 8.4.27-1 and 8.5.12-1) that bundle the fixed Brotli 1.2.1.

TuxCare’s ELS builds sit on the earlier side of that change. Our 8.2 line is based on 8.2.29 and our 8.1 line on 8.1.33, and the older lines predate it by years. Still, a baseline comparison alone wasn’t enough to close the case.

Get Endless Lifecycle Support for PHP → 

Which ELS for PHP on Windows versions are impacted?

None of them. No ELS for PHP on Windows build contains Brotli in its binaries or reports Brotli support through libcurl.

That’s a finding about the PHP runtime we ship, not a blanket statement about everything installed on the host.

How we checked the actual release builds

A “not vulnerable” verdict is only as good as the evidence behind it, so two of our engineers went through the shipped release artifacts in parallel. A missing DLL doesn’t prove Brotli isn’t compiled in somewhere or loadable another way, so they ran four tests.

We searched the binaries for Brotli code

Every Brotli decoder carries a large, distinctive static dictionary. We scanned every .dll and .exe in the current release zips for it and got zero matches, in any build. No Brotli DLL ships in any of the packages either.

We asked libcurl what it supports

In every build, curl_version() doesn’t report the Brotli feature. The libcurl inside php_curl was compiled without it. That says more than any filename search, because it reflects what the HTTP client can actually do.

We sent a Brotli response anyway

Setting CURLOPT_ENCODING to an empty string tells libcurl to offer every encoding it supports. It offered deflate, gzip and no br. Then we forced a Brotli-encoded response on it. On 5.6 through 8.2, libcurl refused with error 61, “libcurl understands deflate, gzip content encodings”. On 5.2 and 5.4, it handed back the body undecoded. The two groups behave differently, but in neither case did the Brotli data reach a decoder.

We dropped the DLLs in ourselves

One question was left. What if Brotli DLLs were already sitting on the machine? Could PHP pick them up at runtime?

The import check said no. Our php_curl.dll doesn’t import brotlidec.dll, and no binary refers to brotlidec or brotlicommon by name. We tried it anyway – trusting an import table alone felt a little too easy. We copied brotlidec.dll and brotlicommon.dll from the official php.net 8.2.35-1 package into the PHP folder, the ext folder and System32, then reran the tests on our 8.1 and 8.2 builds. Nothing changed. Brotli still wasn’t offered, and a forced Brotli response still failed with error 61.

How to check Brotli support on your own PHP host

If you run TuxCare’s Endless Lifecycle Support for PHP on Windows, you can confirm the libcurl side yourself. Run this with the PHP executable you’re assessing:

<?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;

On every ELS build covered here, the last line reads Brotli: no. It only checks libcurl’s compiled features, though, not the rest of the software on the machine.

Where the not vulnerable verdict stops

This verdict covers TuxCare’s ELS for PHP on Windows 5.2 through 8.2 and nothing else. A web server module, Node.js, .NET, a browser or a standalone curl on the same server can carry its own Brotli and needs its own check. Node.js is the first place to look, since its bundled Brotli is affected across the 22.x, 24.x and 26.x lines, with fixes in 22.23.4, 24.22.1 and 26.12.1. The separate PHP brotli extension, if you’ve installed it, also carries its own decoder (fixed in 0.21.1). For anything else, update affected Brotli versions to 1.0.10, 1.1.1 or 1.2.1.

Running an upstream php.net Windows package from 8.2.31 onward? Then your build does ship Brotli, and the PHP project’s advisory is the one to follow. The fix is the -1 rebuild for your branch. Because the PHP source didn’t change, php -v shows the same version number before and after; only the build date moves (8.2.35 reports “built: Oct 20 2026”, 8.2.35-1 reports “built: Oct 26 2026”). The direct check is curl_version()[‘brotli_version’]: the original 8.2.35 package returns brotli/1.2.0, the 8.2.35-1 rebuild returns brotli/1.2.1.

Why proving a negative matters

Most of the security work on an end-of-life runtime is finding the vulnerabilities that apply and patching them. The other part is proving which ones don’t, so your team doesn’t burn a maintenance window on a non-issue or leave a scanner finding open indefinitely.

For CVE-2026-111497, all four tests point the same way, so teams on these builds can document the not vulnerable finding and close it out. You can look up this and other CVEs across TuxCare products in the TuxCare CVE Tracker.

Questions about ELS for PHP on Windows? Contact one of our PHP patching experts.

Get Endless Lifecycle Support for PHP → 

Frequently asked questions

Does php -v show whether my Windows PHP has the Brotli fix?

Not directly. php.net‘s October 26 Windows rebuilds updated Brotli without touching the PHP source, so a patched 8.2.35-1 package still reports 8.2.35. Only the build date changes, from Oct 20 to Oct 26 2026. For a direct answer, run php -r “echo curl_version()[‘brotli_version’];”. brotli/1.2.1 means the fixed decoder; brotli/1.2.0 means you still need the rebuild.

Is CVE-2026-111497 being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on October 27, and security vendors have since reported exploitation attempts against Node.js. That doesn’t mean PHP for Windows is being exploited, and TuxCare’s ELS for PHP on Windows builds don’t contain the vulnerable decoder at all.

Do TuxCare ELS for PHP on Windows customers need to do anything?

Not for this CVE. The builds covered here, versions 5.2 through 8.2, need no update, so you can document the not vulnerable finding and close the scanner ticket.