Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| go.opentelemetry.io/obi | go | < 0.9.0 | 0.9.0 |
Miggo AIRoot Cause AnalysisThe vulnerability lies in the CappedConcurrentHashMap implementation used for Java TLS state tracking. The remove method fails to remove keys from an internal ConcurrentLinkedQueue, leading to a memory leak. The analysis of the provided patch (commit 32442596038ce2c2690438157282b101763b4c54) confirms this. The patch completely replaces the vulnerable queue-based implementation with a more robust ring buffer approach, which inherently solves the memory leak by design. The primary vulnerable function is io.opentelemetry.obi.java.instrumentations.util.CappedConcurrentHashMap.remove, as it's the direct cause of the leak. The put method is also included as it's part of the vulnerable logic, but with medium confidence as the root cause is the lack of cleanup in remove. The vulnerability is triggered by frequent calls to remove, which happens in functions like cleanupConnectionBufMapping and removeBufferMapping in SSLStorage.java during normal TLS connection lifecycles.
io.opentelemetry.obi.java.instrumentations.util.CappedConcurrentHashMap.removepkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java
io.opentelemetry.obi.java.instrumentations.util.CappedConcurrentHashMap.putpkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java