<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T16:41:19.195623+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-86039</id>
    <title>fkie_cve-2026-86039</title>
    <updated>2026-09-29T16:41:21.968033+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-86039"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-vrf4-mx87-p53w</id>
    <title>GHSA-vrf4-mx87-p53w — libp2p: PeerStore accepts attacker-signed PeerRecords for a victim peer ID and stores certified attacker addresses</title>
    <updated>2026-09-29T16:41:21.968230+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @libp2p/peer-store</p>
<p>### Summary
`@libp2p/peer-store` accepts a signed `PeerRecord` whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable `consumePeerRecord` path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped `PeerRecord.peerId`. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim.</p>
<p>### Details
The vulnerable code is in `packages/peer-store/src/index.ts`:</p>
<p>- `RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options)` verifies the envelope signature.
- `const peerId = peerIdFromCID(envelope.publicKey.toCID())` derives the envelope signer peer ID.
- The optional `expectedPeer` check only compares `expectedPeer` to the envelope signer.
- `const peerRecord = PeerRecord.createFromProtobuf(envelope.payload)` decodes `peerRecord.peerId` from attacker-controlled signed payload bytes.
- `this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true })` stores the addresses under the payload peer ID, not the verified signer peer ID.</p>
<p>The missing invariant is:</p>
<p>```ts
peerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))
```</p>
<p>`packages/protocol-identify/src/utils.ts` already performs this check and can be used as the reference behavior:</p>
<p>```ts
if (!peerRecord.peerId.equals(envelopePeer)) {
  throw new InvalidMe…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-vrf4-mx87-p53w"/>
  </entry>
</feed>
