Description

OpenAM before 16.1.3 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject script by supplying crafted parameters rendered unencoded on the OAuth2 authorization error page. Attackers can lure victims to a crafted /oauth2/authorize link with repeated parameters to run JavaScript in the OpenAM origin, acting within existing sessions or redirecting to phishing pages.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-10-03T14:16:37.963Z",
  "pubdate": "2026-10-03T14:16:37.963Z",
  "executiveSummary": "OpenAM versions prior to 16.1.3 are susceptible to a reflected cross-site scripting (XSS) vulnerability residing within the OAuth2 authorization error processing workflow.\nThe vulnerability allows an unauthenticated remote attacker to execute arbitrary JavaScript within the security context of the OpenAM origin by delivering a maliciously crafted URL to a victim.\nThis flaw arises from the failure of the application to properly sanitize or encode user-supplied parameters before rendering them on the OAuth2 authorization error page.\nSuccessful exploitation enables an attacker to compromise the integrity of the victim's session, perform unauthorized actions on behalf of the user, facilitate credential theft, or execute phishing attacks.\nBecause the attack occurs within the authenticated session context of the OpenAM platform, the risk to data confidentiality and session integrity is significant.\nExploitation requires no prior authentication, as the attacker leverages the public-facing OAuth2 authorization endpoint to inject the payload.",
  "technicalDetails": "The vulnerability is identified as a classic reflected XSS flaw located within the error handling logic of the OpenAM OAuth2 component. The root cause is the improper input validation and output encoding of HTTP request parameters processed by the /oauth2/authorize endpoint during error condition reporting.\nWhen an OAuth2 authorization request fails, the application generates an error page that reflects specific parameters submitted in the initial request. In affected versions, these parameters are rendered directly into the HTML document object model (DOM) without undergoing context-aware output encoding. By supplying repeated or maliciously formatted parameters, an attacker can manipulate the structure of the rendered error page to inject arbitrary JavaScript.\nThe attack flow begins when an attacker constructs a crafted URL targeting the OpenAM /oauth2/authorize endpoint. This URL includes malicious payload strings injected into vulnerable parameters. The attacker then lures an authenticated OpenAM user to click this link, typically through social engineering or embedded content.\nUpon clicking the link, the victim's browser sends the crafted request to the OpenAM server. The server, encountering an authorization error, triggers the rendering of the error page, reflecting the attacker-supplied malicious script. The browser parses this injected script, executing it within the origin of the OpenAM domain.\nBecause the script executes in the context of the OpenAM origin, it gains full access to cookies, session tokens, and local storage associated with that origin. This allows the attacker to exfiltrate sensitive session identifiers, hijack the user's active session, or modify the content of the page to present fraudulent forms for credential harvesting. Furthermore, the attacker can redirect the user to external malicious sites, effectively bypassing legitimate authentication workflows.\nThis vulnerability is particularly impactful because it does not require the attacker to have administrative privileges or pre-existing access to the platform. It relies entirely on the inherent trust placed in the error handling mechanism of the OAuth2 framework within OpenAM. As the reflected script acts within the session of the user who clicked the link, it can perform any action authorized to that specific user within the OpenAM environment."
}