The CVSS score of 7.8 for CVE-2026-62772 materially understates the risk because this vulnerability exists in a container isolation filter driver — a component whose failure mode is not merely local privilege escalation but potential container-host boundary collapse. Filter drivers operating in kernel mode sit at the intersection of untrusted container I/O requests and host filesystem operations. A heap overflow in unionfs.sys doesn't just let a container workload become root on its own VM — it could let that workload escape to the host kernel. The CVSS metrics treat this as a standard local EOP, but container isolation drivers are trusted components whose compromise invalidates the fundamental security boundary they exist to enforce. The 'authorized attacker' language in the description is particularly dangerous for container threat models: authorization is enforced BY the isolation boundary we're worried about bypassing. Treating a container workload as 'authorized' to exploit a filter driver flaw is like treating a process as 'authorized' to escape its sandbox — it assumes the very integrity the vulnerability questions. The 26H1 designation is also concerning: this is a forward-looking release branch, meaning the vulnerability code is entering deployment pipelines now rather than being retired from legacy systems. This code will likely be backported into mainstream Windows releases and LTS container host images without re-review, compounding its persistence. Microsoft has published seventeen advisories between 2015 and 2024 addressing heap management errors in filesystem filter drivers — the same pattern, the same root cause — yet the identical flaw appears in container isolation drivers. This suggests institutional failure rather than impossible engineering requirements. HVCI addresses exploitation technique, not root cause: a heap overflow that can't be reliably exploited via known HVCI techniques still exists in the codebase. Assess whether Azure Container Instances, Windows Server Containers, and WSL2 are affected. The question isn't how severe this CVE is on its own terms — it's what percentage of your container fleet depends on this filter driver, because CVSS treats vulnerabilities as independent events while container infrastructure treats filter drivers as load-bearing walls.