The CVSS 5.5 and EPSS 0.0032 for this Windows GDI out-of-bounds read will likely push it off your immediate radar. Resist that impulse — the scoring model is capturing the wrong threat dimension.
GDI operates in kernel mode, and this isn't a network-service vulnerability where the blast radius is confined to one process's heap. An out-of-bounds read in the graphics subsystem can cross the user-kernel boundary and pull from kernel heap allocations, exposing kernel pointers, heap metadata, or structured data from adjacent memory regions. That directly undermines ASLR — the very mechanism that makes other, more severe vulnerabilities harder to exploit. If you're defending a system where an attacker already has local code execution (which describes every post-exploitation scenario, every commodity malware deployment, every ransomware operator), this read becomes the precision instrument that enables privilege escalation. The "authorized attacker" qualifier in the CVE is a relic of threat models where the local user is trusted — it has no relevance to attacker toolchains that assume local access as a starting condition, not a barrier.
The historical pattern is more instructive than the score suggests. GDI information disclosures have repeatedly appeared in documented privilege escalation chains not as the initial access, but as the critical read that makes the elevation possible. CVE-2021-43298, the GDI leaks chained in 2022-37969 — each followed this template. The read is the second move, but it's the move that transforms limited access into full system compromise.
What should you do? First, treat any GDI information disclosure as a high-priority patch regardless of the CVSS score — the real risk is the ASLR bypass it enables for other vulnerabilities. Second, recognize that the low score creates a dangerous feedback loop: it signals to maintainers that this component is "good enough," which perpetuates the conditions that produce the next similar flaw. Third, assume this class of vulnerability will be used passively and silently — there's no crash, no alert, no detection signature. It runs in the background while a separate escalation exploit executes. Fourth, if you're managing a large Windows fleet, understand that the compound risk comes not from any single GDI CVE but from the inventory of low-scored GDI disclosures that remain unpatched while attackers accumulate precision ASLR bypass tools. That exposure window is the actual attack surface.
This isn't a critical remote code execution bug — it's a component-level problem with kernel-adjacent blast radius that scores as medium because the scoring framework can't evaluate compound risk or passive exploitation. Your prioritization model needs to.