Quick Look: OpenAM CVE-2026-123550 SAML Authentication Bypass via Unsigned Assertions

Introduction

A SAML v2.0 service provider is supposed to trust an identity claim only because an identity provider vouched for it cryptographically. In OpenAM before 16.1.4, that guarantee did not hold on every binding. An unauthenticated attacker could submit a forged, unsigned assertion and walk away with a session as any mapped user, administrators included, plus SSO access to every application that relies on that OpenAM instance.

OpenAM is the access management product maintained by OpenIdentityPlatform. It provides authentication, authorization, single sign-on, federation, entitlements and web services security under the CDDL license. The project describes itself as an independent community continuation of the open source identity products underlying ForgeRock's commercial lineage, and positions itself as a free alternative with no per-user or per-server license fees and optional support from independent vendors. The sources we reviewed do not establish a market share or installed base, but OpenAM's role as an SSO hub means a trust failure there is inherited by every dependent application.

Technical Information

Root cause

The maintainer advisory (GHSA-3j2f-qhrc-rjfj) describes a failure to require cryptographic signatures on every binding through which OpenAM accepts SAML authentication responses. On some bindings, the only thing that made a service provider check signatures was its own hosted metadata flag, WantAssertionsSigned. OpenAM's generated hosted SP metadata sets that flag to false. An assertion reaching the assertion consumer service over ECP (PAOS) or HTTP Artifact could therefore be accepted even though the identity provider never signed it, and OpenAM would issue a session for whichever user the assertion named.

The CVE record classifies this as CWE-290, Authentication Bypass by Spoofing. The maintainer also associates the advisory with CWE-294 (Authentication Bypass by Capture replay) and CWE-347 (Improper Verification of Cryptographic Signature), which cover the broader signature and replay weaknesses fixed alongside it.

Three related but distinct failures

The advisory names three issues closed by the same fix:

1. Unsigned assertions over ECP/PAOS. This is the main bypass. It requires the hosted SP to advertise the ECP assertion consumer service, WantAssertionsSigned to be off, and an encryption key to be configured on the SP.
2. Unsigned assertions over HTTP Artifact. These were accepted when the artifact resolution service was reached over plain http.
3. Replay protection only on HTTP POST. The one-time-use check covered that binding alone, and the SAML v2.0 authentication module's assertion consumer had no replay check at all.

These are separate trust failures. Disabling the ECP endpoint, for example, does nothing for the HTTP Artifact or replay issues.

Exposure conditions

For the ECP case, two of the three prerequisites are generated defaults: the advertised ECP consumer and WantAssertionsSigned=false. The third, an encryption key, is an administrator choice. The advisory does not describe an untouched default installation as exploitable, so this is best described as conditional exposure with potentially extensive SSO consequences. Deployments that do not act as a SAML v2.0 service provider are not affected.

Attack flow

At the level the maintainer has disclosed, exploitation looks like this:

1. The attacker locates an OpenAM instance acting as a SAML v2.0 SP whose metadata advertises the ECP assertion consumer (the advisory names the path /Consumer/ECP/...), with WantAssertionsSigned off and an encryption key configured.
2. The attacker builds an assertion the identity provider never signed, naming a target identity. Reachable accounts depend on assertion mapping and may include accounts whose federation identifiers are known or guessable. Administrators are not excluded.
3. The attacker submits the forged assertion through the ECP (PAOS) path, or through HTTP Artifact where artifact resolution runs over plain http.
4. Because signature checks hinge on the SP's WantAssertionsSigned flag, the assertion is accepted and OpenAM issues a session for the named user.
5. The attacker uses that session to reach applications that rely on the OpenAM instance for SSO.

No credentials or user interaction are required. The advisory deliberately withholds the full request sequence, payload and fix commit, so none is reproduced here.

Severity and exploitation status

• CVSS 3.1: 9.8, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• CVSS 4.0 (VulnCheck): 9.3, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
• The NVD entry notes that its own assessment has not yet been provided, so the 9.8 is not an independent NIST score.

As of November 8, 2026, the reporting we reviewed shows no exploitation in the wild and no attributed threat actor. Threat Radar reports no CISA KEV listing and no public exploit indexed in Metasploit or Exploit DB. OpenCVE also marks KEV status as No. Those are catalog observations, not proof that no compromise has occurred.

Timeline:

• October 22, 2026: the maintainer advisory and the 16.1.4 release were both published.
• November 7, 2026: VulnCheck's advisory is dated this day.
• November 8, 2026: the CVE record was published.

Patch Information

Fixed version: OpenAM 16.1.4, released 22 October 2026. Every release up to and including 16.1.3 is affected. NVD and the VulnCheck CNA record map CVE-2026-123550 to GHSA-3j2f-qhrc-rjfj, which lists two patched Maven artifacts, both fixed in 16.1.4:

• org.openidentityplatform.openam:openam-federation-library (the SAML v2.0 service provider code)
• org.openidentityplatform.openam:openam-auth-saml2 (the SAML v2.0 authentication module)

The advisory's own CVE field is still empty. The CVE link comes from the NVD and VulnCheck records. The maintainers are holding back technical details and the fix commit to give operators time to upgrade, and no source diff appears in the sources we reviewed. The full changes sit in the 16.1.3...16.1.4 compare range. What follows is drawn from the advisory, the 16.1.4 release notes and the updated administration guide.

What 16.1.4 changes

• Signatures are required regardless of the metadata flag. The SP now rejects a response unless the response itself, or every assertion it carries, is signed. This holds on HTTP POST, ECP/PAOS and HTTP Artifact, whatever WantAssertionsSigned says. Rejections fail with assertionNotSigned.
• No exceptions on HTTP POST and ECP/PAOS. On these bindings the browser or ECP client hands over the response, so the attacker controls it. The admin guide explains that the signature is the only thing tying an assertion to its identity provider, which is why there is no opt-out here.
• Replay protection on every binding. One-time use of each assertion is enforced on all bindings, including the SAML v2.0 authentication module's assertion consumer.
• Artifact responses must come from the IdP they were resolved against. Previously OpenAM only checked that the Issuer in an artifact-resolved response belonged to the circle of trust. Now it must be the IdP selected by the artifact's SourceID, and a mismatch is rejected with invalidIssuerInResponse. This stops one trusted IdP from answering a resolution in another IdP's name.

The narrow HTTP Artifact opt-out

For legacy identity providers that cannot sign artifact-delivered assertions, 16.1.4 allows unsigned assertions on HTTP Artifact only when the SP's assertion consumer service publishes the HTTP Artifact binding and wantArtifactResponseSigned is true, so the ArtifactResponse envelope itself is signed and verified. It is enabled per SP in extended metadata:

<Attribute name="wantArtifactResponseSigned">
<Value>true</Value>
</Attribute>

<Attribute name="allowUnsignedArtifactAssertions">
<Value>true</Value>
</Attribute>

The opt-out fails closed:

• Only the literal value true enables it. TRUE, yes or a typo leaves signatures required.
• An empty attribute inherits the server-wide default openam.saml.sp.artifact.allow.unsigned.assertions, which is false.
• The wantArtifactResponseSigned check runs before the server-wide property is read, so the default cannot relax anything on its own.

The guide warns to use this only for an IdP you would trust with the identities of every other IdP in the same circle of trust.

Upgrade impact

This is a strict behavior change and can break federations that previously worked:

• Default HTTP Artifact setups. An OpenAM IdP signs artifact-delivered assertions only when the SP metadata sets WantAssertionsSigned="true", which generated metadata does not. Two OpenAM servers, or an OpenAM IdP and a Fedlet, federated over HTTP Artifact with default settings will start failing with assertionNotSigned. Set WantAssertionsSigned="true" in the SP metadata, including the IdP's copy of it, before upgrading.
• Proxy IdPs. An identity provider that answers artifact resolutions on behalf of another entity will now fail the new issuer check.

Interim controls if you cannot upgrade yet

From the maintainer's workaround guidance:

• Enable Assertions Signed at Federation > Entity Providers > SP Name > Assertion Content > Request/Response Signing, or set WantAssertionsSigned="true", after confirming trusted IdPs actually sign assertions.
• If ECP is unused, remove the ECP consumer from hosted SP metadata and block /Consumer/ECP/... at the reverse proxy.
• If encrypted assertions are unnecessary, do not configure an encryption key.
• Use HTTPS for every artifact resolution service.

None of these replaces the replay fix, which only 16.1.4 provides.

Detection Methods

This attack runs through the normal SSO flow, so there is no crash, web shell or obvious malicious payload. The evidence is a federation login that should not have happened. We found no public YARA, Sigma or Suricata rules and no atomic IoCs (IPs, hashes, domains) for this CVE, so detection rests on exposure checks and OpenAM's own SAML2 logs.

1. Identify exposed instances

A hosted SAML v2.0 SP is affected by the ECP issue only when all three are true: its metadata advertises the ECP (PAOS) assertion consumer service (generated default), WantAssertionsSigned is off (generated default), and an encryption key is configured. Check every hosted SP's standard metadata and the Request/Response Signing setting. Also look for any artifact resolution service called over plain http, and any reliance on one-time-use checks outside HTTP POST. Instances that do not act as a SAML v2.0 SP can be ruled out.

2. Hunt ECP single sign-on, especially for privileged accounts

The vendor's guidance is to review audit logs for SAML v2.0 SSO through the ECP binding, especially for privileged accounts. The OpenAM log reference lists the events, which go to SAML2.access / SAML2.error (and SAML.access / SAML.error):

• SUCCESS_FED_SSO (SAML2-142): A federation login succeeded. It records the user id and NameID value, so look for unexpected accounts, admin users or NameIDs that do not match your IdP's usual format.
• RECEIVED_HTTP_REQUEST_ECP (SAML2-157): A request arrived from an ECP client, with SP entity ID and realm.
• CANNOT_INSTANTIATE_SOAP_MESSAGE_ECP (SAML2-151/153) and RECEIVE_SOAP_FAULT_ECP (SAML2-152): Malformed or failed ECP messages that can indicate probing.

The most useful hunt joins successful federation logins with ECP activity in the same time window. Where nobody legitimately uses ECP, which covers most browser-based SSO deployments, any ECP-delivered login deserves investigation, above all for a privileged account.

3. Watch the ECP endpoint at the edge

Reverse proxy, load balancer and WAF logs often outlast application logs. Look for POSTs to /Consumer/ECP/..., particularly from sources that are not known ECP clients, and correlate them with SUCCESS_FED_SSO entries by timestamp.

4. Signature failure events

The log reference defines ECP_ASSERTION_NOT_SIGNED (SAML2-154), ECP_ASSERTION_INVALID_SIGNATURE (SAML2-155) and INVALID_SIGNATURE_ASSERTION (SAML2-95, which records the Assertion ID). On a vulnerable SP with WantAssertionsSigned=false, a forged unsigned assertion may be accepted rather than rejected, so these events probably will not appear for a successful attack. Their absence proves nothing. They become valuable after upgrading to 16.1.4 or enabling Assertions Signed, when a new assertionNotSigned rejection means either a partner that does not sign or someone still trying the attack. Tune out known partners and alert on the rest.

5. HTTP Artifact path

If an SP resolves artifacts over plain http, review RECEIVED_ARTIFACT (SAML2-9), GOT_RESPONSE_FROM_ARTIFACT (SAML2-15, which logs hosted SP, remote IdP and artifact value, and the full Response XML at LL_FINE), ARTIFACT_RESPONSE_INVALID_ISSUER (SAML2-23) and ARTIFACT_RESPONSE_INVALID_SIGNATURE (SAML2-21). After the fix, issuer mismatch events are worth a look. Raising SAML2 logging to LL_FINE retains the assertion XML so you can later verify whether a given login's assertion was signed.

Caveats: These are behavioral leads, not proof of compromise. Legitimate ECP clients, partners that do not sign, and configuration mistakes produce the same events. Follow any suspicious hit by reviewing the session's subsequent activity across applications that rely on that OpenAM instance.

Affected Systems and Versions

• Product: OpenIdentityPlatform OpenAM, all releases up to and including 16.1.3. Fixed in 16.1.4.
• Maven components: org.openidentityplatform.openam:openam-federation-library and org.openidentityplatform.openam:openam-auth-saml2, through 16.1.3.
• Role: Only deployments acting as a SAML v2.0 service provider.
• ECP/PAOS bypass configuration: ECP assertion consumer advertised in hosted SP metadata, WantAssertionsSigned false, and an encryption key configured.
• HTTP Artifact configuration: Artifact resolution service reached over plain http.
• Replay weakness: The SAML v2.0 authentication module's assertion consumer, and any binding other than HTTP POST.

This CVE concerns the OpenIdentityPlatform community project. Shared ancestry is not grounds for treating commercial ForgeRock products as affected.

Vendor Security History

The maintainers have published other advisories with identified fixes. These are separate issues, not additional exploit paths for CVE-2026-123550:

• jato.clientSession deserialization: Unauthenticated arbitrary command execution, affecting releases through 16.0.5, fixed in 16.0.6.
• CDSSO session hijacking: A logged-in user's raw session token could be sent to an attacker-controlled URL, affecting releases through 16.0.6, fixed in 16.1.1.

The CDSSO issue exposed an existing token, whereas this SAML flaw creates an unauthorized session from an untrusted assertion. The repository provides a vulnerability reporting channel, though the reviewed evidence does not establish typical remediation times.

References

• NVD: CVE-2026-123550
• CVE Record: CVE-2026-123550
• OpenAM maintainer advisory GHSA-3j2f-qhrc-rjfj
• GitHub API record for GHSA-3j2f-qhrc-rjfj
• VulnCheck advisory: OpenAM before 16.1.4 SAML authentication bypass
• OpenAM 16.1.4 release announcement
• GitHub release 16.1.4
• Compare 16.1.3 to 16.1.4
• OpenAM releases
• OpenAM administration guide: federation
• OpenAM reference: log messages
• OpenCVE entry
• Threat Radar entry
• VulDB entry
• OpenAM advisory: jato.clientSession deserialization
• OpenAM advisory: session hijacking via CDSSO
• OpenAM GitHub repository
• OpenAM security overview
• Open Identity Platform: OpenAM
• Open Identity Platform: ForgeRock alternative