IBM Verify Access CVE-2026-17616

Exploitation requires the IBM Verify Access / Verify Identity Access Reverse Proxy (WebSEAL) component to be running in one of the 'certain configurations' where cryptographic validation of user-supplied data is weakened - the CVE text does not name the exact setting, so the precise enabling configuration must be confirmed against IBM advisory node 7283079. The CVSS vector (PR:N/UI:N) indicates no authentication and no user interaction are needed once that configuration is present, and AV:N means it is reachable over the network. The primary limiting factor is that this is not a default-configuration flaw: the 'certain configurations' scoping means deployments not using the affected cryptographic/validation option are likely not exploitable, and affected versions are bounded to Security Verify Access ≤10.0.9.2 and Verify Identity Access (Container) ≤11.0.3.

The signals here conflict and should temper the raw score. NVD's CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) implies trivial, unauthenticated, network-based full compromise, yet the description explicitly scopes the flaw to 'certain configurations,' which argues for higher attack complexity than AC:L reflects and casts doubt on a blanket A:H availability impact. EPSS is only 0.24% (15th percentile) and CISA's SSVC framework records exploitation status 'none' and automatable 'no' (though technical impact 'total'), so this reads as a genuinely serious but not currently-exploited, non-wormable issue rather than an active fire. There is no public exploit identified at time of analysis and no KEV listing. Net: treat it as high priority for any deployment matching the vulnerable configuration because the technical impact is total and the component is a security control, but the absence of exploitation evidence and the config dependency mean it is patch-in-normal-cycle-urgently rather than drop-everything - a mid-sized operator running an internet-facing Verify Access proxy should prioritize the IBM fix even though widespread automated attacks are not indicated.

An attacker who can reach an internet-facing Verify Access Reverse Proxy running a vulnerable configuration submits crafted user-supplied data whose cryptographic protection the proxy fails to validate at the expected strength, causing the proxy to trust forged or tampered input and undermine an authentication or authorization decision. No public proof-of-concept is available, and the CVSS network vector with (as scored) low complexity means the network-facing step is straightforward, though the real-world requirement of a specific configuration raises the practical bar.