web3.py CVE-2026-111171

Exploitation requires ALL of: (1) a web3.py version in the affected range with CCIP Read enabled - this is ON by default (global_ccip_read_enabled=True), so no opt-in is needed; (2) the application performing .call()/eth_call against an attacker-controlled or otherwise untrusted ERC-3668/OffchainLookup contract address; and (3) the attacker returning an OffchainLookup URL whose host is an IPv4-mapped IPv6 address (e.g. ::ffff:127.0.0.1, ::ffff:169.254.169.254) or an AAAA record, which _check_ip_blocked() fails to unwrap and therefore does not match against loopback/RFC1918/link-local blocklists. LIMITING FACTORS: per CVSS AC:H/AT:P, the attacker must specifically craft the mapped-address bypass, and the deployment must query untrusted contracts (pure read-only use against trusted contracts is not exposed); impact is partial (information disclosure / internal request forgery, VC:L/VI:L), not full host compromise. Primarily a server-side (backend, indexer, bot, API) risk - not a concern for isolated client wallets querying only trusted contracts.

This is a genuine but moderate-priority issue, best characterized as a CVSS-medium flaw rather than an urgent emergency. The vendor-provided CVSS 4.0 vector (6.3, medium) rates it AV:N but with AC:H and AT:P, signaling that exploitation is network-reachable yet depends on specific, non-trivial attack requirements (crafting IPv4-mapped IPv6 / AAAA records to slip past _check_ip_blocked) and on the victim application calling untrusted contracts. CISA SSVC reinforces this: Exploitation=poc (proof-of-concept only, not active exploitation), Automatable=no (an attacker cannot trivially mass-scan and auto-exploit), and Technical Impact=partial - all consistent with the low VC:L/VI:L/VA:N impact metrics. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of widespread or active exploitation. The strongest aggravating signal is NOT in the raw score: the GHSA advisory states CCIP Read is enabled by default (global_ccip_read_enabled=True), so any backend/indexer/API using .call() against attacker-influenced contracts is silently exposed. Net: prioritize patching for server-side web3.py deployments that process untrusted contract addresses (classic SSRF-to-cloud-metadata risk), but this is not a drop-everything, auto-wormable critical.

A backend indexer or API uses web3.py's .call() against an attacker-controlled or user-supplied ERC-3668 contract with CCIP Read enabled (default). The malicious contract returns an OffchainLookup URL whose host resolves to an IPv4-mapped IPv6 address such as ::ffff:169.254.169.254, bypassing the private/reserved-range block so web3.py fetches the cloud metadata endpoint and leaks credentials. A proof-of-concept exists (SSVC Exploitation=poc), and the high attack complexity (AC:H/AT:P) means exploitation requires the crafted mapped-address trick plus a victim that queries untrusted contracts.