Skip to content

Track CVE-2026-111497 in Brotli bundled with the default curl_cffi backend #3012

Open

Description

@hearkenmx

Describe bug

Resubmission of #3011: the original was automatically closed for using level-2 headings instead of the required issue-form headings. Its body was corrected, but GitHub does not allow me to reopen it. Please use this report; the original will be marked as superseded.

CVE-2026-111497 is a publicly disclosed memory-safety vulnerability in the Brotli decoder. I am reporting a downstream dependency concern: the default curl_cffi backend used by the latest yfinance release can load a native library containing the affected Brotli version, and its HTTP client enables Brotli response decompression by default.

Tested with yfinance 1.7.0 and curl_cffi 0.16.3 on Linux x86_64 / Python 3.12.3. Both are the latest stable PyPI releases at the time of checking (2026-10-23). The native library reports brotli/1.2.0, and the new error name introduced by the public Brotli fix is not recognized.

This is a report about the client-side dependency chain, not a claim that Yahoo Finance is compromised or that ordinary market-data requests demonstrate remote code execution. A malicious Brotli-encoded response would be relevant only if it reaches this decoder. No exploit payload or malformed compressed input was used.

Simple code that reproduces your problem

Install the current stable releases in an isolated environment:

python -m pip install "yfinance==1.7.0" "curl_cffi==0.16.3"

The following Linux-wheel diagnostic makes no network requests and does not decompress attacker-controlled data:

import ctypes
from pathlib import Path

import curl_cffi
import yfinance as yf
from yfinance import _http

print("yfinance:", yf.__version__)
print("curl_cffi:", curl_cffi.__version__)
print("default backend:", _http.HAS_CURL_CFFI, _http.requests.__name__)

native = ctypes.CDLL(str(Path(curl_cffi.__file__).parent / "_wrapper.abi3.so"))
native.curl_version.argtypes = []
native.curl_version.restype = ctypes.c_char_p
print("native:", native.curl_version().decode())

native.BrotliDecoderErrorString.argtypes = [ctypes.c_int]
native.BrotliDecoderErrorString.restype = ctypes.c_char_p
# The official Brotli fix assigns FORMAT_BLOCK_SWITCH error code -17.
print("Brotli error -17:", native.BrotliDecoderErrorString(-17).decode())

The error-name probe is corroborating evidence, not by itself proof of exploitability or absence of a different vendor backport. Please confirm the embedded decoder's patch status with the upstream build maintainers.

Debug log with debug logging enabled

Observed diagnostic output:

yfinance: 1.7.0
curl_cffi: 0.16.3
default backend: True curl_cffi.requests
native: libcurl/8.21.0-IMPERSONATE BoringSSL zlib/1.3 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.7 nghttp2/1.63.0 ngtcp2/1.20.0 nghttp3/1.15.0
Brotli error -17: INVALID

A separate localhost-only check created a session with yfinance._http.new_session() and served a normal, valid Brotli-compressed ok response. The session sent Accept-Encoding: gzip, deflate, br, zstd and decoded it to ok. This confirms that normal response decompression is reachable through the current default backend; it does not demonstrate the CVE or any memory corruption.

For comparison, the fixed Node.js 22.23.4 binary exposes BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH = -17. Its embedded Brotli version string still says 1.1.0, so the version string alone is not being treated as conclusive evidence.

I also inspected the official PyPI Linux x86_64 wheel for curl_cffi 0.17.0b2 (without installing it into the application environment): it reports libcurl/8.23.0-IMPERSONATE ... brotli/1.2.0 ..., and the same error-name probe returns INVALID. A newer Python package version therefore should not automatically be assumed to contain the Brotli fix.

No Yahoo requests were necessary for these checks, so there is no Yahoo request/debug log or incorrect-market-data example to attach.

Bad data proof

Not applicable: this report concerns a publicly disclosed client dependency vulnerability, not incorrect Yahoo Finance data.

yfinance version

1.7.0 (latest stable release, verified against PyPI).

Python version

3.12.3.

Operating system

Ubuntu 24.04.2 LTS, x86_64.

Expected behavior / requested action

Could this project track the downstream impact of the disclosed CVE and coordinate with curl_cffi / curl-impersonate on a wheel containing Brotli 1.2.1 or an equivalent backport?

Until a fixed upstream build is available, please document a supported temporary mitigation for yfinance users, including any limitations of the explicit YF_DISABLE_CURL_CFFI=1 backend switch. That alternative needs its own dependency and data-availability checks; I am not claiming that merely changing Accept-Encoding makes an unpatched decoder safe.

Once an appropriate fixed dependency release exists, documenting or enforcing its minimum version would help users verify remediation. Upgrading yfinance alone currently leaves curl_cffi>=0.15 satisfied by the affected stable wheel.

Additional dependency information and references

Before filing, I searched both open and closed yfinance issues for CVE-2026-111497, 111497, brotli, Brotli decoder, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, and related dependency-security wording. I found no matching report. Issue #2737 concerns the different advisory GHSA-qw2m-4pqf-rmpp and an older curl_cffi version cap; this report is about the newly disclosed Brotli decoder issue.

Activity

  1. ValueRaider commented on Oct 23, 2026

    @ValueRaider
    Collaborator

    Disabling curl_cffi entirely is not feasible. Can we disable Brotli compression?

  2. hearkenmx commented on Oct 23, 2026

    @hearkenmx
    Author

    Yes, keeping curl_cffi and disabling Brotli sounds reasonable as a temporary mitigation.

    I ran a localhost test with curl_cffi 0.15.0 using a valid Brotli response. Even when the actual request advertised only gzip, deflate, the client still automatically decoded a br response. Setting HTTP_CONTENT_DECODING=0 left the compressed bytes untouched. So removing br from Accept-Encoding alone would not block this decoding path.

    Would requesting Accept-Encoding: identity together with HTTP_CONTENT_DECODING=0, and failing explicitly on unexpected compressed responses, be a workable short-term approach? This disables automatic decompression for all content encodings, so Yahoo compatibility would need checking. I haven't tested that or repeated the test on 0.16.3.

    For the permanent fix, I’d suggest tracking an upstream native build containing Brotli 1.2.1 or an equivalent verified backport, then documenting or requiring the minimum fixed dependency version.

  3. hearkenmx commented on Oct 23, 2026

    @hearkenmx
    Author

    I've opened curl_cffi #895 to track wheels incorporating the upstream Brotli fix.

    The maintainer replied that they hope to release 0.17.0 this weekend with updated Brotli.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions