CVE-2026-33040
Integer Overflow in libp2p-rust Gossipsub Causes Remote Crash
Publication date: 2026-03-20
Last updated on: 2026-05-01
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| protocol | libp2p-gossipsub | to 0.49.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-190 | The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-33040 is a vulnerability in the Rust implementation of libp2p's Gossipsub protocol, affecting versions prior to 0.49.3. The issue occurs because the Gossipsub implementation accepts attacker-controlled PRUNE backoff values without proper validation. An attacker can send a specially crafted PRUNE control message containing an extremely large backoff value (such as the maximum 64-bit unsigned integer). This causes an overflow during time arithmetic operations when the system tries to update the backoff state, leading to a panic in the networking state machine."}, {'type': 'paragraph', 'content': 'This panic results in a crash of the target node running the vulnerable libp2p Gossipsub listener. The attack is remotely exploitable over a normal libp2p connection, requires no authentication or user interaction, and can be repeated by reconnecting and resending the malicious message.'}] [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or panics in applications using libp2p-rust Gossipsub prior to version 0.49.3, especially those exposing a Gossipsub listener. Detection involves observing if the networking state machine panics due to overflow in backoff time arithmetic triggered by receiving PRUNE control messages with unusually large backoff values.
To detect exploitation attempts on your network, you can capture and analyze libp2p traffic streams for ControlPrune messages containing abnormally large backoff values (e.g., near u64::MAX).
Suggested commands include using packet capture tools like tcpdump or Wireshark to filter libp2p traffic on the relevant ports, then inspecting protobuf RPC messages for ControlPrune messages with suspicious backoff values.
- tcpdump -i <interface> port <libp2p-port> -w capture.pcap
- Use Wireshark or a protobuf decoder to analyze capture.pcap for ControlPrune messages with extremely large backoff values.
What immediate steps should I take to mitigate this vulnerability?
The primary and immediate mitigation step is to upgrade libp2p-rust to version 0.49.3 or later, where the backoff handling logic has been fixed to prevent overflow and panic conditions.
Until the upgrade can be applied, consider restricting network access to the libp2p Gossipsub listener port to trusted sources only, to reduce exposure to remote attackers.
Additionally, monitor application logs and network traffic for signs of exploitation attempts and be prepared to restart affected services if a crash occurs.
How can this vulnerability impact me? :
This vulnerability can lead to a remote denial of service (DoS) attack against any application exposing a vulnerable libp2p Gossipsub listener. An attacker can crash the application by sending a single specially crafted PRUNE control message with an oversized backoff value.
Because the attack requires no authentication and can be performed remotely over a normal libp2p connection, it poses a significant risk to availability of services relying on libp2p Gossipsub. The attacker can repeatedly crash the service by reconnecting and resending the malicious message, potentially causing persistent downtime.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know