The CVSS 8.7 rating on CVE-2026-16520 obscures a more fundamental problem: a network access control product — a category whose entire purpose is enforcing least-privilege access — contains both SQL injection and authentication bypass. These aren't sophisticated attacks; they've been textbook-preventable for over two decades.
The likely failure modes here deserve attention because they reveal systemic risk. NAC products accumulate years of feature requests requiring database queries against endpoint data, and the pressure to ship quickly often produces unsanitized query-building code. Authentication bypass alongside SQL injection typically indicates inconsistent auth checks across application layers, or legacy authentication logic that wasn't refactored as the product evolved. The fact that this affects Genian NAC V4, V5, and ZTNA V6 simultaneously suggests either shared vulnerable libraries or insecure coding patterns that were copy-pasted rather than centralized into hardened modules.
What you should do: First, confirm exactly which version you're running — the affected revision ranges span V4.x, V5.x, and V6.x across multiple branches. If you're on an older branch, check whether a fix exists in a later version and was backported to your release track. If it wasn't, you're running known-vulnerable code that your vendor has decided not to maintain. Second, examine your deployment posture — NAC products sit at the network chokepoint, manage endpoint compliance state, and typically hold credentials for infrastructure they control. SQL injection plus auth bypass here doesn't give you 'access to the NAC'; it gives you administrative control over network access policy for potentially every endpoint in your organization. Third, consider your patching cadence. Enterprises typically patch NAC conservatively because of its critical role, which means vulnerable-but-highly-privileged NAC installations can remain exploitable for extended windows. The network position and policy authority of this product category matters more than the technical simplicity of the vulnerability.
For procurement: if a dedicated security vendor can't get input validation and session integrity right across multiple product generations, require evidence of secure development lifecycle practices — SAST/DAST in CI/CD, code review requirements — as a procurement criterion. The historical pattern suggests security vendors develop an internal trust hierarchy where their own product traffic is implicitly privileged, meaning their query builders and auth middleware are never tested against adversarial input. Assume this pattern applies to any vendor until proven otherwise.