An explainer for a maximum-severity (CVSS 10.0) vulnerability in OpenAM, an access-management product commonly used for single sign-on (SSO). It covers what happens, who is affected and how to respond, from the defender's side and without attack steps.
- CVE
- CVE-2026-123551 (GitHub advisory GHSA-5c3q-hp86-xjr8)
- Severity
- CVSS v3.1 10.0 (Critical); also 10.0 in CVSS v4.0 (the v4.0 score is from the CVE record)
- Type
- Session-token disclosure (CWE-201). The advisory also lists an authentication bypass (CWE-288) among others
- Preconditions
- Unauthenticated; network reach to the OpenAM port is enough. Per the advisory, default settings are affected
- Affected
- OpenAM (Open Identity Platform) 14.0.0 through 16.1.3
- Fix
- OpenAM 16.1.4
- Dates
- Advisory: 22 October 2026 / CVE record: 8 November 2026
- Exploitation
- No exploitation stated in the advisory. Not in CISA KEV (as of 9 November)
Risk of waiting
According to the advisory, an unauthenticated attacker can read users' session tokens, which act as the login itself. If an administrator session is captured, the advisory says this could lead to configuration takeover and command execution as the OpenAM service account. Collection leaves no failed logins or lockouts. Treat internet-facing OpenAM as the top priority.
What the vulnerability is
OpenAM notifies agents (components placed in front of applications to check authentication) about session creation, logout, timeout and property changes. Per the advisory, these notifications carry the full session identifier, which acts as a bearer credential: whoever holds it is treated as the user. Agent notifications are enabled by default.
Two weaknesses combine. The check that is meant to limit the notification WebSocket to agents can be bypassed without credentials through a legacy Liberty ID-FF (an older federation mechanism) endpoint. Once past it, a connected client can subscribe to any topic, including internal ones. This site does not describe how to exploit it.
Before (14.0.0 to 16.1.3)
- Clients other than agents can connect to the notification WebSocket
- Notifications contain the session identifier
- Collection is passive and leaves no trace in the logs
Changes in 16.1.4
- Security filters also run on internal request dispatches
- ID-FF endpoints no longer forward into internal endpoints
- WebSocket clients may subscribe only to agent topics
The advisory also notes that the same legacy ID-FF endpoints redirect the browser after login, federation or logout to an unchecked address taken from the request, and that with URL rewriting enabled the user's session token is appended to that address. In 16.1.4 redirect destinations are accepted only from a per-provider allow-list.
Who is affected
| Item | Detail |
|---|---|
| Product | OpenAM (Open Identity Platform) |
| Affected versions | 14.0.0 through 16.1.3 (CVE record wording: "from 14.0.0 before 16.1.4") |
| Fixed version | 16.1.4 |
| Not affected | Versions before 14.0.0 (no notification WebSocket) |
| Packages | openam-server-only, openam-federation-library, openam-notifications-websocket (group org.openidentityplatform.openam) |
- Per the advisory, default settings are affected.
- Derived and commercially supported builds depend on the version their vendors publish. Ask your vendor whether your build is affected.
How to check whether you are affected
Check your OpenAM version
Look at the version shown in the admin console, or the version of the deployed package (WAR, JAR and so on). 14.0.0 through 16.1.3 is affected. If you have production, staging and development instances, check each one (asset inventory checklist).
Check whether it is reachable from outside
Check whether the OpenAM port can be reached from the internet or any other untrusted network. The advisory says reaching the port is all an attacker needs.
Check whether you use agent notifications
Look at the agent-notification setting (org.forgerock.openam.notifications.agents.enabled). The advisory says it is enabled by default.
What to do today
Update to 16.1.4 (top priority)
Update OpenAM to 16.1.4, after reading the advisory's upgrade notes. If you redirect users to other hosts after ID-FF login, federation or logout, you must populate the new per-provider Relay State URL List. If you customised web.xml, add the dispatcher elements that 16.1.4 introduces.
Narrow the entry points until you can update
The advisory's workarounds are below. They do not replace updating.
・At the proxy, load balancer or firewall, allow only known agent hosts to reach /openam/notifications and /openam/ws/*.
・If your agents do not depend on notifications, disable agent notifications (set org.forgerock.openam.notifications.agents.enabled to false).
・If you do not use ID-FF federation, block the legacy Liberty ID-FF endpoints, including /openam/preLogin and /openam/postLogin.
Revoke existing sessions after the update
The advisory asks you to rotate exposed sessions and treat current administrator and user sessions as potentially exposed. After updating, force everyone, administrators included, to sign in again. As this site's addition, also review long-lived sessions on devices and sessions held by connected applications. The vulnerability remediation playbook covers the process.
Review logs and configuration changes
The advisory lists unexpected WebSocket connections, subscriptions to session topics and scripting-configuration changes as things to monitor. For the period before the update, review who reached the notification endpoints and the history of administrator configuration changes. Passive reading leaves no failed logins, so finding nothing is not reassurance.
Harden the scripting environment
The advisory advises keeping the scripting sandbox enforced, restricting who can change scripting configuration and running the container under an OS sandbox. This limits the damage if an administrator session is taken.
Exploitation status
- The advisory does not state that exploitation has been observed. It says technical details and proof-of-concept code are withheld to give operators time to upgrade.
- As of 9 November 2026 the flaw is not in CISA's KEV catalogue (catalogue version 2026.11.06).
- The NVD record was only created on 8 November and its status is Received (not yet analysed).
This site's view: weigh its place in SSO and the lack of traces more heavily than the score
With no KEV listing and no reported exploitation, "wait and see" is defensible on the score alone. Even so, this site recommends acting this week if your OpenAM is exposed to the internet, for two reasons.
First, once the centre of SSO is compromised, the same hijack spreads to every connected application. Second, as the advisory describes, reading tokens leaves little trace, so you cannot easily prove afterwards that nothing happened. Assume you cannot prove it and pair the update with session revocation. Multi-factor authentication strengthens the login step but does not stop someone who replays an already-issued session token (multi-factor authentication guide).
Sources
- OpenIdentityPlatform/OpenAM — GHSA-5c3q-hp86-xjr8: OpenAM unauthenticated session token disclosure (published 22 October 2026; affected and fixed versions, workarounds, upgrade notes)
- CVE.org — CVE-2026-123551 (published 8 November 2026; 14.0.0 before 16.1.4; CVSS 10.0)
- NVD — CVE-2026-123551 (created 8 November; status Received, i.e. not analysed; CWE-201)
- CISA KEV — Known Exploited Vulnerabilities Catalog (confirmed not listed as of 9 November)
Last verified: 9 November 2026.
Read next
- Practice: The vulnerability remediation playbook / Asset inventory checklist
- Deciding: Prioritising with CVSS, EPSS and KEV
- Authentication: Multi-factor authentication guide / Authentication vs authorization
- Terms: What is session fixation? / What is CVSS?