CVE-2024-35133: IBM Security Verify Access Redirect Flaw

CVE-2024-35133 Overview

CVE-2024-35133 is an open redirect vulnerability in the IBM Security Verify Access OpenID Connect (OIDC) Provider. The flaw affects IBM Security Verify Access versions 10.0.0 through 10.0.8, including the Docker distribution. A remote authenticated attacker can craft a malicious URL that uses the trusted IBM Security Verify Access domain to redirect victims to attacker-controlled sites. The vulnerability is categorized as URL Redirection to Untrusted Site [CWE-601] and enables phishing campaigns that abuse the trust users place in the legitimate authentication endpoint. Successful exploitation can lead to credential theft, session token capture, and downstream account compromise.

Critical Impact
Attackers can hijack the OIDC redirect flow to send authenticated users to malicious sites under the guise of a trusted IBM identity provider, enabling targeted phishing and credential harvesting.

Affected Products

IBM Security Verify Access 10.0.0 through 10.0.8
IBM Security Verify Access Docker 10.0.0 through 10.0.8
IBM Security Verify Access OIDC Provider component

Discovery Timeline

2024-08-29 - CVE-2024-35133 published to the National Vulnerability Database
2024-08-29 - IBM publishes IBM Support Document #7166712
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-35133

Vulnerability Analysis

The vulnerability resides in the OIDC Provider component of IBM Security Verify Access. The provider fails to properly validate redirect parameters supplied during authentication flows. An authenticated attacker can supply a crafted redirect value that points to an external, attacker-controlled domain. Because the initial URL bears the legitimate IBM Security Verify Access hostname, victims and security controls treat the link as trustworthy.

The attack chain typically pairs the open redirect with a phishing lure. After clicking the trusted-looking link, the victim is silently redirected to a spoofed login page or content-delivery resource. Attackers can then capture OIDC tokens, harvest credentials, or deliver follow-on payloads. The redirected URL inherits implicit trust from the originating identity provider, which is the primary cause of impact escalation.

Root Cause

The root cause is insufficient validation of user-controllable redirect parameters within the OIDC Provider [CWE-601]. The provider does not enforce a strict allowlist of permitted redirect destinations and does not reject absolute external URLs. This allows the redirect_uri or equivalent parameter to be manipulated into pointing outside the trusted origin.

Attack Vector

Exploitation requires the attacker to be authenticated and to convince a victim to click a specially crafted link. The malicious URL uses the legitimate Verify Access domain as the host but encodes an external destination in the redirect parameter. When the victim follows the link, the OIDC Provider issues an HTTP redirect to the attacker-controlled site. No special privileges on the victim's endpoint are required, and the integrity of the displayed URL bar is preserved up until the redirect occurs.

No verified public proof-of-concept code is published for CVE-2024-35133. Refer to the IBM X-Force Vulnerability #291026 entry for additional technical context.

Detection Methods for CVE-2024-35133

Indicators of Compromise

Outbound HTTP 302 or 303 redirects from the Verify Access OIDC Provider whose Location header points to domains outside the organization's allowlist.
Authentication logs showing OIDC requests containing encoded external URLs in redirect_uri, state, or similar parameters.
User reports of unexpected login pages reached through links that originated from a trusted IBM Security Verify Access hostname.

Detection Strategies

Parse OIDC Provider access logs and alert on redirect_uri values that do not match the registered client redirect allowlist.
Deploy web proxy or WAF rules that inspect query strings on Verify Access endpoints for absolute URLs in redirect parameters.
Correlate user click telemetry from email security gateways with OIDC redirect responses to surface phishing chains that abuse the trusted domain.

Monitoring Recommendations

Forward Verify Access OIDC Provider logs to a centralized SIEM and retain at least 90 days for retrospective analysis.
Monitor for spikes in authenticated session activity followed by redirects to newly registered or low-reputation external domains.
Track changes to OIDC client registrations and redirect URI allowlists for unauthorized modifications.

How to Mitigate CVE-2024-35133

Immediate Actions Required

Apply the fix described in IBM Support Document #7166712 to all Verify Access instances running 10.0.0 through 10.0.8.
Audit OIDC client registrations and remove wildcard or overly permissive redirect_uri entries.
Notify users of the active phishing risk and reinforce verification of post-login destinations.

Patch Information

IBM has issued a remediation through the official advisory at IBM Support Document #7166712. Administrators should upgrade IBM Security Verify Access and the Verify Access Docker image to the fixed release identified in that advisory. The X-Force entry IBM X-Force Vulnerability #291026 tracks the same remediation guidance.

Workarounds

Restrict OIDC client redirect_uri values to a strict allowlist of fully qualified internal URLs until patching is complete.
Place the Verify Access OIDC Provider behind a reverse proxy that rewrites or blocks redirect responses pointing to external hosts.
Disable or quarantine unused OIDC clients to reduce the attack surface available to authenticated adversaries.

bash

# Example reverse-proxy rule to block external redirect targets
# NGINX snippet placed in front of the Verify Access OIDC endpoint
location /oidc/ {
    proxy_pass https://verify-access.internal/oidc/;
    proxy_intercept_errors on;
    header_filter_by_lua_block {
        local loc = ngx.header["Location"]
        if loc and not loc:match("^https://verify%-access%.internal/") then
            ngx.header["Location"] = nil
            ngx.status = 403
        end
    }
}