https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 23:39:44 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-216321 EUVD-2026-216321 https://cve.radiocsirt.org/vuln/euvd-2026-216321 https://cve.radiocsirt.org/vuln/fkie_cve-2023-25568 <p>Boxo, formerly known as go-libipfs, is a library for building IPFS applications and implementations. In versions 0.4.0 and 0.5.0, if an attacker is able allocate arbitrary many bytes in the Bitswap server, those allocations are lasting even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server and also affects users using the old API stubs at `github.com/ipfs/go-libipfs/bitswap` because users then transitively import `github.com/ipfs/go-libipfs/bitswap/server`. Boxo versions 0.6.0 and 0.4.1 contain a patch for this issue. As a workaround, those who are using the stub object at `github.com/ipfs/go-libipfs/bitswap` not taking advantage of the features provided by the server can refactor their code to use the new split API that will allow them to run in a client only mode: `github.com/ipfs/go-libipfs/bitswap/client`.</p> <p>Boxo, formerly known as go-libipfs, is a library for building IPFS applications and implementations. In versions 0.4.0 and 0.5.0, if an attacker is able allocate arbitrary many bytes in the Bitswap server, those allocations are lasting even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server and also affects users using the old API stubs at `github.com/ipfs/go-libipfs/bitswap` because users then transitively import `github.com/ipfs/go-libipfs/bitswap/server`. Boxo versions 0.6.0 and 0.4.1 contain a patch for this issue. As a workaround, those who are using the stub object at `github.com/ipfs/go-libipfs/bitswap` not taking advantage of the features provided by the server can refactor their code to use the new split API that will allow them to run in a client only mode: `github.com/ipfs/go-libipfs/bitswap/client`.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-25568 https://cve.radiocsirt.org/vuln/ghsa-m974-xj4j-7qv5 <p><strong>Affected:</strong> Go: github.com/ipfs/go-libipfs</p> <p>### Impact An attacker is able allocate arbitrarily many bytes in the Bitswap server by sending many `WANT_BLOCK` and or `WANT_HAVE` requests which are queued in an unbounded queue, with allocations that persist even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server, this also affects users using the old API stubs at `github.com/ipfs/boxo/bitswap` because it transitively uses `github.com/ipfs/boxo/bitswap/server`.</p> <p>We have [renamed go-libipfs to boxo](https://github.com/ipfs/boxo/issues/215); this document uses both terms interchangeably. The version numbers for both are applicable, as they share the same historical timeline.</p> <p>### Remediation Apply one of: - Update `boxo` to [`v0.6.0`](https://github.com/ipfs/boxo/releases/tag/v0.6.0) or later - Update `boxo` to [`v0.4.1`](https://github.com/ipfs/boxo/releases/tag/v0.4.1) Note that ***`v0.5.0` is NOT safe***, `v0.4.1` is a backport of the `v0.6.0` security fixes on top of `v0.4.0`.</p> <p>### Mitigations 1. The server now limits how many wantlist entries per peer it knows. The `MaxQueuedWantlistEntriesPerPeer` option allows configuring how many wantlist entries the server remembers; if a peer sends a wantlist bigger than this (including a sum of multiple delta updates) the server will truncate the wantlist to the match the limit. This defaults to `1024` entries per peer. 2. The server now properly clears state about peers when they disconnect. Peer state is more…</p> <p><strong>Affected:</strong> Go: github.com/ipfs/go-libipfs</p> <p>### Impact An attacker is able allocate arbitrarily many bytes in the Bitswap server by sending many `WANT_BLOCK` and or `WANT_HAVE` requests which are queued in an unbounded queue, with allocations that persist even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server, this also affects users using the old API stubs at `github.com/ipfs/boxo/bitswap` because it transitively uses `github.com/ipfs/boxo/bitswap/server`.</p> <p>We have [renamed go-libipfs to boxo](https://github.com/ipfs/boxo/issues/215); this document uses both terms interchangeably. The version numbers for both are applicable, as they share the same historical timeline.</p> <p>### Remediation Apply one of: - Update `boxo` to [`v0.6.0`](https://github.com/ipfs/boxo/releases/tag/v0.6.0) or later - Update `boxo` to [`v0.4.1`](https://github.com/ipfs/boxo/releases/tag/v0.4.1) Note that ***`v0.5.0` is NOT safe***, `v0.4.1` is a backport of the `v0.6.0` security fixes on top of `v0.4.0`.</p> <p>### Mitigations 1. The server now limits how many wantlist entries per peer it knows. The `MaxQueuedWantlistEntriesPerPeer` option allows configuring how many wantlist entries the server remembers; if a peer sends a wantlist bigger than this (including a sum of multiple delta updates) the server will truncate the wantlist to the match the limit. This defaults to `1024` entries per peer. 2. The server now properly clears state about peers when they disconnect. Peer state is more…</p> https://cve.radiocsirt.org/vuln/ghsa-m974-xj4j-7qv5 https://cve.radiocsirt.org/vuln/gsd-2023-25568 gsd-2023-25568 https://cve.radiocsirt.org/vuln/gsd-2023-25568