Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The OAuth2/OIDC consent page rendered for display=wap authorize requests reflected several request-derived values into the HTML response without escaping. An attacker who induces a user with an active OpenAM session to follow a crafted authorize link can execute arbitrary JavaScript in the OpenAM origin. This is the same vulnerability class as CVE-2026-44203; that fix did not cover this code path. Impact Arbitrary JavaScript execution in the OpenAM origin in the victim's authenticated context — enabling session/cookie theft, CSRF-token exfiltration, and actions on behalf of the victim, up to administrative takeover if the victim is an administrator. Reachable on any deployment with at least one registered OAuth2 client; no attacker-controlled client and no special configuration required. Mitigation - Upgrade to 16.1.2 (or later). - Until then, restrict/limit access to the OAuth2 authorize endpoint and treat unsolicited display=wap authorize links as untrusted.
Recommended action: Upgrade to 16.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description An Improper Authorization (CWE-285) issue in OpenAM's OAuth2 authorization-code grant allows a PKCE-protected authorization code to be redeemed without the required codeverifier. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1. The authorize endpoint stores a codechallenge on the issued code, but the token endpoint only requires a codeverifier when the realm-wide codeVerifierEnforced setting is enabled, which ships disabled by default. With that setting off, the stored challenge is checked only if the caller supplies a verifier, so omitting the parameter skips PKCE verification entirely. Impact OpenAM Community Edition deployments through version 16.0.6 using the default OAuth2 provider configuration are potentially affected. For public clients, an attacker who intercepts an authorization code can exchange it for tokens without knowing the verifier. For confidential clients, the attacker additionally needs client…
Recommended action: Upgrade to 16.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description An Improper Authentication (CWE-287) issue in OpenAM's OAuth2 private_key_jwt client authentication path allows any registered OAuth2 client to mint tokens in the name of any other client whose key is published via a jwks_uri, without knowing the victim's signing key. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1. Impact OpenAM Community Edition deployments through version 16.0.6 that have OAuth2 clients configured for private_key_jwt authentication with keys published via jwks_uri are potentially affected. An attacker holding any such client registration, their own, or one obtained through open dynamic client registration where enabled, can mint access tokens in any other such client's name, in any realm hosted by the OpenAM process. Patch This has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.
Recommended action: Upgrade to 16.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description An Authorization Bypass Through User-Controlled Key (CWE-639) exists in OpenAM's stateful OAuth2 token-read path. Under certain conditions, this may allow an attacker to forge OAuth2 bearer tokens and OIDC ID tokens with arbitrary subject, client, realm, and scope. This affects OpenAM Community Edition through version 16.0.6. The OAuth2 token-read path reads caller-supplied token identifiers from the shared Core Token Store (CTS) without placing them in an OAuth-only namespace and without binding the row's trusted CTS type to the expected OAuth token family, so any CTS row whose BLOB claims to be an OAuth token is accepted on the read path with no integrity check. Impact OpenAM Community Edition deployments through version 16.0.6 with the OAuth2 Provider service enabled in a realm are potentially affected, but the vulnerable read path is only reachable once an attacker can place attacker-controlled JSON into the shared CTS under an identifier they know.…
Recommended action: Upgrade to 16.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OAuth 2.0 / OpenID Connect authorization endpoint does not sufficiently sanitize certain user-supplied parameters before incorporating them into the HTML response generated for the `form_post` response mode. This may allow an attacker to inject content into the rendered page in the context of the OpenAM origin.
Recommended action: Upgrade to 16.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If the "claimsparametersupported" parameter is activated, it is possible through the "oidc-claims-extension.groovy" script, to inject the value of choice into a claim contained in the idtoken or in the userinfo. Authorization function requests do not prevent a claims parameter containing a JSON file to be injected. This JSON file allows users to customize claims returned by the "idtoken" and "userinfo" files. This allows for a very wide range of vulnerabilities depending on how clients use claims. For example, if some clients rely on an email field to identify a user, users can choose to entera any email address, and therefore assume any chosen identity.
Recommended action: Upgrade to 16.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenAM is an open access management solution. In versions 15.0.3 and prior, the getCustomLoginUrlTemplate method in RealmOAuth2ProviderSettings.java is vulnerable to template injection due to its usage of user input. Although the developer intended to implement a custom URL for handling login to override the default PingOne Advanced Identity Cloud login page,they did not restrict the CustomLoginUrlTemplate, allowing it to be set freely. Commit fcb8432aa77d5b2e147624fe954cb150c568e0b8 introduces TemplateClassResolver.SAFERRESOLVER to disable the resolution of commonly exploited classes in FreeMarker template injection. As of time of publication, this fix is expected to be part of version 15.0.4.
Recommended action: Upgrade to 15.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.