libp2p gossipsub EUVD-2026-81685

Exploitation requires the target deployment to run @libp2p/gossipsub 15.0.0 through before 16.0.5 under the default StrictSign message signing policy, and - critically - the impersonated victim must use an RSA peer ID that does NOT inline its public key, because the flaw is that validateToRawMessage verifies the attacker-supplied msg.key signature but skips binding that key to msg.from only in this RSA-without-inlined-key path. Ed25519/secp256k1 peer IDs (which embed the key in the multihash) are not spoofable this way, which limits the victim set. Impact only materializes for applications that make trust decisions on message.from (validators, authorization, accounting, moderation, reputation, or audit logging); deployments that ignore claimed origin are unaffected. No authentication and no user interaction are needed (PR:N/UI:N), and the attacker only needs network reachability into the gossipsub mesh.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, base 7.5) is internally consistent with the description: an unauthenticated network attacker can forge message authorship with no user interaction, yielding a pure integrity impact (I:H) and no confidentiality or availability loss - so the input Tag 'Information Disclosure' is misaligned with the actual C:N/I:H impact profile. No EPSS score, CISA KEV entry, or standalone POC is present in the input, so exploitation status is 'no public exploit identified at time of analysis'; however, the fixing PR #3569 ships a unit test that concretely demonstrates the forgery (claiming a victim RSA peer ID while signing with an attacker Ed25519 key), which is effectively a working proof-of-concept of the flaw's mechanics even if not packaged as a weapon. Real-world risk is moderate and highly context-dependent: the flaw only matters for applications that trust message.from for validation, authorization, accounting, moderation, reputation, or audit logging AND where the impersonated peer uses an RSA peer ID that does not inline its public key. Absent KEV/EPSS signals this is a spoofing/authenticity-verification weakness to patch on a normal cadence rather than an emergency, but the network-reachable, unauthenticated, low-complexity nature warrants prompt upgrade for any deployment building trust decisions on gossipsub message origin.

An attacker joins a gossipsub mesh and publishes a StrictSign message placing a victim's RSA peer ID in msg.from, signing with the attacker's own private key and supplying the attacker's public key in msg.key; because validateToRawMessage never binds that key back to the claimed RSA author, the message is accepted and propagated as authored by the victim. Downstream applications that authorize, moderate, or audit based on message.from then process attacker-controlled content under the victim's identity. The fixing PR #3569 includes a test that reproduces the forgery, effectively serving as a proof-of-concept.