Alleysira

**Name of the Vulnerable Software and Affected Versions** @libp2p/gossipsub versions 15.0.0 through 16.0.4 **Description** In the default `StrictSign` policy, the `validateToRawMessage()` function in `packages/gossipsub/src/utils/buildRawMessage.ts` fails to bind the supplied public key in `msg.key` to the claimed author in `msg.from` when the author is an RSA peer ID that does not inline its public key. An unauthenticated attacker can spoof a victim's RSA peer ID by placing it in `msg.from`, signing the message with their own private key, and providing their own public key in `msg.key`. This allows the message to be accepted and propagated as if it were authored by the victim. Applications relying on `message.from` for authorization, accounting, moderation, reputation, or audit logging may process attacker-controlled data under false origin attribution. **Recommendations** Update @libp2p/gossipsub to version 16.0.5.

**Name of the Vulnerable Software and Affected Versions** @libp2p/peer-store versions 8.0.0 through 12.0.23 **Description** In the `@libp2p/peer-store` component, the `consumePeerRecord()` function verifies a `RecordEnvelope` signature but fails to ensure that the `PeerRecord.peerId` within the signed payload matches the signer peer ID derived by `RecordEnvelope.openAndCertify()`. Because the `expectedPeer` option only validates the envelope signer, an attacker can sign a record with their own key while including a victim's peer ID and attacker-controlled multiaddrs in the payload. This allows an attacker to store certified addresses for a victim peer, leading to address-book corruption, routing manipulation, reachability disruption, or dial redirection and failure. However, this does not allow a full identity takeover as the connection upgrade process still verifies the remote peer identity. **Recommendations** Update @libp2p/peer-store to version 12.0.24.