CVE-2024-35133: CVE-2024-35133: IBM Security Verify Access 10.0.0 through 10.0.8 OIDC Provider could allow a remote authen…

What it is

IBM Security Verify Access 10.0.0 through 10.0.8 OIDC Provider could allow a remote authenticated attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim.

Exploitation evidence

First exploit evidence seen: 2025-04-05 (earliest date across the sources below).

Exploited in the wild

No source on this site lists in-the-wild exploitation yet (CISA KEV, VulnCheck KEV).

Public exploit code

Exploit-DB

• EDB-52123: IBM Security Verify Access 10.0.0 - Open Redirect during OAuth Flow (2025-04-05)

GitHub proof-of-concept repositories below quality bar

1 public repositories from 1 accounts, first seen 2024-10-18.

Verify before running: public PoCs can be malicious. Read the code and only run it in an isolated lab. A PoC means exploit code is public, not that this CVE is exploited in the wild.

Sources: Exploit-DB (OffSec) · nomi-sec/PoC-in-GitHub.

How to fix it

Fixed versions

• ibm security verify access: versions up to and including 10.0.8 are affected; check the vendor advisory for the fixed release.
• ibm security verify access docker: versions up to and including 10.0.8 are affected; check the vendor advisory for the fixed release.

Derived from the NVD CPE configuration (versionEndExcluding / versionEndIncluding). Always confirm with the vendor advisory.

Vendor advisories and patches

• https://www.ibm.com/support/pages/node/7166712 (Vendor Advisory)

MITRE ATT&CK mitigations for this chain

• M1054 Software Configuration (for T1566.002) : Use anti-spoofing and email authentication mechanisms to filter messages based on validity checks of the sender domain (using SPF) and integrity of messages (using DKIM). Enabling these mechanisms within an organization (through policies such as DMARC) may enable recipients (intra-org and cross domain) to perform simil
• M1021 Restrict Web-Based Content (for T1566.002) : Determine if certain websites that can be used for spearphishing are necessary for business operations and consider blocking access if activity cannot be monitored well or if it poses a significant risk.
• M1047 Audit (for T1566.002) : Audit applications and their permissions to ensure access to data and resources are limited based upon necessity and principle of least privilege.
• M1018 User Account Management (for T1566.002) : Azure AD Administrators apply limitations upon the ability for users to grant consent to unfamiliar or unverified third-party applications.
• M1017 User Training (for T1566.002) : Users can be trained to identify social engineering techniques and spearphishing emails with malicious links which includes phishing for consent with OAuth 2.0. Additionally, users may perform visual checks of the domains they visit; however, homographs in ASCII and in IDN domains and URL schema obfuscation may render

Detection Generic guidance

• Initial Access: Alert on unusual requests to the affected service (odd paths, oversized payloads, exploit strings) in WAF, reverse-proxy and application logs.

Response checklist Generic guidance

1. Inventory: find every instance of the affected product and version (include internet-facing and forgotten ones).
2. Patch or mitigate per the vendor advisory; if you cannot patch, remove internet exposure or apply the vendor workaround.
3. Assume compromise if the system was exposed before patching: hunt for the indicators in the advisory and review logs back to the disclosure date.
4. Rotate credentials and secrets stored on or used by the affected system if compromise cannot be ruled out.