CVE-2026-62900

The CVSS-EPSS gap in this disclosure isn't contradictory—it reflects a fundamental category mismatch. This isn't memory corruption in the traditional sense; it's a data lifecycle failure in a managed runtime where developers assume Dispose() means 'securely gone' when it only means 'eligible for collection.' The critical question is where the sensitive data is escaping. The CVE's mention of 'network transfer' is the signal that matters most. In .NET, this almost certainly means the data isn't sitting in local process memory waiting for a dump—it has flowed into observability pipelines: logging middleware, telemetry SDKs, HTTP client headers, or APM integrations. If a credential flows into OpenTelemetry headers or a logging serializer, your blast radius isn't 'the local process'—it's every downstream consumer of that telemetry, including vendors and analysts with dashboard access. That's a regulatory event, not just a security bug. The managed memory model creates specific failure modes. Dispose() doesn't zero memory—it marks it for collection. Async continuations pin objects beyond their expected lifetime. ObjectPool reuses buffers. The finalization queue holds references the developer thinks they've released. Each of these behaves differently under the same CWE-459 classification, and the actual exploitability depends entirely on which integration point is leaking. For prioritization: treat this as a data exfiltration vector, not a memory corruption vector. Your remediation path is determined by which observability pipeline is carrying the leaked data—rotate credentials regardless, then audit your logging, telemetry, and HTTP client configurations. If you're using any third-party APM or distributed tracing, assume the data may have already reached those systems. The low EPSS reflects that automated scanners can't detect this pattern yet, not that it isn't happening.

Reviewed through automated stages and approved by a human before publication.