{
  "@id": "urn:uuid:50d11a50-bf4e-4aa2-8e1d-909ddc0ea0ae",
  "role": "Document Creator",
  "author": "https://tuxcare.com",
  "version": 2,
  "@context": "https://openvex.dev/ns/v0.2.0",
  "timestamp": "2026-10-28T14:49:12.792520+00:00",
  "statements": [
    {
      "status": "fixed",
      "products": [
        {
          "@id": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1",
          "identifiers": {
            "purl": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1"
          }
        }
      ],
      "timestamp": "2026-10-28T14:49:12.792520+00:00",
      "status_notes": "Vulnerability CVE-2026-14683 is fixed in version 2.1.10-tuxcare.1 of org.hdrhistogram:HdrHistogram.",
      "vulnerability": {
        "name": "CVE-2026-14683"
      }
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1",
          "identifiers": {
            "purl": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1"
          }
        }
      ],
      "timestamp": "2026-10-28T14:49:03.865219+00:00",
      "status_notes": "Vulnerability CVE-2026-14684 does not affect version 2.1.10-tuxcare.1 of org.hdrhistogram:HdrHistogram. not_affected \u2014 HdrHistogram version 2.1.10 is not affected by CVE-2026-14684. The vulnerability describes uncontrolled memory allocation via manipulation of the numberOfSignificantValueDigits parameter in decodeFromByteBuffer. However, this version contains runtime validation (added in 2013) that restricts numberOfSignificantValueDigits to the range 0-5, preventing uncontrolled allocation. The validation is a...",
      "vulnerability": {
        "name": "CVE-2026-14684"
      },
      "impact_statement": "not_affected \u2014 HdrHistogram version 2.1.10 is not affected by CVE-2026-14684. The vulnerability describes uncontrolled memory allocation via manipulation of the numberOfSignificantValueDigits parameter in decodeFromByteBuffer. However, this version contains runtime validation (added in 2013) that restricts numberOfSignificantValueDigits to the range 0-5, preventing uncontrolled allocation. The validation is a..."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1",
          "identifiers": {
            "purl": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1"
          }
        }
      ],
      "timestamp": "2026-10-28T14:49:03.865219+00:00",
      "status_notes": "Vulnerability CVE-2026-14685 does not affect version 2.1.10-tuxcare.1 of org.hdrhistogram:HdrHistogram. not_affected \u2014 CVE-2026-14685 describes a state issue where recordValueWithCount() accepts arbitrary count values without validation. However, HdrHistogram is a data structure library (LIB) with no trust boundary of its own. The Mandatory Reachability Audit (MRA) shows no attacker-controllable entry point within the library's code. The count parameter is controlled by application code, not external attackers....",
      "justification": "vulnerable_code_not_in_execute_path",
      "vulnerability": {
        "name": "CVE-2026-14685"
      },
      "impact_statement": "not_affected \u2014 CVE-2026-14685 describes a state issue where recordValueWithCount() accepts arbitrary count values without validation. However, HdrHistogram is a data structure library (LIB) with no trust boundary of its own. The Mandatory Reachability Audit (MRA) shows no attacker-controllable entry point within the library's code. The count parameter is controlled by application code, not external attackers...."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1",
          "identifiers": {
            "purl": "pkg:maven/org.hdrhistogram/HdrHistogram@2.1.10-tuxcare.1"
          }
        }
      ],
      "timestamp": "2026-10-28T14:49:03.865219+00:00",
      "status_notes": "Vulnerability CVE-2026-14686 does not affect version 2.1.10-tuxcare.1 of org.hdrhistogram:HdrHistogram. not_affected \u2014 HdrHistogram (org.hdrhistogram:HdrHistogram) IS the CVE's affected product, so not a false positive. CVE-2026-14686 is a disputed CWE-697 (CVSS 3.3-4.0 LOW, local, data-integrity-only): in DoubleHistogram.recordValue the range check `(value < currentLowestValueInAutoRange) || (value >= currentHighestValueLimitInAutoRange)` returns false for NaN/+-Infinity (IEEE-754), so a NaN skips auto-ranging and is recorded as bucket 0 (GitHub issue #222; PR #224 proposed isNaN/isInfinite guards). The exact pattern IS present in target 2.1.10 at DoubleHistogram.java:334 and :344 with no NaN/Infinity guard, so I do NOT rely on OSV's 'introduced 2.2.0 / affected 2.2.1-2.2.2' metadata (the pattern predates 2.2.0). However, HdrHistogram is a LIBRARY: recordValue/recordValueWithCount are public metrics-recording APIs consuming the caller's own measured values, not attacker input crossing a trust boundary. No production entry point in HdrHistogram's own source routes attacker-controlled NaN into recordValue: the only main() (HistogramLogProcessor CLI) never calls recordValue, and internal callers (add/subtract/recordValueWithExpectedInterval) pass only integer-derived doubles. Per the mandatory Reachability Audit, 'a downstream app could pass NaN' is not valid exposure, so the flawed comparison is not reachable from the target's own trust boundary -> not_affected (code_not_reachable). This matches the CVE's disputed rationale (no security-boundary crossing). [VC re-run with claude-opus-4-8, prod pin d46bd7a, 2026-09-21; the earlier Sonnet run was parked by the author-verification gate after crediting a TuxCare backport for an upstream fix]",
      "justification": "vulnerable_code_not_in_execute_path",
      "vulnerability": {
        "name": "CVE-2026-14686"
      },
      "impact_statement": "not_affected \u2014 HdrHistogram (org.hdrhistogram:HdrHistogram) IS the CVE's affected product, so not a false positive. CVE-2026-14686 is a disputed CWE-697 (CVSS 3.3-4.0 LOW, local, data-integrity-only): in DoubleHistogram.recordValue the range check `(value < currentLowestValueInAutoRange) || (value >= currentHighestValueLimitInAutoRange)` returns false for NaN/+-Infinity (IEEE-754), so a NaN skips auto-ranging and is recorded as bucket 0 (GitHub issue #222; PR #224 proposed isNaN/isInfinite guards). The exact pattern IS present in target 2.1.10 at DoubleHistogram.java:334 and :344 with no NaN/Infinity guard, so I do NOT rely on OSV's 'introduced 2.2.0 / affected 2.2.1-2.2.2' metadata (the pattern predates 2.2.0). However, HdrHistogram is a LIBRARY: recordValue/recordValueWithCount are public metrics-recording APIs consuming the caller's own measured values, not attacker input crossing a trust boundary. No production entry point in HdrHistogram's own source routes attacker-controlled NaN into recordValue: the only main() (HistogramLogProcessor CLI) never calls recordValue, and internal callers (add/subtract/recordValueWithExpectedInterval) pass only integer-derived doubles. Per the mandatory Reachability Audit, 'a downstream app could pass NaN' is not valid exposure, so the flawed comparison is not reachable from the target's own trust boundary -> not_affected (code_not_reachable). This matches the CVE's disputed rationale (no security-boundary crossing). [VC re-run with claude-opus-4-8, prod pin d46bd7a, 2026-09-21; the earlier Sonnet run was parked by the author-verification gate after crediting a TuxCare backport for an upstream fix]"
    }
  ]
}