IBM Verify Access EUVD-2026-57539

Exploitation requires a valid authenticated user account on the affected IBM Verify Access or Verify Identity Access instance, consistent with the CVSS PR:L (low privilege) metric - anonymous or unauthenticated attackers cannot exploit this directly. The attack is network-accessible (AV:N) with low complexity (AC:L), meaning no special network position, timing, or target interaction is required beyond holding credentials. No specific non-default configuration is indicated as a prerequisite; the vulnerability appears to affect standard deployments. Exploitation is limited to authenticated users - insider threats, compromised service accounts, or attackers who have already obtained low-privilege credentials through phishing or credential stuffing represent the realistic threat actor profile.

The CVSS 3.1 base score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) accurately reflects a serious but authenticated threat: an attacker must hold a valid low-privilege account before exploiting this flaw, which materially limits opportunistic attack surface compared to unauthenticated issues. The low attack complexity (AC:L) means no race conditions, special timing, or advanced knowledge is required once access is obtained - a straightforward crafted request is sufficient. High confidentiality and integrity impact (C:H/I:H) are appropriate given that impersonating another user in an IAM product can expose session data, access tokens, and the ability to act on behalf of the victim across integrated applications. No EPSS data was provided; no KEV listing or public exploit code is identified at time of analysis, which tempers urgency slightly. However, IBM Verify Access functions as a trust anchor in enterprise SSO and zero-trust architectures, meaning successful exploitation could propagate access to downstream protected resources far beyond the IAM product itself - the real-world blast radius likely exceeds what the unchanged scope (S:U) metric suggests. This should be treated as a high-priority remediation for any enterprise with exposed IBM Verify Access instances.

An attacker with a valid but low-privilege IBM Verify Access account authenticates normally, then crafts an HTTP request in which a user-controlled parameter (such as a user ID, token claim, or session attribute) is modified to reference a different, higher-privileged target account. The server, relying on this parameter as an assumed-immutable value rather than re-validating it against the authenticated session, grants the attacker the privileges and data of the target user. No public proof-of-concept exploit code has been identified at time of analysis, but the low attack complexity suggests this pattern is straightforward to discover and replicate.