@libp2p/peer-store EUVD-2026-81686

Exploitable when the target runs @libp2p/peer-store from js-libp2p 8.0.0 up to (not including) 12.0.24 AND processes signed peer records through consumePeerRecord - specifically the gossipsub Peer Exchange path, which lets the attacker set its own peer ID as the expectedPeer option so only the envelope signer (not the payload PeerRecord.peerId) is validated. No authentication or user interaction is required (PR:N/UI:N): the attacker only needs to be a participating peer able to deliver a sealed RecordEnvelope. LIMITING FACTOR: the impact is capped - the connection upgrade still verifies the remote peer's real identity, so this yields address-book poisoning, dial redirection/failure, routing manipulation and reachability disruption, but not full identity takeover or traffic interception; deployments not using Peer Exchange / certified-address storage are less exposed.

The signals are mostly consistent and point to a genuine but bounded integrity risk. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L, base 8.2) is plausible: exploitation is network-reachable, low-complexity, requires no authentication (the attacker only needs to participate in the gossipsub Peer Exchange path and supply its own peer ID as expectedPeer), and needs no user interaction. Impact is correctly weighted toward integrity (I:H - certified address-book poisoning for arbitrary victim peer IDs) with a secondary availability effect (A:L - dial redirection/failure and reachability disruption); confidentiality is N because the description explicitly notes the connection upgrade still verifies remote peer identity, preventing a full identity/traffic takeover. So this is NOT a complete impersonation flaw. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - treat the 8.2 as a design-level integrity risk rather than evidence of mass exploitation. The fix (12.0.24) and root cause are strongly confirmed by the vendor advisory, PR #3570, and the added regression tests, which materially increases confidence in the technical assessment. Net: a real, patch-now issue for libp2p-based P2P networks, but not a confirmed-exploited emergency.

An attacker joins a libp2p network and, via the gossipsub Peer Exchange path, supplies its own peer ID as expectedPeer while sealing a RecordEnvelope with its own key whose PeerRecord payload names a victim peer ID and attacker-controlled multiaddrs. Because consumePeerRecord never checks that PeerRecord.peerId equals the envelope signer, the victim's certified addresses are overwritten, redirecting or breaking dials to that victim. No public POC was provided, but the added test cases in PR #3570 demonstrate the exact exploit primitive.