Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
@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: For RSA peer IDs parsed from the wire from multihash, fromPeerId.publicKey is undefined because the RSA public key is not inlined in the peer ID. This means the key-to-from comparison is skipped. The code then verifies the signature with the attacker-supplied msg.key and returns a signed message whose from is the victim RSA peer ID. The missing invariant is: This check must be performed whenever a public key is supplied, including keyless peer…
Recommended action: Upgrade to 16.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 is no equivalent counter at all, so a single peer continuously streaming 4MB frames can hold the event loop above 80% utilisation indefinitely. Details No decode-time cap on message ID count (message/decodeRpc.ts:11-19) These are the defaults unless the operator explicitly overrides opts.decodeRpcLimits. A TODO at gossipsub.ts:857 already notes the gap: // TODO: Check max gossip message size, before…
Recommended action: Upgrade to 16.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 peer disconnect, empty Sets are never deleted from this.topics thus memory is non-reclaimable within the process lifetime. A single 4MB LP frame carries 349,525 unique topic SUBSCRIBE entries. Each frame causes ~89MB of heap growth (~22x amplification). A Node.js process with a 1.5GB heap limit crashes after ~17 such frames (~68MB total attacker bandwidth, achievable in ~5 seconds at 100Mbps). Details Defect 1:…
Recommended action: Upgrade to 15.0.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.