CVE-2021-29156

What it actually does

ForgeRock OpenAM versions before 13.5.1 improperly validate attacker-controlled input passed through the WebFinger protocol into LDAP queries. Because the WebFinger endpoint is reachable without authentication and the issue has low attack complexity, an external attacker can inject LDAP filter syntax and manipulate directory lookups. The primary impact is confidentiality loss: attackers may be able to infer or retrieve sensitive directory-backed values such as password hashes, session tokens, or private keys, including through character-by-character extraction techniques.

Why it matters to the business

A vulnerable OpenAM deployment can expose authentication secrets from the identity platform without requiring a valid login. Compromise of password hashes, session tokens, or private keys can lead to account takeover, impersonation of users or services, broader access to dependent applications, and expensive incident response actions such as credential resets, token revocation, certificate/key rotation, and forensic review. Although this vulnerability is not listed in CISA KEV, its EPSS score is high, exploit maturity is weaponized, and it affects internet-facing identity infrastructure, so remediation should be treated as urgent.

How an attack unfolds

An attacker first identifies an exposed ForgeRock OpenAM service and confirms that the WebFinger endpoint is reachable. The attacker then sends crafted unauthenticated WebFinger requests containing LDAP metacharacters or encoded filter syntax in parameters that OpenAM uses to build LDAP queries. By observing differences in responses, status codes, timing, or returned data, the attacker can alter the LDAP query logic and iteratively extract sensitive values. In more damaging cases, the attacker uses the leaked material, such as a session token or private key, to impersonate users or services, access applications protected by OpenAM, or enable follow-on attacks against connected systems.

How to fix it

Upgrade ForgeRock OpenAM to version 13.5.1 or later. If the product is no longer supported in the environment, migrate to a supported ForgeRock/OpenIdentity platform release that contains the fix. Until upgrade is complete, restrict external access to OpenAM WebFinger endpoints where operationally feasible, require access through trusted reverse proxies or WAF controls, and block requests containing LDAP filter metacharacters in WebFinger parameters. Review and harden LDAP query construction, ensure server-side allow-list validation is enforced, and avoid exposing unnecessary identity discovery endpoints to the public internet. After remediation, rotate any secrets that may have been exposed, including session tokens, signing/encryption keys, service credentials, and affected user credentials where warranted by log evidence.

How to confirm the fix worked

Confirm the installed OpenAM version is 13.5.1 or later, or that a vendor-supported patched successor release is in place. From an unauthenticated network location, verify that WebFinger requests containing LDAP filter characters such as parentheses, asterisks, pipes, ampersands, or URL-encoded equivalents are rejected, normalized safely, or return a generic error without altering LDAP query behavior. Review reverse proxy, WAF, and application logs to ensure the vulnerable endpoint is not externally reachable if exposure has been intentionally restricted. Validate that compensating controls trigger alerts on suspicious WebFinger query strings and that no sensitive LDAP attributes are returned through discovery endpoints.

Typical attack path

1. Discover an internet-facing ForgeRock OpenAM instance.
2. Identify accessible WebFinger functionality, commonly under a .well-known/webfinger path or OpenAM OAuth/WebFinger route.
3. Send unauthenticated requests with LDAP filter metacharacters or URL-encoded LDAP syntax in WebFinger parameters.
4. Compare server responses to infer whether injected LDAP conditions are true or false.
5. Iteratively enumerate sensitive LDAP-backed values such as password hashes, session tokens, or private key material.
6. Use recovered secrets to impersonate users or services, bypass normal authentication, or pivot into applications relying on OpenAM.

How to detect it

To determine whether this was already exploited, review HTTP access logs, reverse-proxy logs, WAF logs, OpenAM debug logs, LDAP directory logs, and identity audit logs for unauthenticated requests to WebFinger endpoints with LDAP filter syntax in query parameters. Focus on requests to paths containing .well-known/webfinger or webfinger, especially where the resource or related parameters include parentheses, asterisks, boolean operators, escaped LDAP characters, or URL-encoded equivalents. Look for repeated requests from the same source that vary by one character or one encoded condition at a time, which may indicate blind character-by-character extraction. Correlate suspicious requests with LDAP bind/search activity, unusual directory attribute access, spikes in failed or malformed LDAP filters, unexpected successful authentications, token reuse from new locations, or changes in service-account behavior. If logs show attempts to retrieve or infer secrets, assume compromise of exposed tokens, keys, and credentials until proven otherwise.

• .well-known/webfinger
• /webfinger
• resource=
• %28
• %29
• %2a
• %2A
• %7c
• %7C
• %26
• %5c
• %5C
• objectClass=*
• userPassword
• sessionToken
• privateKey
• iPlanetDirectoryPro
• LDAP: error code
• InvalidSearchFilterException
• Malformed LDAP filter
• Unbalanced parenthesis
• (&(objectClass=*
• (|(objectClass=*

What your security team should do

• Prioritize patching or upgrading OpenAM before 13.5.1, especially for internet-facing identity services.
• Inventory all OpenAM deployments, including legacy, test, disaster recovery, and externally proxied instances.
• Search historical access logs for suspicious WebFinger requests containing LDAP metacharacters, URL-encoded filter syntax, or high-volume repeated probing of the same parameter.
• If exploitation is suspected, revoke active sessions, rotate affected keys and service credentials, and assess whether password hashes or tokens may have been exposed.
• Add WAF or reverse-proxy rules to block LDAP injection patterns in WebFinger parameters while upgrades are completed.
• Increase monitoring for abnormal authentication events, unexpected session reuse, and service-account activity following suspicious WebFinger traffic.
• Preserve relevant web, application, LDAP, proxy, and identity audit logs before rotation for forensic review.