{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T20:17:33Z",
    "nvd_published_at": "2026-06-02T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe 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.\n\n### Details\n\nThe 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() \u003e capacity`.\n\nThe `remove()` method removes the key from the `ConcurrentHashMap` but leaves the key in the queue. Because `evictIfNeeded()` only checks `map.size() \u003e capacity`, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.\n\nThis 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` removes entries from `bufConn` and `activeConnections`, and `removeBufferMapping` removes entries from `bufToBuf`. In normal TLS connection lifecycles, those removals happen frequently.\n\n### PoC\n\nLocal testing with a small Java reproducer showed queue growth continuing after removals and eventually reached `OutOfMemoryError`, which matches the code-level leak mechanism described above.\n\nUse a vulnerable Java agent build from `v0.0.0-rc.2+build.2` or any later release that still contains the change. Start any JVM process instrumented with OBI\u0027s Java TLS support, then generate a large number of short-lived TLS handshakes.\n\nOne local reproducer is:\n\n```bash\ngit checkout v0.0.0-rc.2+build.2\nmake build\n```\n\nStart a simple TLS server:\n\n```bash\nopenssl req -x509 -newkey rsa:2048 -nodes -keyout /tmp/key.pem -out /tmp/cert.pem -subj \u0027/CN=localhost\u0027 -days 1\nopenssl s_server -accept 9443 -key /tmp/key.pem -cert /tmp/cert.pem -quiet\n```\n\nRun an instrumented JVM client that repeatedly opens and closes TLS connections:\n\n```java\n// save as /tmp/TLSChurn.java\nimport javax.net.ssl.*;\nimport java.net.Socket;\n\npublic class TLSChurn {\n  public static void main(String[] args) throws Exception {\n    SSLContext ctx = SSLContext.getInstance(\"TLS\");\n    ctx.init(null, new TrustManager[]{new X509TrustManager() {\n      public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }\n      public void checkClientTrusted(java.security.cert.X509Certificate[] c, String a) {}\n      public void checkServerTrusted(java.security.cert.X509Certificate[] c, String a) {}\n    }}, new java.security.SecureRandom());\n\n    SSLSocketFactory f = ctx.getSocketFactory();\n    for (;;) {\n      try (Socket s = f.createSocket(\"127.0.0.1\", 9443)) {\n        s.getOutputStream().write(\"x\".getBytes());\n      } catch (Exception ignored) {}\n    }\n  }\n}\n```\n\nCompile and run:\n\n```bash\njavac /tmp/TLSChurn.java\njava TLSChurn\n```\n\nAttach the vulnerable OBI Java instrumentation to the JVM. Over time, heap usage in the OBI Java agent process grows even though live connection counts remain bounded. A heap dump will show large retention from `ConcurrentLinkedQueue` nodes owned by `CappedConcurrentHashMap`.\n\n### Impact\n\nThis issue causes an availability loss in instrumented Java workloads that use OBI\u0027s TLS instrumentation. Repeated connection setup and teardown can grow the retained queue until the Java helper experiences long GC pauses or exhausts heap memory with `OutOfMemoryError`.",
  "id": "GHSA-962q-hwm5-52x5",
  "modified": "2026-06-09T10:58:45Z",
  "published": "2026-05-18T20:17:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-962q-hwm5-52x5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45682"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: CappedConcurrentHashMap leaks keys after removals"
}