CVE-2026-86039

### Summary `@libp2p/peer-store` accepts a signed `PeerRecord` whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable `consumePeerRecord` path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped `PeerRecord.peerId`. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim. ### Details The vulnerable code is in `packages/peer-store/src/index.ts`: - `RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options)` verifies the envelope signature. - `const peerId = peerIdFromCID(envelope.publicKey.toCID())` derives the envelope signer peer ID. - The optional `expectedPeer` check only compares `expectedPeer` to the envelope signer. - `const peerRecord = PeerRecord.createFromProtobuf(envelope.payload)` decodes `peerRecord.peerId` from attacker-controlled signed payload bytes. - `this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true })` stores the addresses under the payload peer ID, not the verified signer peer ID. The missing invariant is: ```ts peerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID())) ``` `packages/protocol-identify/src/utils.ts` already performs this check and can be used as the reference behavior: ```ts if (!peerRecord.peerId.equals(envelopePeer)) { throw new InvalidMessageError('signing key does not match PeerId in the PeerRecord') } ``` The gossipsub Peer Exchange path reaches this code via `packages/gossipsub/src/gossipsub.ts` by calling: ```ts peerStore.consumePeerRecord(pi.signedPeerRecord, { expectedPeer: peer }) ``` This does not prevent the bug because `peer` is derived from the wire `pi.peerID`. An attacker can set `pi.peerID` to their own peer ID, sign the envelope with their own key, and put the victim peer ID inside the wrapped `PeerRecord`. ##