Go to packages list

libp2p-gossipsub

Ecosystem: npm

Downloads:

Vulnerabilities from the last (months)
  • 0CriticalAffects 0 versions
  • 3HighAffects 3 versions
  • 0MediumAffects 0 versions
  • 0ModerateAffects 0 versions
  • 0LowAffects 0 versions
Severity distribution (all time)
3vulnerabilities
  • Critical0 (0.0%)
  • High3 (100.0%)
  • Medium0 (0.0%)
  • Moderate0 (0.0%)
  • Low0 (0.0%)

Monthly breakdown

  • Critical
  • High
  • Medium
  • Moderate
  • Low
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0

Vulnerabilities (3)

Known vulnerabilities affecting libp2p-gossipsub, based on data from OSV.

Vulnerabilities affecting libp2p-gossipsub
IDSeveritySummaryAffected versionsPublishedSource
GHSA-c3gv-825q-fvmpHighlibp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID### Summary `@libp2p/gossipsub` `StrictSign` validation does not bind a supplied message public key to the claimed `from` peer ID when `from` is an RSA-style peer ID that does not inline its public key. An attacker can set `from` to a victim RSA peer ID, sign the message with the attacker's own private key, include the attacker's public key in `msg.key`, and have the message accepted as a valid signed message from the victim. ### Details The vulnerable code is in `packages/gossipsub/src/utils/buildRawMessage.ts` inside `validateToRawMessage`. When `msg.key` is present: ```ts publicKey = pub
  • >= 15.0.0, < 16.0.5
GitHub (opens in a new tab)
GHSA-cwc9-cp4j-mcvvHighlibp2p: CPU DoS via oversized IHAVE and IWANT control message arrays### Summary gossipsub processes IHAVE and IWANT control messages by iterating every received message ID synchronously before doing anything with the results. There is no cap on how many IDs a single frame may contain. The default LP frame limit is 4MB, which fits roughly 180,000 message IDs. Iterating that many IDs blocks the Node.js event loop for around 200ms per call. The two variants have different severity. For IHAVE there is a per-peer per-heartbeat counter that limits each peer to one full iteration per heartbeat, so causing a total stall requires around 10 Sybil peers. For IWANT there
  • < 16.0.0
GitHub (opens in a new tab)
GHSA-4f8r-922h-2vgvHighjs-libp2p: Memory DoS via subscription flood of unique topics### Summary Three cooperating omissions in `@libp2p/gossipsub` allow an unauthenticated single peer to exhaust the Node.js heap of any gossipsub node with default options. 1. **`defaultDecodeRpcLimits.maxSubscriptions = Infinity`** (`packages/gossipsub/src/message/decodeRpc.ts:11`): no decode-level cap on subscription entries per RPC. 2. **`handleReceivedSubscription` is unbounded** (`gossipsub.ts:1009-1021`): every unique topic string creates a new `Map` entry + `Set` object in `this.topics` with no per-peer count limit. 3. **`removePeer` leaves empty Sets** (`gossipsub.ts:782-784`): after p
  • < 15.0.23
GitHub (opens in a new tab)
  • GHSA-c3gv-825q-fvmpHigh
    libp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID
    • >= 15.0.0, < 16.0.5
    GitHub (opens in a new tab)

    ### Summary `@libp2p/gossipsub` `StrictSign` validation does not bind a supplied message public key to the claimed `from` peer ID when `from` is an RSA-style peer ID that does not inline its public key. An attacker can set `from` to a victim RSA peer ID, sign the message with the attacker's own private key, include the attacker's public key in `msg.key`, and have the message accepted as a valid signed message from the victim. ### Details The vulnerable code is in `packages/gossipsub/src/utils/buildRawMessage.ts` inside `validateToRawMessage`. When `msg.key` is present: ```ts publicKey = pub

    CVE: CVE-2026-86038

  • GHSA-cwc9-cp4j-mcvvHigh
    libp2p: CPU DoS via oversized IHAVE and IWANT control message arrays
    • < 16.0.0
    GitHub (opens in a new tab)

    ### Summary gossipsub processes IHAVE and IWANT control messages by iterating every received message ID synchronously before doing anything with the results. There is no cap on how many IDs a single frame may contain. The default LP frame limit is 4MB, which fits roughly 180,000 message IDs. Iterating that many IDs blocks the Node.js event loop for around 200ms per call. The two variants have different severity. For IHAVE there is a per-peer per-heartbeat counter that limits each peer to one full iteration per heartbeat, so causing a total stall requires around 10 Sybil peers. For IWANT there

    CVE: CVE-2026-49866

  • GHSA-4f8r-922h-2vgvHigh
    js-libp2p: Memory DoS via subscription flood of unique topics
    • < 15.0.23
    GitHub (opens in a new tab)

    ### Summary Three cooperating omissions in `@libp2p/gossipsub` allow an unauthenticated single peer to exhaust the Node.js heap of any gossipsub node with default options. 1. **`defaultDecodeRpcLimits.maxSubscriptions = Infinity`** (`packages/gossipsub/src/message/decodeRpc.ts:11`): no decode-level cap on subscription entries per RPC. 2. **`handleReceivedSubscription` is unbounded** (`gossipsub.ts:1009-1021`): every unique topic string creates a new `Map` entry + `Set` object in `this.topics` with no per-peer count limit. 3. **`removePeer` leaves empty Sets** (`gossipsub.ts:782-784`): after p

    CVE: CVE-2026-46679

Showing 1-3 of 3 vulnerabilities