CVE-2026-86038 in libp2p
Summary
by MITRE • 09/17/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within libp2p versions 15.0.0 through 16.0.5 represents a critical authentication bypass rooted in the implementation of the gossipsub protocol's message validation logic. Specifically, the flaw resides in the buildRawMessage utility function located at packages/gossipsub/src/utils/buildRawMessage.ts. This component is responsible for verifying cryptographic signatures on incoming messages to ensure their integrity and authenticity before propagation across the peer-to-peer network. The core technical deficiency lies in how the system handles RSA-based peer identifiers that do not inline their public keys within the identifier itself. In such cases, the validation process verifies the signature against a provided public key but fails to cryptographically bind or verify that this claimed public key actually corresponds to the identity asserted in the message's from field. This separation of verification and binding creates an opening for spoofing attacks where the source attribution can be decoupled from the actual cryptographic proof.
An unauthenticated attacker can exploit this flaw by constructing a malicious message with several carefully chosen fields. The attacker sets the msg.from field to contain the victim peer ID, effectively claiming authorship on behalf of that entity. Simultaneously, the attacker signs the message content using their own private key and places their corresponding public key into the msg.key field. Because the validation logic checks if the signature matches the provided public key in msg.key but does not enforce a strict binding between that public key and the identity specified in msg.from for RSA peers without inline keys, the system accepts the message as valid. Consequently, the gossipsub network propagates this message across the mesh, leading other nodes to believe it originated from the victim peer ID rather than the attacker. This mechanism allows for precise impersonation within a decentralized network environment where trust is often derived directly from cryptographic identity proofs.
The operational impact of this vulnerability is severe, particularly for applications that rely on the msg.from field as a primary source of truth for security and governance decisions. Many distributed systems utilize message originators to enforce access control policies, track reputation scores, manage accounting records, or perform audit logging. By successfully spoofing another peer's identity, an attacker can inject malicious data into the network while evading attribution mechanisms designed to hold specific peers accountable. This undermines trust models that depend on accurate provenance of information. For instance, if a system grants privileges based on messages from trusted validators, an attacker could impersonate one of these validators to push unauthorized updates or false consensus states. Similarly, in reputation systems, the attacker could manipulate metrics by appearing as a highly-rated peer performing legitimate actions, thereby distorting network health assessments and potentially influencing routing decisions that depend on trust scores.
To mitigate this risk, users must upgrade immediately to version 16.0.5 of libp2p, which addresses the validation logic flaw by ensuring proper binding between the claimed author identity and the cryptographic key used for signature verification. This fix enforces strict adherence to authentication policies even when public keys are not inlined within peer IDs. From a broader security architecture perspective, this vulnerability aligns with CWE-345 Insufficient Verification of Data Authenticity, as the system failed to verify that the claimed identity matched the cryptographic proof provided. Furthermore, it relates to ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials or identities to bypass authentication controls and gain unauthorized access or influence within a network environment. Organizations deploying libp2p-based applications should also consider implementing additional layers of validation at the application layer, such as cross-referencing peer IDs with known public key registries or requiring explicit proof-of-possession for critical operations, thereby reducing reliance on single-point authentication mechanisms that may be susceptible to implementation flaws in underlying networking libraries.