https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 15:16:28 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-324060 EUVD-2026-324060 https://cve.radiocsirt.org/vuln/euvd-2026-324060 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45682 <p>OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory. This issue has been patched in version 0.9.0.</p> <p>OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory. This issue has been patched in version 0.9.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45682 https://cve.radiocsirt.org/vuln/ghsa-962q-hwm5-52x5 <p><strong>Affected:</strong> Go: go.opentelemetry.io/obi</p> <p>### Summary</p> <p>The custom `CappedConcurrentHashMap` introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory.</p> <p>### Details</p> <p>The vulnerable implementation is in [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11). New keys are appended to a `ConcurrentLinkedQueue`, and eviction only runs inside `put()` when `map.size() &gt; capacity`.</p> <p>The `remove()` method removes the key from the `ConcurrentHashMap` but leaves the key in the queue. Because `evictIfNeeded()` only checks `map.size() &gt; capacity`, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.</p> <p>This pattern is reachable from [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66), where `cleanupConnectionBufMapping` remov…</p> <p><strong>Affected:</strong> Go: go.opentelemetry.io/obi</p> <p>### Summary</p> <p>The custom `CappedConcurrentHashMap` introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory.</p> <p>### Details</p> <p>The vulnerable implementation is in [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11). New keys are appended to a `ConcurrentLinkedQueue`, and eviction only runs inside `put()` when `map.size() &gt; capacity`.</p> <p>The `remove()` method removes the key from the `ConcurrentHashMap` but leaves the key in the queue. Because `evictIfNeeded()` only checks `map.size() &gt; capacity`, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.</p> <p>This pattern is reachable from [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66), where `cleanupConnectionBufMapping` remov…</p> https://cve.radiocsirt.org/vuln/ghsa-962q-hwm5-52x5 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11053-1 <p>alloy-1.17.0-1.1 on GA media</p> <p>alloy-1.17.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11053-1 https://cve.radiocsirt.org/vuln/suse-su-2026:22575-1 <p>Security update for alloy</p> <p>Security update for alloy</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22575-1