Vulnerabilities

OpenAM CVSS 10 flaw can leak live admin session tokens

Three critical OpenAM flaws, now with CVEs, allow session token theft, SAML bypass and admin escalation. No known exploitation; upgrade to 16.1.4.

Padlock graphic with the headline OpenAM flaws expose admin sessions

Three critical flaws in the open-source OpenAM access manager can hand an unauthenticated attacker a working administrator session, and they now carry CVE identifiers that vulnerability scanners will start flagging this week. The fix, OpenAM 16.1.4, has been out since 22 October, so any organisation still running an older build should treat this as an upgrade it is already late for.

What happened

On 22 October 2026 the OpenIdentityPlatform project released OpenAM 16.1.4 alongside three GitHub security advisories. On 8 November VulnCheck published the matching CVE records, which is the point at which scanners and patch dashboards that rely purely on CVE feeds can see the problem for the first time.

The three issues are:

  • CVE-2026-123551, rated CVSS 10.0: live session tokens can be read by an unauthenticated party through OpenAM’s notification WebSocket. It affects versions 14.0.0 to 16.1.3.
  • CVE-2026-123550, rated 9.8 by the vendor: in deployments where OpenAM is the SAML v2.0 service provider, assertions the identity provider never signed may be accepted on certain bindings.
  • CVE-2026-123549, also 9.8: the self-registration feature fails to enforce its list of permitted attributes, so an anonymous user can place themselves in an administrative group.

To be clear about the threat level: at the time of writing there is no known exploitation in the wild, no public proof-of-concept, and none of the three flaws appears in CISA’s Known Exploited Vulnerabilities (KEV) catalogue. Ostorlab’s 8 November analysis reported the same on all three points.

The technical picture

OpenAM is the community-maintained continuation of the ForgeRock OpenAM codebase, used to provide single sign-on, SAML federation and policy enforcement in front of other applications. Whoever controls that identity tier controls access to everything behind it.

The session token issue is the worst of the three. OpenAM pushes notifications to its policy agents over a WebSocket, and with agent notifications switched on, which is the default, full session identifiers travel on those topics. According to the vendor advisory, the agent-only authentication check on that WebSocket could be sidestepped via a legacy Liberty ID-FF endpoint, and a connected client could subscribe to any topic it liked. Ostorlab’s code review traces this to a filter mapped only to ordinary requests, so internal forwards skipped it. The result is that an outsider could quietly harvest bearer tokens for any user, administrators included, whose session started, changed or ended while they were listening. The advisory notes this would leave no failed logins or lockouts behind, and that a stolen administrator session could be turned into control of the configuration and, from there, commands running under OpenAM’s service account.

The SAML flaw comes down to inconsistent signature checking. OpenAM insisted on a signed response or signed assertions only on the HTTP-POST binding. For ECP (PAOS) and HTTP-Artifact, the only gate was the WantAssertionsSigned flag, which is false in the metadata OpenAM generates. The vendor lists three conditions that must all be true: ECP advertised (the default), that flag off (the default) and an encryption key configured on the service provider, which is an administrator decision rather than a default. Where those line up, a forged assertion naming a local account, potentially an administrator, could produce a valid session.

The self-registration bug only matters where that feature has been switched on; it is off by default. Where enabled, accounts were created using the server’s own administrative credentials without the attribute allowlist being applied, so group membership could be set by the person registering.

Version 16.1.4 closes all three paths, enforcing the WebSocket check on every dispatch, limiting subscriptions to agent topics, requiring signatures on all SAML bindings and applying the allowlist to registrations.

Timeline showing OpenAM fixes on 21 and 22 October 2026, CVE publication on 8 November, and current status of no known exploitation

Why it matters for UK organisations

There is no public figure for how many UK organisations run OpenAM. Ostorlab points to roughly 475,000 Docker Hub pulls of the official image, which suggests a meaningful install base worldwide. In my experience, ForgeRock-lineage single sign-on platforms are often deployed years ago, heavily customised and owned by a team that has since moved on.

Timing matters too. Many vulnerability management programmes in the UK key their service levels to CVE publication or scanner detection rather than to vendor advisories on GitHub. For more than two weeks, these flaws were effectively invisible to that process. Now the records exist, attention will rise on both sides, and the fix commits are public for anyone willing to compare versions.

An identity platform compromise is rarely contained. A hijacked administrator session in the SSO layer can reach payroll, customer records and cloud consoles in one step, which quickly becomes a question of personal data exposure under UK GDPR and, for operators of essential services, an incident reportable under the NIS Regulations.

Expert view

When we test single sign-on deployments, the identity provider is usually the best-protected box in the building, yet its legacy endpoints are often the least understood. Every flaw here sits in a feature many administrators would not recognise as live: old Liberty ID-FF handlers, a notification channel nobody configured by hand, a SAML binding that was advertised by default. That should worry anyone who inherited their access management stack.

Nobody should read “no known exploitation” as “low priority”. The token disclosure is passive and network-reachable in a default configuration, and the vendor itself scores it at the top of the scale. In my experience, quiet bugs that leave few traces are the ones discovered by incident responders months after the fact.

The upgrade is not entirely painless. The SAML change will reject partners who have been sending unsigned assertions, including some OpenAM-to-OpenAM federations over HTTP-Artifact, and customised web.xml files need new dispatcher entries. Test in staging, briefly.

What to do now

  1. Find every instance. Check asset registers and your external attack surface, including containers and forgotten test servers. The version endpoint will tell you what is running.
  2. Upgrade to 16.1.4 or later. This is the only complete fix. It maps directly to the Cyber Essentials security update management control, which expects critical fixes within 14 days of release; 22 October has already passed that mark.
  3. Prepare federation partners. Set WantAssertionsSigned to true and confirm identity providers sign their assertions before you switch over, so logins do not break.
  4. Apply interim controls if you cannot patch today. Use the reverse proxy to limit the notifications WebSocket to your policy agents, disable agent notifications if unused, block legacy ID-FF endpoints, remove unused ECP endpoints and disable self-registration. These align with the Cyber Essentials secure configuration and firewall controls, but none fixes the code.
  5. Look back as well as forward. Review audit logs for unexpected WebSocket connections, federation sessions without a matching identity provider login and self-registered accounts in privileged groups. Revoke active sessions after upgrading if anything looks odd.
  6. Check forks separately. The advisories cover OpenIdentityPlatform OpenAM only. If you run commercial ForgeRock AM or another fork, ask the vendor directly.

Bottom line

Nothing suggests these flaws are under attack today. But a maximum-severity, unauthenticated route to administrator sessions in an SSO platform, now freshly visible in CVE feeds with the fixes public, is the kind of finding that rarely stays theoretical for long. Patch to 16.1.4, tighten the legacy endpoints and check your logs.

Sources