Two libp2p Spoofing Flaws Let Attackers Forge Peer Records and Gossipsub Messages

What happened

Two separate authentication-bypass issues were found in libp2p packages. In @libp2p/peer-store (CVE-2026-86039, GHSA-vrf4-mx87-p53w), the consumePeerRecord logic verifies the signature on a RecordEnvelope but does not require that the PeerRecord's peerId field matches the signer's peer ID. Combined with how the gossipsub Peer Exchange path supplies the 'expectedPeer' value, an attacker can sign a record with their own key while listing a victim's peer ID and attacker-controlled multiaddrs in the payload, causing PeerStore to store these as certified addresses for the victim. In @libp2p/gossipsub (CVE-2026-86038, GHSA-c3gv-825q-fvmp), the default StrictSign message-validation policy verifies a message signature against an attacker-supplied public key but does not bind that key to the claimed 'from' peer ID when that ID is an RSA peer ID without an inlined public key. This lets an attacker sign a message with their own key while claiming a victim's RSA peer ID as the author, causing the message to be accepted and propagated as if it came from the victim.

Technical cause

Both issues stem from incomplete binding between a cryptographic signer and the identity claimed in the signed payload (CWE-290, Authentication Bypass by Spoofing, for the peer-store issue; CWE-345, Insufficient Verification of Data Authenticity, for the gossipsub issue). In the peer-store case, the code in packages/peer-store/src/index.ts checks only that the envelope's signer matches the 'expectedPeer' option, not that the payload's own peerId field matches the signer. In the gossipsub case, the code in packages/gossipsub/src/utils/buildRawMessage.ts validates the signature against the supplied key but does not verify that this key actually corresponds to the RSA peer ID named in the message's 'from' field when no public key is inlined in that ID.

Why it matters

The peer-store flaw can cause address-book corruption, dial redirection or failure, routing manipulation, and reachability disruption for a victim peer, because other nodes may store and act on attacker-controlled addresses believing them to be certified for the victim. However, the libp2p connection upgrade process still independently verifies the remote peer's identity, so this does not by itself allow a full identity takeover. The gossipsub flaw allows false origin attribution: applications that rely on the message 'from' field for validators, authorization, accounting, moderation, reputation, or audit logging can be made to process attacker-controlled data as if it were submitted by a trusted victim peer.

Who is affected

Any application using @libp2p/peer-store versions from 8.0.0 up to (but not including) 12.0.24 is affected by CVE-2026-86039. Any application using @libp2p/gossipsub versions from 15.0.0 up to (but not including) 16.0.5 is affected by CVE-2026-86038. Both packages are part of the npm ecosystem used in JavaScript/Node.js libp2p deployments.

Affected versions

@libp2p/peer-store: versions >= 8.0.0 and < 12.0.24 are affected; fixed in 12.0.24. @libp2p/gossipsub: versions >= 15.0.0 and < 16.0.5 are affected; fixed in 16.0.5.

Fixes and mitigation

Both issues are resolved in updated package releases. @libp2p/peer-store is fixed in version 12.0.24. @libp2p/gossipsub is fixed in version 16.0.5. No workarounds beyond upgrading are described in the available advisories.

Recommended action

Upgrade @libp2p/peer-store to version 12.0.24 or later, and upgrade @libp2p/gossipsub to version 16.0.5 or later. Applications that make trust, authorization, moderation, or logging decisions based on gossipsub message origin ('from') or on stored peer addresses should review whether those decisions could be affected by forged data prior to applying the updates.