libp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID
Published Sep 17, 2026 · Updated Nov 3, 2026
Original summary
Normalized public record · Updated Nov 3, 2026
libp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID
Publisher and source text is retained separately from QFinch interpretation.
QFinch assessment
@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.
Potential impact
Attackers can forge gossipsub messages attributed to arbitrary victim RSA peer IDs under the default StrictSign policy. Applications that trust message.from in topic validators, authorization logic, accounting, moderation, reputation, or audit logs can be misled into treating attacker-controlled data as if it was authored by the victim. The forged message can also be considered valid by gossipsub's validation path and forwarded to peers, spreading the incorrect origin attribution through the pubsub mesh.
Technical context
The vulnerable code is in packages/gossipsub/src/utils/buildRawMessage.ts inside validateToRawMessage. When msg.key is present: 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: 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: 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.
Evidence: public source recordsAffected products
| Affected package, product or range | Fix status |
|---|---|
| Consult the referenced vendor advisory for affected versions. | Consult source advisory |
Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.
Remediation
Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.
- Confirm the affected product and reachable code path exist in your environment.
- Apply the vendor-supported patch or mitigation from the primary advisory.
- Rescan the exact deployed revision and retain verification evidence.
Evidence coverage
- SSVC priority
- MEDIUM
- Confidence
- Not available
- Aliases
- None reported
Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.
Sources and record history
Record history
Published Sep 17, 2026 · Last refreshed Nov 3, 2026