CVE-2026-105116 in OpenAM
Summary
by MITRE • 10/03/2026
OpenAM before 16.1.3 contains a latent cross-site scripting defect that places the SAML message, relay state and target URL unencoded into the load-balancer cookie bounce auto-submit page. If reachable with cookieHashRedirectEnabled set, crafted requests could execute script in the OpenAM origin, though an unrelated HTTP 500 failure prevents exploitation in released versions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in ForgeRock Access Manager (OpenAM) prior to version 16.1.3 represents a latent cross-site scripting flaw rooted in improper input validation and encoding mechanisms within the SAML authentication flow. Specifically, when the configuration parameter cookieHashRedirectEnabled is set to true, the application processes incoming SAML assertions by extracting critical components such as the SAML message payload, relay state data, and target URLs. Instead of applying strict output encoding before rendering these values into an HTML-based auto-submit page designed for load-balancer cookie bounce scenarios, OpenAM inserts them directly into the document object model without sanitization. This architectural oversight creates a vector where maliciously crafted HTTP requests can inject executable JavaScript code that executes within the security context of the trusted OpenAM origin domain.
From a technical perspective, this defect aligns with CWE-79, which classifies improper neutralization of input during web page generation as cross-site scripting. The vulnerability manifests specifically in the server-side rendering logic responsible for generating HTML forms that automatically submit data to downstream services or identity providers. Because the SAML message and relay state are user-controllable inputs derived from external authentication requests, an attacker can manipulate these fields to include script tags or event handlers such as onerror or onload attributes. When a victim interacts with a crafted link or is redirected through this flow while authenticated or in a session context, the browser interprets the injected content as legitimate code belonging to the OpenAM domain, thereby bypassing same-origin policy protections that typically isolate web applications from malicious scripts.
The operational impact of this vulnerability is significant despite its latent nature in released versions due to an unrelated HTTP 500 server error that currently blocks successful exploitation. This internal failure acts as a de facto mitigation by preventing the vulnerable page from rendering correctly, thus stopping the execution pipeline before the script can run. However, if the underlying cause of the HTTP 500 error is resolved or bypassed through alternative request structures, the latent XSS vulnerability becomes fully exploitable. Successful exploitation could allow an attacker to perform actions on behalf of authenticated users, steal session cookies containing sensitive authentication tokens, redirect users to phishing sites mimicking the OpenAM interface, or deface the administrative console if accessed by privileged accounts. This poses a severe risk to identity and access management infrastructure where trust in the origin domain is paramount for secure single sign-on operations.
In terms of threat modeling, this vulnerability maps to MITRE ATT&CK technique T1059, specifically command scripting via browser-based execution, often categorized under Initial Access or Credential Harvesting depending on the payload intent. Attackers could leverage this flaw in phishing campaigns where victims are tricked into clicking malicious links that trigger the vulnerable SAML flow. The presence of cookieHashRedirectEnabled suggests a complex load-balancing environment where session persistence and state management rely heavily on client-side interactions, increasing the attack surface for such injection attacks.
To mitigate this risk, organizations running OpenAM versions earlier than 16.1.3 should immediately apply the vendor-patched update which addresses the encoding deficiency in the auto-submit page generation logic. Until an upgrade is feasible, administrators can disable the cookieHashRedirectEnabled configuration option to prevent the vulnerable code path from being triggered during authentication flows. Additionally, implementing a Web Application Firewall with rules capable of detecting and blocking reflected XSS payloads containing script tags or common event handler attributes may provide a layer of defense in depth. It is also critical to ensure that Content Security Policy headers are configured to restrict inline script execution where possible, although this must be carefully balanced against the functional requirements of SAML-based single sign-on applications which often require dynamic form submissions and script execution for legitimate purposes. Regular security assessments should include testing for output encoding failures in all user-controlled data rendered into HTML contexts to prevent similar latent vulnerabilities from persisting in production environments.