Act nowDisclosed

Advisory · CVE-2026-123550

OpenAM accepts unsigned SAML assertions, letting attackers log in as anyone

OpenAM before 16.1.4 accepts unsigned SAML assertions on the ECP (PAOS) and HTTP-Artifact bindings when WantAssertionsSigned is false, letting unauthenticated attackers forge assertions and obtain sessions as any mapped user including administrators, rated critical at CVSS 9.8; fixed in 16.1.4.

Vendor
OpenIdentityPlatform
Product
OpenAM
Identifier / CWE
CVE-2026-123550
CWE-290
Action timing
Immediate
ELI5

Explain it like I’m five

OpenAM is supposed to check the signature on login passes handed over by SAML. On two login paths it skips that check, so anyone can write their own pass saying they are the admin and walk in.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Attacker crafts an assertion

    A forged SAML assertion is written naming an administrator or any mapped user.

  2. 02Unsigned assertion submitted

    The assertion is sent via the ECP (PAOS) or HTTP-Artifact binding.

  3. 03Signature check skipped

    The SAML v2.0 service provider accepts the assertion because WantAssertionsSigned is false.

  4. 04Session issued

    OpenAM creates a session as the mapped user.

  5. 05Single sign-on hijacked

    The attacker reaches dependent applications as that user.

What happened

OpenAM before 16.1.4 contains an authentication bypass in its SAML v2.0 service provider. It accepts unsigned assertions on the ECP (PAOS) and HTTP-Artifact bindings when WantAssertionsSigned is false. Unauthenticated remote attackers can submit forged assertions to obtain sessions as any mapped user, including administrators, and hijack single sign-on to dependent applications. The record rates it critical at CVSS 9.8 under version 3.1, with network attack vector, low complexity, no privileges required, and no user interaction.

A forged assertion needs no credential, no victim interaction, and no prior access. The flaw is fixed in OpenAM 16.1.4.

What to do

  1. Inventory OpenAM deployments and record each version.
  2. Upgrade to OpenAM 16.1.4 or later.
  3. Until upgraded, review SAML service provider settings and confirm WantAssertionsSigned is enforced where the deployment allows it.
  4. Review authentication logs for SAML logins with unsigned assertions, especially for administrative accounts.
  5. Treat any session that cannot be accounted for as a compromise indicator and rotate the affected credentials.
  6. Verify the deployed version after updating.

Management note

Authentication that accepts its own homework is not authentication. Any SAML login that arrived unsigned is suspect until the logs say otherwise.