An attacker can generate a signed PeerRecord using their own private key but specify the PeerId of a victim in the payload. When processed by a vulnerable node, the library treats the payload as authentic because the envelope signature is technically valid (signed by the attacker). Consequently, the node stores attacker-controlled multiaddrs as 'certified' addresses for the victim peer. Since libp2p connection logic prioritizes certified addresses during dialing, this vulnerability allows for address-book poisoning, dial redirection, and reachability disruption. This affects @libp2p/peer-store versions 8.0.0 through 12.0.23.

Attack Chain

1. Attacker generates a legitimate libp2p cryptographic key pair.
2. Attacker crafts a PeerRecord object containing the victim's PeerId and the attacker's own malicious multiaddrs.
3. Attacker signs this PeerRecord using their own private key, creating a valid RecordEnvelope.
4. Attacker transmits the forged envelope to a target node, typically through peer discovery protocols like GossipSub Peer Exchange (PX).
5. The target node's consumePeerRecord function extracts the PeerId from the envelope signature and validates the signature successfully.
6. The target node fails to compare the signer's identity against the PeerRecord.peerId field in the payload.
7. The target node's peerStore.patch method commits the forged addresses to its local datastore, marking them as isCertified: true under the victim's identity.
8. Future connection attempts by the target node to the victim peer are redirected to the attacker's infrastructure or result in connection failure.

Impact

Successful exploitation results in the poisoning of the target's peer-store cache. Because certified addresses are highly prioritized by libp2p connection logic, legitimate traffic intended for the victim peer is redirected to attacker-controlled endpoints. This can disrupt network connectivity, prevent legitimate peer communication, and facilitate further reconnaissance or man-in-the-middle attacks on the application layer. Thousands of decentralized applications and infrastructure nodes relying on libp2p for peer-to-peer networking are potentially affected.

Recommendation

Prioritized, concrete actions for engineering and security teams:

• Upgrade @libp2p/peer-store to version 12.0.24 or later to implement the required PeerId/signer identity invariant.
• Audit existing PeerStore datastores for unexpected or unauthorized certified addresses associated with high-value peer IDs if the node has been exposed to untrusted peer records.
• Implement strict peer-to-peer connection validation logic to ensure that connection upgrades and identity handshakes are not solely reliant on certified peer records stored in the local cache.