Skip to main content
VulnerabilityPublished Updated

CVE-2026-86039: js-libp2p · Authentication Bypass by Spoofing

Affects js-libp2pSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 8.2 High : upgrade to 12.0.24 soon.

Data as of 1 Nov 2026, 11:03 UTC

CVSS 3.1 base score
8.2High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 19% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 12.0.24
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 17 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 1 Nov 2026.

What to do

Upgrade js-libp2p and @libp2p/peer-store to 12.0.24.

Affected software

ProductAffectedFixed in
libp2pjs-libp2pAffected
  • >=8.0.0 <12.0.24
Fixed in
  • 12.0.24
npm@libp2p/peer-storepkg:npm/@libp2p/peer-storeOther threatsAffected
  • >=8.0.0 <12.0.24
Fixed in
  • 12.0.24

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix is available in version 12.0.24 of js-libp2p. Users should upgrade to version 12.0.24 or later to remediate this vulnerability. No additional mitigation steps are indicated by the vendor advisory.

Description

libp2p is a JavaScript implementation of the libp2p networking stack. From 8.0.0 until 12.0.24, @libp2p/peer-store in packages/peer-store/src/index.ts uses consumePeerRecord to verify a RecordEnvelope signature but does not require PeerRecord.peerId in the signed payload to equal the signer peer ID derived by RecordEnvelope.openAndCertify. The expectedPeer option checks only the envelope signer, and the gossipsub Peer Exchange path can provide the attacker's own peer ID as expectedPeer. An attacker can therefore sign a record with the attacker's key, place a victim peer ID and attacker-controlled multiaddrs in the payload, and have certified addresses stored for the victim. The poisoned addresses can cause address-book corruption, dial redirection or failure, routing manipulation, and reachability disruption, although the connection upgrade still verifies remote peer identity and prevents a complete identity takeover. The issue is fixed in version 12.0.24.

References

Community reviews

Loading reviews…