CVE-2026-45049 in OpenAM
Summary
by MITRE • 10/29/2026
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the `Cross-Domain Single Sign-On` (`CDSSO`) servlet allows a logged-in user's raw OpenAM session token to be POSTed to an attacker-controlled URL. An attacker who induces an authenticated victim to visit a crafted URL can receive the session credential and potentially hijack the session. Deployments must have `CDSSO` enabled, as is common in multi-domain deployments, and exploitation is additionally gated on a non-default configuration being absent. This issue is fixed in version 16.1.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within Open Access Management versions prior to 16.1.1 centers on the improper handling of session credentials by the Cross-Domain Single Sign-On servlet, commonly referred to as CDSSO. This component is designed to facilitate authentication across multiple domains in complex enterprise environments where users must seamlessly access resources hosted on different subdomains or distinct domain names without re-authenticating. The core technical flaw lies in the mechanism used to transfer session tokens between these trusted and untrusted boundaries. Specifically, when a user initiates an action that triggers cross-domain authentication, the system constructs a POST request containing the raw OpenAM session token intended for the target identity provider or service provider. However, due to insufficient validation of the destination URL within this transmission process, the servlet fails to strictly enforce allow-lists against maliciously crafted endpoints. This oversight allows an attacker who can induce a logged-in victim to interact with a specially constructed link or form submission to redirect the sensitive session data out of the secure domain boundary and into a server controlled by the adversary.
From a technical perspective, this flaw represents a classic instance of insecure direct object reference combined with cross-site request forgery principles, though it is primarily categorized under improper validation of input parameters that dictate resource location. The vulnerability aligns closely with CWE-209, which describes the generation of an error message that includes sensitive information, and more accurately with CWE-352 regarding Cross-Site Request Forgery if viewed through the lens of inducing actions, but most critically it maps to CWE-614, Sensitive Cookie in HTTPS Session Without Secure Attribute, or broadly to CWE-798 for use of hardcoded credentials if one considers the token as a credential. In terms of the MITRE ATT&CK framework, this behavior facilitates Account Manipulation and Credential Access techniques, specifically allowing an adversary to steal session tokens from memory or network traffic without needing to crack passwords. The attacker does not need to exploit a buffer overflow or injection flaw; instead, they leverage the legitimate functionality of the CDSSO feature against itself by manipulating where that functionality sends its payload.
The operational impact of this vulnerability is severe because it leads directly to session hijacking and unauthorized access. An OpenAM session token acts as a bearer credential for all services integrated with that specific identity provider. Once an attacker captures the raw session token via their controlled URL, they can replay this token in subsequent HTTP requests to any service protected by the compromised OpenAM instance. This effectively bypasses authentication mechanisms entirely, granting the attacker full administrative or user-level privileges depending on the victim's role within the organization. The scope of damage is further amplified because CDSSO is frequently enabled in multi-domain deployments where trust relationships are established between various organizational units or partner organizations. If an internal employee with elevated privileges falls victim to this attack, the attacker gains a foothold that can be used for lateral movement across multiple systems and applications that rely on the same identity infrastructure.
Exploitation of this vulnerability requires specific conditions to be met simultaneously. First, the OpenAM deployment must have Cross-Domain Single Sign-On enabled, which is common in federated environments but not universal. Second, there must be a misconfiguration where the allowed redirect URLs or target domains are either left at default settings that might include wildcard patterns, or more likely, the system fails to validate the destination URL against a strict allow-list before transmitting the token. The attacker's role involves social engineering or web-based attacks such as cross-site scripting or phishing to induce an authenticated user to visit a crafted URL. This action triggers the browser to POST the session cookie data to the attacker’s server. Because modern browsers typically send cookies with requests, and if the CDSSO servlet is configured to accept this token for redirection without verifying its origin integrity properly, the leakage occurs silently in the background of normal authentication flows.
Mitigation strategies must address both immediate remediation and long-term architectural hardening. The primary and most effective mitigation is upgrading OpenAM to version 16.1.1 or later, where Oracle has patched this logic error by implementing stricter validation on the destination URLs for CDSSO requests. For organizations unable to upgrade immediately due to compatibility constraints with legacy applications, disabling Cross-Domain Single Sign-On entirely removes the attack vector but may break functionality in multi-domain setups. Alternatively, administrators can implement a Web Application Firewall rule that inspects outbound POST requests from the OpenAM server and blocks any transmission of session tokens or cookies to URLs not explicitly whitelisted as trusted partners. It is also critical to ensure that all CDSSO configurations strictly define allowed domains using exact matches rather than partial string matching to prevent bypasses via subdomain variations. Regular audits of identity provider trust relationships should be conducted to minimize the number of potential targets for such token leakage, ensuring that only necessary and verified endpoints are permitted in the cross-domain authentication flow.