CVE-2026-86038

### Summary `@libp2p/gossipsub` `StrictSign` validation does not bind a supplied message public key to the claimed `from` peer ID when `from` is an RSA-style peer ID that does not inline its public key. An attacker can set `from` to a victim RSA peer ID, sign the message with the attacker's own private key, include the attacker's public key in `msg.key`, and have the message accepted as a valid signed message from the victim. ### Details The vulnerable code is in `packages/gossipsub/src/utils/buildRawMessage.ts` inside `validateToRawMessage`. When `msg.key` is present: ```ts publicKey = publicKeyFromProtobuf(msg.key) if (fromPeerId.publicKey !== undefined && !publicKey.equals(fromPeerId.publicKey)) { return { valid: false, error: ValidateError.InvalidPeerId } } ``` For RSA peer IDs parsed from the wire `from` multihash, `fromPeerId.publicKey` is undefined because the RSA public key is not inlined in the peer ID. This means the key-to-`from` comparison is skipped. The code then verifies the signature with the attacker-supplied `msg.key` and returns a signed message whose `from` is the victim RSA peer ID. The missing invariant is: ```ts peerIdFromPublicKey(publicKey).equals(fromPeerId) ``` This check must be performed whenever a public key is supplied, including keyless peer ID representations such as RSA peer IDs. `StrictSign` is the default gossipsub signature policy in `packages/gossipsub/src/gossipsub.ts`: ```ts this.globalSignaturePolicy = opts.globalSignaturePolicy ?? StrictSign ``` Version tracing: - `git blame` points the vulnerable `validateToRawMessage` block to `9a9b11fd44` (`fix!: remove pubsub (#3291)`), which introduced `packages/gossipsub/src/utils/buildRawMessage.ts`. - That commit's `packages/gossipsub/package.json` still reports `14.1.1`, but the first `gossipsub-v*` release tag in this checkout that contains the vulnerable block is `gossipsub-v15.0.0`. ### PoC ```ts // TypeScript ESM PoC. import { strict as assert } from 'node:assert