CVE-2026-53660: OpenAM CSRF Vulnerability

CVE-2026-53660 Overview

Open Access Management (OpenAM) contains an insecure default configuration that exposes the iPlanetDirectoryPro single sign-on (SSO) cookie to theft through cross-site scripting (XSS). Versions prior to 16.1.1 initialize the SSO cookie without the HttpOnly flag and without a protective SameSite default. OAuth 2.0 and OpenID Connect (OIDC) consent flows compound the risk by reusing the same cookie through CsrfProtection as a CSRF token. An attacker chaining a same-origin XSS payload with a crafted link can read the cookie, hijack the SSO session, and complete attacker-driven consent grants. The issue is fixed in OpenAM 16.1.1.

Critical Impact
Successful exploitation results in full SSO session takeover and unauthorized OAuth/OIDC consent grants against federated applications relying on OpenAM.

Affected Products

Open Identity Platform OpenAM versions prior to 16.1.1
OpenAM deployments using default cookie configuration for iPlanetDirectoryPro
OpenAM instances exposing OAuth 2.0 or OpenID Connect consent endpoints

Discovery Timeline

2026-09-15 - CVE-2026-53660 published to the National Vulnerability Database (NVD)
2026-09-15 - Last updated in NVD database
Release 16.1.1 - Open Identity Platform publishes fixed release (GitHub Release v16.1.1)

Technical Details for CVE-2026-53660

Vulnerability Analysis

The vulnerability is a configuration and design flaw classified as [CWE-1004] Sensitive Cookie Without HttpOnly Flag. OpenAM issues the iPlanetDirectoryPro SSO cookie with HttpOnly disabled by default, which allows client-side JavaScript to read the cookie value through document.cookie. The cookie also lacks a restrictive SameSite attribute, permitting the browser to attach it to cross-site requests.

The design flaw is amplified by the CsrfProtection component in OpenAM's OAuth 2.0 and OIDC consent flows. Rather than issuing a dedicated anti-CSRF token, the consent handler reuses the SSO cookie value as the CSRF token. An attacker who obtains the cookie value simultaneously obtains a valid CSRF token, enabling attacker-driven consent grants without additional interaction.

Root Cause

Default initialization logic in openam-core/src/main/java/com/sun/identity/setup/ServicesDefaultValues.java and related setup constants did not enforce HttpOnly or SameSite protections on the SSO cookie. The consent CSRF protection derives its token from the SSO cookie value, coupling session confidentiality to CSRF integrity.

Attack Vector

Exploitation requires a same-origin XSS primitive in an application sharing the OpenAM cookie domain, plus user interaction with an attacker-controlled link. The attacker's JavaScript reads iPlanetDirectoryPro, exfiltrates it, and replays the value to complete OAuth or OIDC consent flows on behalf of the victim.

java

// Security patch excerpt - openam-core/src/main/java/com/sun/identity/setup/ServicesDefaultValues.java
 import com.iplanet.am.util.SystemProperties;
 import com.iplanet.services.util.Crypt;
 import com.sun.identity.common.DNUtils;
+import com.sun.identity.shared.debug.Debug;
 import com.sun.identity.shared.encode.Base64;
 import com.sun.identity.shared.encode.Hash;
 import com.sun.identity.shared.xml.XMLUtils;
// Source: https://github.com/OpenIdentityPlatform/OpenAM/commit/2af597267e6eb9302f75445c2c726f9b84f62966

The patch introduces stricter cookie handling and adjusted setup constants to enforce secure defaults on the iPlanetDirectoryPro cookie. See the GitHub Security Advisory GHSA-fpmh-vx4h-xc33 for the complete technical analysis.

Detection Methods for CVE-2026-53660

Indicators of Compromise

Unexpected OAuth 2.0 or OpenID Connect consent grants recorded in OpenAM audit logs for accounts that did not interact with a client application.
HTTP responses from OpenAM containing Set-Cookie: iPlanetDirectoryPro= without HttpOnly or SameSite attributes.
Requests to /oauth2/authorize or /oauth2/consent endpoints originating from unusual referrers or IP addresses shortly after a suspected XSS event.

Detection Strategies

Inspect OpenAM configuration and live HTTP responses to confirm whether the SSO cookie is issued with HttpOnly and SameSite=Lax or stricter.
Correlate authentication events for a single iPlanetDirectoryPro session ID observed from multiple client IP addresses or user agents.
Review web application firewall (WAF) telemetry for reflected or stored XSS payloads targeting hosts sharing the OpenAM cookie domain.

Monitoring Recommendations

Enable and centralize OpenAM audit logging for session creation, consent grants, and OAuth 2.0 token issuance.
Alert on new OAuth 2.0 client authorizations that occur without a prior login event in the same session lineage.
Monitor federated application logs for token issuance to clients not previously authorized by the end user.

How to Mitigate CVE-2026-53660

Immediate Actions Required

Upgrade OpenAM to version 16.1.1 or later using the official GitHub Release v16.1.1.
Invalidate all active iPlanetDirectoryPro sessions after upgrade to force re-authentication under the hardened defaults.
Audit recent OAuth 2.0 and OpenID Connect consent grants and revoke any that cannot be attributed to legitimate user activity.

Patch Information

The fix is delivered in OpenAM 16.1.1 through commit 2af59726. The patch modifies ServicesDefaultValues.java and SetupConstants.java to enforce secure cookie defaults. Additional context is available in the GitHub Security Advisory GHSA-fpmh-vx4h-xc33.

Workarounds

Configure the deploying servlet container or reverse proxy to append HttpOnly, Secure, and SameSite=Lax attributes to the iPlanetDirectoryPro cookie until the upgrade is applied.
Isolate OpenAM on a dedicated cookie domain so that XSS in unrelated applications cannot read the SSO cookie.
Disable or restrict OAuth 2.0 and OpenID Connect consent endpoints to trusted client identifiers until patching is complete.

bash

# Example: enforce HttpOnly and SameSite on the OpenAM SSO cookie via nginx reverse proxy
proxy_cookie_flags iPlanetDirectoryPro httponly secure samesite=lax;