Threat Intelligence Brief: CVE-2026-40072-SSRF Vulnerability in web3.py

Vulnerability: CVE-2026–40072 Affected Software: web3.py Severity: High (CVSS 3.1: 7.5) / Medium (CVSS 4.0: 6.9) Patched Versions: 7.15.0 and 8.0.0b2

Executive Summary

A recently disclosed vulnerability, CVE-2026–40072, affects web3.py, the most widely used Python library for interacting with Ethereum-based blockchain networks. The issue stems from the library’s implementation of EIP-3668 (CCIP Read), a feature designed to retrieve data from off-chain sources when that data is impractical to store directly on the blockchain.

The vulnerability allows attackers to exploit a weakness in how web3.py handles external URLs supplied by smart contracts. By crafting a malicious contract, an attacker can force a backend server using a vulnerable version of web3.py to make arbitrary HTTP requests. This creates a classic Server-Side Request Forgery (SSRF) condition.

Because CCIP Read is enabled by default, applications may be vulnerable without administrators realizing the feature is active. Successful exploitation could allow attackers to access cloud metadata services, probe internal networks, or interact with internal APIs that were never intended to be exposed externally.

Understanding the Vulnerability

What is CCIP Read?

EIP-3668, commonly known as CCIP Read, is a mechanism that enables smart contracts to retrieve data from external sources. When a smart contract encounters data that is stored off-chain, it can return an OffchainLookup response. The web3.py library then automatically contacts the specified external endpoint to obtain the required information.

This approach helps reduce on-chain storage costs while allowing applications to access larger datasets.

Where the Problem Occurs

The vulnerability exists because web3.py trusts the URLs provided by smart contracts and performs requests without adequately validating the destination.

In affected versions, the library:

• Accepts both HTTP and HTTPS destinations without restriction.
• Does not block requests to internal or sensitive IP addresses.
• Automatically follows HTTP redirects.
• Processes attacker-controlled URLs supplied through smart contract responses.

As a result, an attacker can create a malicious contract that instructs a vulnerable backend system to send requests to internal resources or cloud services.

Why It Is Dangerous

The most concerning aspect of this vulnerability is that CCIP Read is enabled by default. Any application that performs blockchain calls against an untrusted smart contract may unknowingly trigger outbound requests controlled by an attacker.

This significantly increases the attack surface for blockchain indexers, DeFi infrastructure, backend services, analytics platforms, and other applications that interact with public smart contracts.

Potential Attack Scenarios

1. Cloud Metadata Credential Theft

One of the most serious exploitation paths involves cloud metadata services.

An attacker can deploy a smart contract that points web3.py toward a metadata endpoint such as:

http://169.254.169.254

When a vulnerable application queries the contract, the backend server automatically contacts the metadata service.

In cloud environments such as AWS, this could expose temporary IAM credentials, potentially giving attackers access to cloud resources and sensitive data.

2. Internal Network Reconnaissance

The vulnerability can also be used for internal network scanning.

By supplying different internal IP addresses and ports, attackers can determine which systems are reachable from the vulnerable server. This enables reconnaissance activities that help identify:

• Internal web applications
• Databases
• Redis instances
• Jenkins servers
• Internal blockchain nodes
• Administrative interfaces

Such information can be leveraged in later stages of an attack.

3. Interaction with Internal APIs

Under specific conditions, web3.py may issue POST requests instead of GET requests.

This behavior can allow attackers to interact with internal APIs and services that were never intended to be publicly accessible. In poorly secured environments, this could result in unauthorized actions being performed through internal management interfaces or backend services.

Detection and Indicators of Compromise

Security teams should monitor outbound network activity from systems running web3.py and investigate unusual connections.

Suspicious Network Activity

Look for requests directed toward:

• Cloud metadata services such as 169.254.169.254
• Loopback addresses (127.0.0.1)
• Private network ranges:
• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• Unexpected high-numbered ports
• Internal services that normally should not receive requests from application servers

User-Agent Indicators

Logs containing the following User-Agent strings may indicate activity related to this vulnerability:

python-requests/…

aiohttp/…

Blockchain Activity Monitoring

Teams operating Ethereum infrastructure should monitor JSON-RPC requests involving:

• eth_call
• Contract .call() operations
• Recently deployed or unknown smart contracts

Correlating these events with outbound HTTP traffic may help identify exploitation attempts.

Affected Versions

Vulnerable Versions

• web3.py >= 6.0.0b3 and < 7.15.0
• web3.py >= 8.0.0b1 and < 8.0.0b2

Patched Versions

• web3.py 7.15.0
• web3.py 8.0.0b2

Mitigation and Remediation

Upgrade Immediately

Organizations should update to a patched version of web3.py as soon as possible.

Disable CCIP Read

If upgrading is not immediately feasible, CCIP Read can be disabled globally:

from web3 import Web3

Web3.global_ccip_read_enabled = False

Restrict Outbound Traffic

Implement network-level controls to prevent application servers from accessing internal networks and cloud metadata services.

Example:

sudo iptables -A OUTPUT -d 169.254.169.254 -j DROP

Additional firewall policies should block access to private address ranges wherever possible.

Follow the Principle of Least Privilege

Cloud workloads should use minimally privileged IAM roles and service accounts. This helps reduce the impact if metadata credentials are exposed.

Proof of Concept (PoC)

Step 1: Environment Setup

Install the vulnerable version of Web3.py:

pip install web3==7.14.0

The installation confirms that the vulnerable version of the library is being used for testing.

Step 2: Execute the Exploit

Create and run the following Python script:

from web3._utils.transaction_utils import handle_offchain_lookup

payload = {

“sender”: “0x1111111111111111111111111111111111111111”,

“callData”: “0x12345678”,

“urls”: [“http://127.0.0.1:48711/ssrf_triggered"]

}

handle_offchain_lookup(payload, {“to”: payload[“sender”]})

The payload contains a malicious URL pointing to a localhost address. When processed by the vulnerable function, Web3.py automatically performs an HTTP request to the supplied endpoint.

Step 3: Verify SSRF Execution

Upon execution, the application sends a request to the attacker-controlled URL without validating the destination.

The output demonstrates that Web3.py accessed the localhost address (127.0.0.1:48711), confirming the presence of a Server-Side Request Forgery (SSRF) vulnerability.

Root Cause

The vulnerability exists because:

• CCIP Read functionality is enabled by default.
• User-supplied URLs are not properly validated.
• Internal addresses such as localhost, 127.0.0.1, and cloud metadata endpoints can be accessed.
• Requests are automatically executed when interacting with malicious smart contracts.

Security Impact

An attacker can potentially abuse this behavior to access:

• Cloud metadata services
• Internal network resources
• Local APIs
• Backend management interfaces
• Internal databases and services

Remediation

Upgrade to the patched version of Web3.py:

Reference:

https://nvd.nist.gov/vuln/detail/CVE-2026-40072

GraySentinel gives you both: A portfolio that proves you can do the work + a certificate linked to your GitHub.

🔓 Free WhatsApp community: https://lnkd.in/dCmW77eM 🎯 Don’t delay. Start building proof today: https://lnkd.in/dXJQjxyh

👇 How much money have you spent on certifications that didn’t help you get a job?

CEH #CyberSecurity #Certification #GraySentinel #PortfolioOverCertificate #RedTeam #AppSec #EthicalHacking