The CVSS 5.5 score assigned to CVE-2026-66151 measures a system crash, but an out-of-bounds read in a kernel-mode driver like SWIPsec.sys is architecturally different from a usermode denial-of-service. Kernel pool memory contains session tokens, credential buffers, and kernel callback data — a read primitive doesn't need to write anything to be dangerous; it just needs to touch memory an attacker shouldn't access and survive long enough to exfiltrate. The CVSS availability score reflects the crash vector while ignoring the information disclosure dimension that has persistent consequences even after the system recovers.
What actually matters is the blast radius. The SonicWall Global VPN client runs with kernel privileges on installation — this isn't a sandbox escape, it's already at ring zero. A compromised laptop running this client isn't just an endpoint; it's the authenticated bridge to the corporate network. A single kernel read that touches the wrong session buffer doesn't need code execution to detonate. It needs to leak a credential that unlocks the entire VPN trust model. That's not a 5.5 severity vulnerability — that's crown jewel territory.
The deeper concern is whether this is an isolated fix or indicative of broader driver instability. VPN driver security patches are almost never singular events — they tend to be leading indicators of architectural rot. The pattern across two decades of similar CVEs shows one researcher finds a bounds-check failure, the vendor patches that instance, then six to eighteen months later a second, third, and fourth OOB access surfaces in adjacent functions within the same driver. If SWIPsec.sys has had prior CVEs in this version range, the conditional probability of additional vulnerabilities is significantly higher.
What you should do: treat this as a conditional probability signal rather than a standalone DoS patch. Check whether this driver has a history of similar disclosures or whether the vendor has shipped multiple kernel memory safety issues in adjacent product lines. If so, the CVSS score should be adjusted upward not based on this vulnerability in isolation, but based on the driver's vulnerability history. The question isn't whether SWIPsec.sys has more bugs — it almost certainly does. The question is whether the threat model that necessitates kernel access in the first place has been questioned, and whether your organization is treating a one-time patch event rather than a 'should we be running this driver at all' decision.