CVE-2026-86039 in libp2p
Summary
by MITRE • 09/17/2026
libp2p is a JavaScript implementation of the libp2p networking stack. From 8.0.0 until 12.0.24, @libp2p/peer-store in packages/peer-store/src/index.ts uses consumePeerRecord to verify a RecordEnvelope signature but does not require PeerRecord.peerId in the signed payload to equal the signer peer ID derived by RecordEnvelope.openAndCertify. The expectedPeer option checks only the envelope signer, and the gossipsub Peer Exchange path can provide the attacker's own peer ID as expectedPeer. An attacker can therefore sign a record with the attacker's key, place a victim peer ID and attacker-controlled multiaddrs in the payload, and have certified addresses stored for the victim. The poisoned addresses can cause address-book corruption, dial redirection or failure, routing manipulation, and reachability disruption, although the connection upgrade still verifies remote peer identity and prevents a complete identity takeover. The issue is fixed in version 12.0.24.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the libp2p JavaScript implementation, specifically affecting versions from 8.0.0 through 12.0.23, represents a critical flaw in the peer store's handling of signed peer records. This issue stems from an insufficient validation mechanism during the verification process for RecordEnvelope signatures. When the system utilizes consumePeerRecord to validate a signature, it fails to enforce that the PeerId contained within the signed payload matches the signer identity derived by the openAndCertify method. Consequently, there is a disconnect between who signs the record and whose identity is being asserted in the data payload, creating an opportunity for malicious actors to manipulate peer routing information without possessing the private key of the target victim.
From a technical perspective, this flaw allows an attacker to craft a deceptive peer record by signing it with their own cryptographic keys while embedding a legitimate victim's PeerId and attacker-controlled multiaddrs into the signed payload. The existing security controls rely on the expectedPeer option, which verifies only that the envelope was signed by the specified signer. In scenarios involving gossipsub Peer Exchange paths, an attacker can supply their own peer ID as the expectedPeer parameter. This configuration bypasses the implicit expectation that the signed content must correspond to the signer's identity, thereby allowing the system to accept and store poisoned address data associated with a victim node under false pretenses.
The operational impact of this vulnerability is significant for network integrity and availability. By injecting fraudulent multiaddrs into the peer store, an attacker can cause severe address-book corruption for other nodes in the swarm. This manipulation facilitates dial redirection or connection failures as peers attempt to connect using invalid addresses. Furthermore, it enables routing table manipulation and reachability disruption, effectively degrading the performance and reliability of the decentralized network. Although the vulnerability does not allow a complete identity takeover because subsequent connection upgrade protocols still verify remote peer identities cryptographically, the ability to poison address books undermines trust in the discovery mechanism and can lead to persistent connectivity issues for targeted victims.
This flaw aligns with CWE-20 Improper Input Validation, as the system fails to properly validate that the signed payload attributes match the expected identity constraints before accepting them into storage. Additionally, it relates to CWE-345 Insufficient Verification of Data Authenticity within the context of peer-to-peer networking protocols where trust is established through cryptographic signatures. In terms of adversarial tactics, this vulnerability supports techniques associated with MITRE ATT&CK T1078 Valid Accounts or more broadly T1190 Exploit Public-Facing Application in distributed systems, as it involves abusing protocol logic to inject malicious state into the network topology without direct authentication bypasses at the transport layer.
To mitigate this risk, organizations and developers must upgrade immediately to version 12.0.24 of libp2p or later releases where the validation logic has been corrected to ensure that PeerRecord.peerId strictly equals the signer peer ID derived from the envelope signature. For systems unable to update promptly, implementing strict input filtering on gossipsub Peer Exchange inputs and ensuring that expectedPeer parameters are not arbitrarily set by untrusted sources can provide partial mitigation. Long-term resilience requires enforcing rigorous validation of all signed payloads against their cryptographic signers across all networking components in the stack.