CVE-2026-85850
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-85850 is a high-severity Release of Invalid Pointer or Reference (CWE-763) vulnerability. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique OS Credential Dumping (T1003); ranked at the 26th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-99554
Vulnerability Data
Release of invalid pointer or reference in Windows Kernel allows an authorized attacker to elevate privileges locally.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation directly exercises deallocation paths and can find incorrect release calls or mismatched alloc/free pairs.
Documented development standards and tools can mandate safe memory-management idioms and static checks that avoid invalid releases.
An SDLC that incorporates security can embed memory-safety requirements, reducing the chance such coding errors are introduced.
Engineering principles require correct resource management and memory-release patterns that stop invalid pointer releases from being coded.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent invalid pointer release errors during development.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.25 mandates a secure-SDLC process (requirements, checkpoints, secure coding guidelines, testing, training) but does not itself stop an invalid pointer/reference from being released; the coding defect can still be written, reach production, and be exploitable.
A.8.26 only requires that security requirements (including resilience against attacks such as buffer overflows) be identified and specified during development; it does not itself enforce, implement or assure those requirements, so the invalid-pointer weakness can still arise and be exploited.
A.8.27 mandates establishing and applying secure engineering principles (e.g. least privilege, security by design, hardening) during architecture and development; it does not stop an invalid pointer release from being exploitable once the coding error exists in the product.
Secure coding standards directly prohibit mismatched or incorrect pointer-release calls.
Security testing can detect invalid pointer releases before release.