Default AutomaticDecompression = All routes responses through the Brotli decoder affected by CVE-2026-111497 #2420

Describe the bug
RestClientOptions.AutomaticDecompression defaults to DecompressionMethods.All on .NET (src/RestSharp/Options/RestClientOptions.cs). Every RestClient built with default options therefore advertises Accept-Encoding: gzip, deflate, br and auto-decodes Content-Encoding: br responses through the Brotli decoder bundled in the .NET runtime.

That decoder is affected by CVE-2026-111497 (CVSS 4.0: 9.2): an out-of-bounds write in Google Brotli 1.0.3–1.2.0 triggered by a crafted stream, leading to memory disclosure, crash, or code execution in the decoding process. Public PoCs exist and code execution has been demonstrated against Node.js through the same "malicious server → auto-decompressed response" path.

HttpClientHandler/SocketsHttpHandler default to AutomaticDecompression = None, so plain HttpClient users are not exposed. RestSharp's default opts every user in without them ever mentioning Brotli. The bug is the runtime's, but as of 2026-10-24 no .NET servicing release contains the fix and no public dotnet/runtime branch has it (vendored Brotli is 1.1.0 on release/9.0–main, 1.0.9 on release/8.0; the upstream fix's BLOCK_SWITCH error code is absent on all of them), so users have no runtime update to apply.

To Reproduce

using var client = new RestClient("https://<your-request-bin>");
await client.ExecuteAsync(new RestRequest(""));

The captured request carries Accept-Encoding: gzip, deflate, br. Any server that answers with Content-Encoding: br has its body passed to the runtime's Brotli decoder before RestSharp hands it back. Same with new RestClient(new RestClientOptions(url)) — no decompression setting touched.

Expected behavior
A default RestClient should not advertise br or decode br responses while the runtime decoder is known-vulnerable and unpatched. With AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate the request carries Accept-Encoding: gzip, deflate and a br response is returned undecoded in RawBytes — the decoder is never reached. Servers that support Brotli also support gzip, so there is no functional loss.

Stack trace
None — the issue is reachability of vulnerable code, not an exception.

Desktop (please complete the following information):

• OS: macOS
• .NET version: .NET 10 (SDK 10.0.401); applies to all #if NET targets (net8.0/net9.0/net10.0). .NET Framework defaults to GZip and is not affected.
• Version: 114.1.0 (NuGet latest) and dev @ 466e5f8

Additional context
Only clients constructed from a URL, Uri or RestClientOptions are affected; a caller-supplied HttpClient/handler keeps the caller's setting. Exposure is proportional to how much control outsiders have over the URLs the client calls (third-party APIs, customer-supplied webhook endpoints, config-driven hosts).

Proposed resolution in #2419: change the .NET default to GZip | Deflate (Brotli opt-in) with docs and changelog, at least until patched runtimes ship.

References:

• Node.js advisory: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• GHSA-9v8h-qqgm-4m35: GHSA-9v8h-qqgm-4m35
• Upstream fix: google/brotli@0ed4268
• Imperva analysis: https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/