Repository navigation
Track CVE-2026-111497 in Brotli bundled with the default curl_cffi backend #3012
Description
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
- curl_cffi: 0.16.3 (latest stable); additional native-library inspection of the 0.17.0b2 Linux x86_64 wheel.
- Brotli 1.2.1 security release.
- Public Brotli decoder fix.
- Node.js October 2026 security advisory, including CVE-2026-111497.
- curl_cffi stable package.
- curl_cffi 0.17.0b2 release.
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
ValueRaider commentedon Oct 23, 2026
Disabling curl_cffi entirely is not feasible. Can we disable Brotli compression?
hearkenmx commentedon Oct 23, 2026
Yes, keeping
curl_cffiand disabling Brotli sounds reasonable as a temporary mitigation.I ran a localhost test with
curl_cffi 0.15.0using a valid Brotli response. Even when the actual request advertised onlygzip, deflate, the client still automatically decoded abrresponse. SettingHTTP_CONTENT_DECODING=0left the compressed bytes untouched. So removingbrfromAccept-Encodingalone would not block this decoding path.Would requesting
Accept-Encoding: identitytogether withHTTP_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 on0.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.
hearkenmx commentedon Oct 23, 2026
I've opened curl_cffi #895 to track wheels incorporating the upstream Brotli fix.
The maintainer replied that they hope to release
0.17.0this weekend with updated Brotli.