IBM Verify Identity Access CVE-2026-4938

Exploitation requires the attacker to hold a valid account on the IBM Verify Identity Access or IBM Security Verify Access platform with at minimum read-only privileges - unauthenticated access is not sufficient per the CVSS PR:L metric. The affected write/deploy operations must be reachable over the network, which is the expected deployment posture for these IAM management interfaces. No additional non-default configuration is stated as required; any deployment of the affected version ranges with a low-privilege account provisioned is potentially exploitable. Exploitation is limited by the requirement to possess valid credentials (PR:L), meaning compromised or stolen read-only account credentials are a prerequisite. There is no user interaction required (UI:N) and attack complexity is low (AC:L) once credentials are in hand.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) yields a Medium score of 6.5, reflecting that exploitation requires an authenticated low-privilege account but is otherwise straightforward - no complexity, no user interaction, network-accessible. The high integrity impact is significant in the context of an IAM platform: unauthorized deployments or configuration changes on an identity broker can introduce rogue policies, backdoor accounts, or weakened authentication rules with downstream blast radius across all relying-party applications. No EPSS data was provided, no public exploit code exists, and the vulnerability is not listed in CISA KEV, suggesting it has not seen widespread exploitation. However, IAM platforms are high-value targets and even a read-only service account credential - obtainable through phishing, credential stuffing, or leaked secrets - is sufficient for exploitation. The gap between the CVSS medium score and potential business impact is notable and defenders should weight the asset criticality of the IAM layer when prioritizing remediation.

An attacker who has obtained read-only credentials for the IBM Verify Identity Access administrative interface - via credential stuffing against a shared account, exfiltration of a service account secret, or insider access - authenticates over the network and invokes a deployment or configuration modification API endpoint that should be restricted to privileged administrators. Because the authorization check is incorrect, the request succeeds and the attacker is able to push unauthorized configuration changes, such as modifying authentication policies, adding federation trust relationships, or deploying modified rule sets. No public exploit code has been identified at time of analysis.