CVE-2026-62280: OpenAM OAuth2 Endpoint XSS Vulnerability

CVE-2026-62280 Overview

Open Access Management (OpenAM) contains a reflected Cross-Site Scripting (XSS) vulnerability [CWE-79] in the OAuth2 authorize endpoint. The display=wap consent page reflects request-derived values through ConsentRequiredResource and wap/authorize.ftl without HTML escaping. Attackers can craft an authorization link that executes JavaScript in the OpenAM origin when a user with an active session follows it. Successful exploitation enables session theft, cookie theft, CSRF-token disclosure, and unauthorized actions with the victim's privileges. The vulnerability affects versions 13.0.0 through 16.1.1 and is fixed in version 16.1.2.

Critical Impact
An attacker with any registered OAuth2 client on the target OpenAM instance can execute arbitrary JavaScript in the OpenAM origin, hijacking authenticated sessions and performing actions on behalf of victims.

Affected Products

OpenAM 13.0.0 through 16.1.1
OpenIdentityPlatform OpenAM OAuth2/OIDC wap display consent flow
OpenAM deployments with at least one registered OAuth2 client

Discovery Timeline

2026-09-15 - CVE-2026-62280 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-62280

Vulnerability Analysis

The vulnerability resides in the OAuth2 authorize endpoint when invoked with the display=wap parameter. OpenAM renders the consent page using the wap/authorize.ftl FreeMarker template, populated by ConsentRequiredResource. Request-derived values, including scope descriptions supplied through OAuth2 client configuration, flow into the template without HTML escaping. An attacker can craft an authorization URL that embeds JavaScript payloads within these reflected fields. When a victim with an active OpenAM session clicks the link, the browser renders the consent page and executes the injected script in the OpenAM origin. The attacker does not need to control the referenced OAuth2 client, only to reference a registered client identifier.

Root Cause

The root cause is missing output encoding when constructing the JSON data model passed to the consent template. Scope names and related values were placed directly into JsonValue structures and rendered by the FreeMarker template without applying HTML entity encoding. The fix introduces encodeForHTML() calls around user-controllable fields before template rendering.

Attack Vector

Exploitation requires user interaction. The attacker delivers a crafted /oauth2/authorize?display=wap&... URL through phishing, forum posts, or malicious sites. Because the script executes in the OpenAM origin, it can read session cookies not marked HttpOnly, exfiltrate CSRF tokens, and issue authenticated requests to OpenAM administrative endpoints.

java

// Patch: openam-oauth2/src/main/java/org/forgerock/oauth2/restlet/ConsentRequiredResource.java
private void addDisplayScopesAndClaims(ResourceOwnerConsentRequired consentRequired, Map<String, Object> data) {
    JsonValue scopes = json(array());
    List<String> scopeNames = new ArrayList<>();
    Set<String> allScopeClaims = new HashSet<>();
    final Map<String, List<String>> compositeScopes = consentRequired.getClaims().getCompositeScopes();
    final Map<String, String> claimDescriptions = consentRequired.getClaimDescriptions();
    final Map<String, Object> claimValues = new LinkedHashMap<>(consentRequired.getClaims().getValues());

    for (Map.Entry<String, String> scope : consentRequired.getScopeDescriptions().entrySet()) {
        if (scope.getValue() != null) {
            scopeNames.add(scope.getValue());
        }
        // Fix: encodeForHTML() applied before JSON value construction
        JsonValue value = json(object(field("name", encodeForHTML(scope.getValue()))));
        scopes.add(value.getObject());
        List<String> scopeClaims = compositeScopes.get(scope.getKey());

Source: GitHub Commit 98cee2d

Detection Methods for CVE-2026-62280

Indicators of Compromise

Requests to /oauth2/authorize containing display=wap alongside encoded <script>, onerror=, or javascript: payloads in query parameters.
Unexpected outbound requests from browsers to attacker-controlled domains immediately after visiting an OpenAM consent page.
OpenAM audit log entries showing consent page rendering for OAuth2 clients with unusually long or HTML-laden scope descriptions.

Detection Strategies

Deploy Web Application Firewall (WAF) rules that inspect OAuth2 authorize parameters for HTML and script tokens.
Monitor OpenAM access logs for display=wap requests with abnormal parameter lengths or encoded angle brackets.
Correlate consent page rendering events with subsequent session activity from unexpected IP addresses.

Monitoring Recommendations

Enable full URI logging on OpenAM front-end proxies to preserve query strings for forensic review.
Alert on OAuth2 client registrations that include HTML characters in scope descriptions or display names.
Track session cookie reuse across geographically inconsistent client IPs following authorize endpoint hits.

How to Mitigate CVE-2026-62280

Immediate Actions Required

Upgrade OpenAM to version 16.1.2, which applies encodeForHTML() to reflected consent page fields.
Audit all registered OAuth2 clients for scope descriptions and display names containing HTML or script content.
Rotate OpenAM session and CSRF secrets after patching if exploitation is suspected.

Patch Information

The fix is available in OpenAM 16.1.2. The security advisory GHSA-vqxv-6xrh-49cp documents the issue, and the code change is published in GitHub Commit 98cee2d. Release artifacts are available on the OpenAM 16.1.2 Release page.

Workarounds

Block or restrict access to the /oauth2/authorize endpoint when the display=wap parameter is present until patching is complete.
Enforce a strict Content Security Policy (CSP) on the OpenAM origin to limit inline script execution.
Mark OpenAM session cookies as HttpOnly and Secure to reduce cookie theft impact from script execution.

bash

# Example nginx rule to block display=wap consent requests pre-patch
location /oauth2/authorize {
    if ($arg_display = "wap") {
        return 403;
    }
    proxy_pass http://openam_backend;
}