CVE-2026-111171 in Web3.py
Summary
by MITRE • 10/15/2026
Web3.py 7.15.0 through 7.16.0 and 8.0.0b2 through 8.0.0 contains a server-side request forgery vulnerability because _check_ip_blocked() does not unwrap IPv4-mapped IPv6 addresses in CCIP Read URL validation. Malicious contracts can return OffchainLookup URLs with IPv4-mapped IPv6 hosts or AAAA records, making clients with CCIP Read enabled send requests to loopback, private, or link-local services.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within Web3.py versions 7.15.0 through 7.16.0 and the beta release 8.0.0b2 through 8.0.0 represents a critical server-side request forgery flaw rooted in the improper handling of network address formats during CCIP Read URL validation. This specific weakness occurs within the _check_ip_blocked() function, which is responsible for validating IP addresses to prevent requests from being directed toward restricted or internal network ranges. The core technical failure lies in the library's inability to unwrap IPv4-mapped IPv6 addresses. In standard networking protocols, an IPv4 address can be represented as an IPv6 address using a specific mapping format, typically appearing as ::ffff:192.168.0.1 or similar variations. When malicious smart contracts return OffchainLookup URLs containing hosts formatted in this manner, the validation logic fails to recognize that these addresses are effectively standard IPv4 addresses destined for private or loopback networks. Consequently, the security filter is bypassed because it treats the mapped address as a distinct entity rather than resolving its underlying IPv4 nature.
This architectural oversight allows attackers to exploit CCIP Read enabled clients by crafting malicious contracts that return OffchainLookup URLs with hosts utilizing either IPv4-mapped IPv6 notation or AAAA records pointing to restricted ranges. The operational impact of this vulnerability is severe, as it enables the client application to send HTTP requests to loopback interfaces such as 127.0.0.1, private internal networks like 192.168.x.x, or link-local addresses. This capability effectively transforms the Web3.py client into a proxy for server-side request forgery attacks against services that are not intended to be accessible from external sources. An attacker can leverage this mechanism to probe internal network infrastructure, exfiltrate data from local APIs, or interact with backend services that rely on IP-based access controls rather than authentication mechanisms. The flaw undermines the security boundary between the blockchain interaction layer and the host machine's local environment, potentially leading to unauthorized access to sensitive resources residing within the same network segment as the vulnerable client.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically falling under subcategories related to bypassing filters via ambiguous or encoded inputs. The failure to normalize IP address representations before validation is a classic example of insufficient input sanitization that leads to security misconfiguration in network access controls. Furthermore, this attack vector maps directly to the ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where an attacker intercepts and potentially alters communication between two parties or services. In this context, the malicious contract acts as a trigger that forces the victim's application to initiate connections to internal targets, effectively using the client as a tool for lateral movement within the network topology. The lack of proper address unwrapping means that standard firewall rules or IP blacklists configured at the application level are rendered ineffective against these obfuscated requests.
To mitigate this vulnerability, developers and users must upgrade immediately to patched versions of Web3.py where the _check_ip_blocked() function has been updated to correctly unwrap IPv4-mapped IPv6 addresses before performing validation checks. It is essential that any IP address normalization logic resolves both standard IPv4 notation and its IPv6 mapped equivalents into a common format for consistent evaluation against blocklists. Additionally, security architectures should implement defense-in-depth strategies by ensuring that backend services do not rely solely on IP-based restrictions when exposed to untrusted inputs from blockchain interactions. Implementing strict allow-lists for outbound connections rather than relying exclusively on deny lists can further reduce the risk of SSRF exploitation. Regular auditing of smart contract integrations and validating all external URLs against a comprehensive set of normalized address formats are critical steps in maintaining the integrity of Web3 applications that utilize CCIP Read features.