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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Description An Improper Authorization (CWE-285) issue in OpenAM's Liberty Web Services SOAP receiver allows an unauthenticated remote attacker to write persistent entries into the Liberty Discovery store on any user's LDAP entry, and into a shared root-realm Discovery branch. This impacts OpenAM Community Edition through version 16.0.6. This issue was patched in version 16.1.1. Liberty ID-WSF is a legacy protocol superseded by SAML 2.0, OAuth, and OIDC, and deployments that intentionally leverage it assume the risks of an unmaintained federation stack. While Liberty is exposed in the shipped defaults, this bug does not require active Liberty consumers for the write itself. Downstream impact depends on whether anything consumes Discovery data. The endpoint accepts anonymous writes that are performed server-side by the Discovery handlers, bypassing the requester's LDAP and identity ACLs. The global Discovery path explicitly uses the internal admin token. Impact OpenAM Community…
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.
Certain federation endpoints do not consistently apply output encoding when rendering user-supplied parameters into HTML responses. Under a non-default configuration used in some clustered deployments, this inconsistency can result in reflected XSS in the OpenAM origin without authentication.
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.
Impact OpenAM up to version 14.7.2 does not properly validate the signature of SAML responses received as part of the SAMLv1.x Single Sign-On process. Attackers can use this fact to impersonate any OpenAM user, including the administrator, by sending a specially crafted SAML response to the SAMLPOSTProfileServlet servlet. Patches This problem has been patched in OpenAM 14.7.3-SNAPSHOT and later Workarounds One should comment servlet SAMLPOSTProfileServlet in web.xml or disable SAML in OpenAM References #624
Recommended action: Upgrade to 14.7.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.