Description

libp2p is a JavaScript implementation of the libp2p networking stack. From 15.0.0 until 16.0.5, @libp2p/gossipsub uses the default StrictSign policy in packages/gossipsub/src/utils/buildRawMessage.ts, where validateToRawMessage verifies a signature with attacker-controlled msg.key but skips binding that key to msg.from when the claimed author is an RSA peer ID that does not inline a public key. An unauthenticated attacker can place a victim RSA peer ID in msg.from, sign the message with the attacker's private key, and supply the attacker's public key in msg.key, causing the message to be accepted and propagated as authored by the victim. Applications that trust message.from for validators, authorization, accounting, moderation, reputation, or audit logging can process attacker-controlled data under false origin attribution. The issue is fixed in version 16.0.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-17T16:18:16.927Z",
  "pubdate": "2026-09-17T16:18:16.927Z",
  "executiveSummary": "This vulnerability is an identity spoofing flaw within the @libp2p/gossipsub package, affecting versions 15.0.0 through 16.0.5.\nThe issue stems from improper cryptographic verification of message signatures, specifically concerning RSA-based peer identities.\nAn unauthenticated attacker can forge messages that appear to originate from a victim's RSA peer ID, despite lacking the victim's private key.\nThe impact is significant for applications relying on the msg.from field for security-sensitive logic, including access control, reputation systems, moderation, and auditing.\nBy manipulating the msg.key and msg.from fields, an attacker can bypass origin authentication mechanisms, leading to unauthorized actions or data corruption.\nExploitation requires the attacker to craft a message containing a victim's RSA peer identifier while providing their own public key for signature verification, which the system erroneously accepts.",
  "technicalDetails": "The vulnerability resides in the validation logic within packages/gossipsub/src/utils/buildRawMessage.ts. The @libp2p/gossipsub implementation utilizes the StrictSign policy to verify the integrity and authenticity of gossip messages.\nThe root cause is a failure to cryptographically bind the message author's PeerID (msg.from) to the public key (msg.key) provided in the message envelope, specifically when the claimed author is an RSA-based PeerID that does not inline its public key within the ID itself.\nIn the affected versions, the validateToRawMessage function verifies the signature provided by the sender using the supplied msg.key. However, the system fails to enforce that the PeerID in msg.from matches the public key provided in msg.key for RSA identities.\nThe attack flow proceeds as follows: 1) The attacker selects a target victim RSA peer ID. 2) The attacker constructs a malicious Gossipsub message, setting the msg.from field to the victim's PeerID. 3) The attacker signs the message using their own private key. 4) The attacker includes their own public key in the msg.key field of the message. 5) Upon receiving the message, the validation logic in buildRawMessage.ts verifies the signature against the attacker's public key (msg.key), which evaluates to true. 6) Because the implementation fails to verify the relationship between the msg.from RSA identity and the provided msg.key, the message is accepted as valid and propagated through the network.\nThis allows the attacker to impersonate any RSA-based peer on the network. Any downstream application consuming the msg.from attribute—such as reputation or moderation services—will treat the malicious payload as originating from the victim.\nThe vulnerability is limited to PeerIDs using RSA keys that do not store public keys in-line. The issue was addressed by modifying the validation process to ensure proper binding between the claimed identity and the cryptographic key used for signature verification."
}