Description

Open Access Management (OpenAM) is an access management solution. From 13.0.0 until 16.1.2, the OAuth2 authorize endpoint's display=wap consent page reflects request-derived values through ConsentRequiredResource and wap/authorize.ftl without HTML escaping. An attacker can induce a user with an active OpenAM session to follow a crafted authorization link and execute JavaScript in the OpenAM origin, enabling session or cookie theft, CSRF-token disclosure, and actions with the victim's privileges. At least one registered OAuth2 client is required, but the attacker does not need to control that client. This issue is fixed in version 16.1.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-15T10:17:05.957Z",
  "pubdate": "2026-09-15T10:17:05.957Z",
  "executiveSummary": "Open Access Management (OpenAM) contains a Reflected Cross-Site Scripting (XSS) vulnerability within its OAuth2 authorize endpoint.\nThe vulnerability exists in the display=wap consent page, where request-derived parameters are reflected back to the user without sufficient HTML escaping.\nThe flaw allows an unauthenticated attacker to execute arbitrary JavaScript in the context of the victim's session within the OpenAM origin.\nSuccessful exploitation requires the victim to have an active OpenAM session and to be induced into clicking a maliciously crafted link.\nImpact includes session hijacking, cookie exfiltration, CSRF-token disclosure, and unauthorized actions performed with the victim's privileges.\nThe vulnerability affects OpenAM versions 13.0.0 through 16.1.2.\nWhile the attacker does not need to control a malicious OAuth2 client, at least one registered client must exist within the environment.",
  "technicalDetails": "The vulnerability originates from improper input sanitization in the OAuth2 authorize endpoint when utilizing the display=wap parameter.\nThe application processes request-derived values and renders them directly into the Document Object Model (DOM) through the ConsentRequiredResource class and the wap/authorize.ftl template without implementing robust HTML escaping mechanisms.\nThis behavior facilitates a Reflected XSS attack vector where malicious input passed in the URL parameters is interpreted as active content by the victim's browser.\nThe attack flow begins when an attacker crafts a malicious URI containing an XSS payload injected into a parameter processed by the affected consent page. The attacker must then entice an authenticated user—who currently possesses an active OpenAM session—to visit this link.\nUpon navigating to the crafted URL, the OpenAM server generates a response containing the unsanitized payload. The browser, trusting the origin of the server, executes the embedded script.\nBecause the script executes within the OpenAM origin, it gains full access to the Document object, including sensitive session identifiers, persistent cookies, and Cross-Site Request Forgery (CSRF) tokens. This effectively bypasses the Same-Origin Policy (SOP).\nPost-exploitation, the malicious script can silently exfiltrate session cookies to an attacker-controlled listener, perform arbitrary actions on behalf of the victim through asynchronous requests, or manipulate the UI to facilitate further credential harvesting.\nThe requirement of a registered OAuth2 client serves as a functional dependency for the endpoint's operation but does not mitigate the risk, as the attacker leverages existing infrastructure rather than needing to authorize a malicious client application.\nThis vulnerability persists across the range of versions 13.0.0 to 16.1.2 due to the consistent lack of contextual output encoding in the specified template files and server-side resource handling.\nThe lack of strict Content Security Policy (CSP) headers or robust input validation allows this reflection to be successfully converted into an actionable exploit."
}