Windows GDI CVE-2026-61360

Exploitation requires a local session on the affected Windows machine with at minimum a low-privileged authenticated account (consistent with PR:L from the CVSS vector). No user interaction is required beyond the attacker invoking the vulnerable GDI code path. There is no evidence this is exploitable remotely or without authentication. The following conditions limit exploitation: the attacker must already have local logon access (physical, RDP, or terminal session), meaning the attack surface is restricted to users or services with interactive or scripted local execution capability. Non-default configurations are not a prerequisite - the vulnerability exists in GDI's default operational mode present across all affected Windows builds. The scope is strictly local information disclosure; there is no path to remote exploitation or to integrity/availability impact based on available data.

The CVSS 5.5 Medium score accurately reflects the constrained threat model: AV:L limits exploitation to users with local system access, AC:L indicates straightforward exploitation once access is established, and PR:L confirms that at minimum a low-privileged authenticated account is required - no unauthenticated remote exploitation path exists. The impact is bounded to confidentiality (C:H) with no integrity or availability consequence and no scope change (S:U), meaning kernel or cross-process code execution is not in scope for this vulnerability as described. No POC exploit code is publicly available and CISA KEV status is not confirmed, placing this firmly in the category of a standard patch-cycle item rather than an emergency. Even a mid-sized municipal IT team in ustka should treat this as a routine monthly patch priority given that every supported Windows release is affected, while large enterprises with automated patch distribution can absorb it in their normal cadence. No conflicting signals exist between CVSS vector and the vulnerability description - both align on a local, authenticated, information-disclosure-only scenario with no exploitation barrier beyond local access.

A local attacker authenticated with a standard low-privileged account on an unpatched Windows system crafts a GDI API call that supplies a controlled pointer value to the vulnerable GDI code path. When GDI dereferences the untrusted pointer, memory contents from a privileged address - potentially including sensitive kernel data, ASLR layout information, or process memory - are returned to the attacker, enabling information leakage that could support further privilege escalation. No public exploit code has been identified at time of analysis, but the low attack complexity (AC:L) and absence of user interaction requirements make this technically straightforward to reproduce once the vulnerable code path is identified.