<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-04T15:16:03.705239+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/euvd-2026-324315</id>
    <title>EUVD-2026-324315</title>
    <updated>2026-10-04T15:16:03.709944+00:00</updated>
    <content>EUVD-2026-324315</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-324315"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45686</id>
    <title>fkie_cve-2026-45686</title>
    <updated>2026-10-04T15:16:03.709975+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From version 0.7.0 to before version 0.9.0, a remotely reachable integer overflow in OBI's memcached text protocol parser can crash the OBI process and cause denial of service. When parsing memcached storage commands such as set, add, replace, append, prepend, or cas, OBI accepts extremely large &lt;bytes&gt; values and adds the payload delimiter length without checking for overflow. A crafted request with &lt;bytes&gt; set to math.MaxInt or math.MaxInt-1 causes the computed payload length to wrap negative and triggers a runtime panic in LargeBufferReader.Peek. This issue has been patched in version 0.9.0.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-45686"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-43g7-cwr8-q3jh</id>
    <title>GHSA-43g7-cwr8-q3jh — OpenTelemetry eBPF Instrumentation: Memcached payload length overflow can crash OBI</title>
    <updated>2026-10-04T15:16:03.710009+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: go.opentelemetry.io/obi</p>
<p>### Summary</p>
<p>A remotely reachable integer overflow in OBI's memcached text protocol parser can crash the OBI process and cause denial of service. When parsing memcached storage commands such as `set`, `add`, `replace`, `append`, `prepend`, or `cas`, OBI accepts extremely large `&lt;bytes&gt;` values and adds the payload delimiter length without checking for overflow. A crafted request with `&lt;bytes&gt;` set to `math.MaxInt` or `math.MaxInt-1` causes the computed payload length to wrap negative and triggers a runtime panic in `LargeBufferReader.Peek`.</p>
<p>### Details</p>
<p>The issue is in the memcached request parser at `pkg/ebpf/common/memcached_detect_transform.go`.</p>
<p>`memcachedCommandBytesField` parses the storage command `&lt;bytes&gt;` field with `strconv.Atoi` and only rejects negative values:</p>
<p>```go
size, err := strconv.Atoi(string(fields[4]))
if err != nil || size &lt; 0 {
	return 0, false
}
```</p>
<p>Because there is no upper bound check, values up to `math.MaxInt` are accepted.</p>
<p>`memcachedConsumeStoragePayload` then computes the payload length by adding the trailing `\r\n` delimiter length:</p>
<p>```go
payloadLen := bytesField + len(memcachedDelimBytes)
payload, err := r.Peek(payloadLen)
```</p>
<p>If `bytesField` is `math.MaxInt` or `math.MaxInt-1`, this addition overflows the signed `int` and produces a negative `payloadLen`.</p>
<p>That negative length is passed into `LargeBufferReader.Peek` in `pkg/internal/largebuf/large_buffer.go`. `Peek` checks whether `n &gt; Remaining()` but does not reject negative values be…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-43g7-cwr8-q3jh"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11053-1</id>
    <title>openSUSE-SU-2026:11053-1 — alloy-1.17.0-1.1 on GA media</title>
    <updated>2026-10-04T15:16:03.710067+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>alloy-1.17.0-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11053-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:22575-1</id>
    <title>SUSE-SU-2026:22575-1 — Security update for alloy</title>
    <updated>2026-10-04T15:16:03.710088+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for alloy</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:22575-1"/>
  </entry>
</feed>
