CVE-2026-40072: 
Python vulnerability analysis and mitigation

CVE-2026-40072 is a Server-Side Request Forgery (SSRF) vulnerability in the web3.py Python library affecting its CCIP Read / OffchainLookup (EIP-3668) implementation. It affects versions from 6.0.0b3 up to (but not including) 7.15.0, and version 8.0.0b1. The flaw allows a malicious smart contract to force the web3.py process to issue HTTP requests to arbitrary destinations — including internal network services and cloud metadata endpoints — without any destination validation. It was published on April 9, 2026, and carries a CVSS v3.1 base score of 7.2 (High) (GitHub Advisory).

The root cause (CWE-918) lies in web3.py's CCIP Read handlers (web3/utils/exception_handling.py and web3/utils/async_exception_handling.py), which iterate over URLs supplied by smart contracts in offchain_lookup_payload["urls"] and issue HTTP GET or POST requests after simple {sender}/{data} template substitution — with no scheme restriction, no hostname/IP allowlist, no blocking of private/reserved IP ranges, and no redirect validation (allow_redirects=True by default for both requests and aiohttp). CCIP Read is enabled globally by default (global_ccip_read_enabled = True) on all providers, so any application invoking .call() against an untrusted or user-supplied contract address is automatically exposed. An attacker deploys a malicious contract that reverts with an OffchainLookup error containing attacker-controlled URLs; web3.py's .call() method then automatically invokes the CCIP handler up to ccip_read_max_redirects times (default: 4) without any user interaction. A full reproduction script (repro_ssrf.py) is included in the official advisory (GitHub Advisory, Patch Commit).

Successful exploitation enables blind SSRF from the web3.py process's network context, allowing an attacker to probe internal network topology, reach cloud metadata endpoints (e.g., AWS IMDSv1 at http://169.254.169.254/latest/meta-data/iam/security-credentials/), and trigger state-changing operations on internal APIs via POST requests with attacker-influenced JSON bodies. While the CCIP handler expects a JSON "data" field in the response (limiting direct data exfiltration in most cases), the outbound request itself constitutes the primary threat — enabling network reconnaissance, side-effect triggering on unauthenticated internal services, and potential credential exposure on cloud platforms using IMDSv1. The vulnerability has no impact on confidentiality or integrity of the vulnerable system itself (CVSS scores reflect low sub-system impact), but the changed scope means downstream internal systems are at risk (GitHub Advisory).

A proof-of-concept reproduction script (repro_ssrf.py) is publicly available in the official GitHub Security Advisory and requires no network access or blockchain connection — it calls the vulnerable handler function directly (GitHub Advisory). A community-created SSRF lab repository (github.com/u1tr0nex/cve-2026-40072-ssrf-lab) and listings on Sploitus and Vulners further lower the barrier to exploitation. The EPSS score is approximately 0.041% (0.000410), and there is no current evidence of in-the-wild exploitation or CISA KEV catalog inclusion. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify backend services, indexers, APIs, or bots that use web3.py versions >=6.0.0b3 and <7.15.0 (or 8.0.0b1) and call .call() or eth_call against user-supplied or untrusted contract addresses.
2. Deploy malicious contract: Deploy a smart contract on a network accessible to the target that, when called, reverts with an OffchainLookup error (EIP-3668) containing attacker-controlled URLs in the urls field — e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/ or an internal service address.
3. Trigger the call: Cause the target backend to invoke .call() against the malicious contract address (e.g., by submitting the contract address through a user-facing API, or by listing it in a dataset the indexer processes).
4. SSRF fires automatically: web3.py's CCIP Read handler intercepts the OffchainLookup revert and issues an HTTP GET or POST request to the attacker-supplied URL from the backend's network context, with no destination validation.
5. Exploit redirect amplification (optional): Point the initial URL to an attacker-controlled server that issues a 302 redirect to an internal target (e.g., http://10.0.0.1/admin), bypassing any naive URL-prefix checks, since allow_redirects=True by default.
6. Collect results: Monitor the attacker-controlled server for inbound requests (confirming network reachability and internal topology), or — if an internal endpoint returns JSON with a "data" field — observe the on-chain callback for exfiltrated data (GitHub Advisory).

• Network: Unexpected outbound HTTP/HTTPS requests from backend application servers to cloud metadata endpoints (e.g., 169.254.169.254), loopback addresses (127.0.0.1, localhost), or RFC1918 ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x); outbound requests to unknown external hosts originating from the web3.py process.
• Logs: Application logs showing Web3ValidationError or MultipleFailedRequests exceptions related to CCIP Read / OffchainLookup handling; HTTP access logs on internal services showing unexpected GET/POST requests with query parameters containing Ethereum addresses or hex-encoded data (e.g., ?sender=0x...&data=0x...).
• Process: The Python process running web3.py initiating unexpected outbound TCP connections on ports 80 or 443 to internal or metadata IP ranges.
• File System: Presence of repro_ssrf.py or similar SSRF test scripts in application directories (GitHub Advisory).

Upgrade web3.py to version 7.15.0 or 8.0.0b2 (or later), which introduce HTTPS-only enforcement by default, private/reserved IP blocking via hostname resolution, allow_redirects=False on all CCIP requests, and an optional custom URL validator hook (Patch Commit). For applications that cannot upgrade immediately, disable CCIP Read entirely by setting global_ccip_read_enabled = False on the provider, or pass ccip_read_enabled=False per .call() invocation if CCIP Read is not required. If HTTP URLs are needed after upgrading, opt in explicitly via provider.ccip_read_allow_http = True, and consider supplying a custom ccip_read_url_validator callback to enforce an allowlist of trusted CCIP gateway hostnames (GitHub Advisory).

The vulnerability was reported by researcher Nadav0077 and published via GitHub Security Advisory GHSA-5hr4-253g-cpx2 by web3.py maintainer fselmo on April 2, 2026 (GitHub Advisory). A Medium article from GraySentinel AI provided a threat intelligence brief on the vulnerability, and community SSRF lab repositories appeared shortly after disclosure, indicating active interest from the security research community. No major vendor statements beyond the official advisory or significant mainstream media coverage have been identified.