CVE-2025-27497: OpenDJ LDAP Directory Service DoS Flaw

CVE-2025-27497 Overview

CVE-2025-27497 is a denial-of-service (DoS) vulnerability in OpenDJ, an LDAPv3-compliant directory service maintained by Open Identity Platform. Versions prior to 4.9.3 contain a flaw that causes the server to become unresponsive to all Lightweight Directory Access Protocol (LDAP) requests without crashing or restarting. The condition triggers when an alias loop exists in the directory and an ldapsearch request is executed with alias dereferencing set to always against the looped alias entry. The server stops responding to all future requests until administrators restart it. Data corruption does not occur. The vendor fixed the issue in OpenDJ 4.9.3.

Critical Impact
An unauthenticated attacker with network access to the LDAP service can render the directory unresponsive to all clients with a single crafted search request, disrupting authentication and directory-dependent applications.

Affected Products

Open Identity Platform OpenDJ versions prior to 4.9.3
Applications and services relying on OpenDJ as their LDAP directory backend
Identity and access management workflows depending on OpenDJ for authentication

Discovery Timeline

2025-03-05 - CVE-2025-27497 published to the National Vulnerability Database
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-27497

Vulnerability Analysis

The flaw is classified under CWE-835 (Loop with Unreachable Exit Condition, or "Infinite Loop"). OpenDJ's local backend search operation does not track aliases it has already dereferenced during a single request. When the server encounters an alias entry whose target points back into the same chain, the dereferencing logic follows the references indefinitely. With alias dereferencing set to always, every search that touches the looped entry enters this state. The worker thread stops returning and never releases its slot, eventually starving the request pipeline so the server cannot process additional LDAP operations.

Root Cause

The defect resides in LocalBackendSearchOperation.java within the opendj-server-legacy module. The original implementation iteratively followed alias references without keeping a record of distinguished names (DNs) already visited during the dereference walk. A cyclic alias graph therefore produced an unbounded loop. The patch introduces a HashSet to record visited entries during dereferencing, allowing the server to detect a repeat visit and abort the operation safely.

Attack Vector

Exploitation requires network reachability to the LDAP port and the ability to issue a search request. Authentication is not required by the vulnerability itself; the attack succeeds whenever an attacker can submit a search with derefAliases=always against a directory containing an alias loop. An attacker who can write to the directory may first create the alias loop and then query it. In environments where alias loops can arise from misconfiguration, even a benign query may trigger the condition.

java

  *
  * Copyright 2008-2010 Sun Microsystems, Inc.
  * Portions Copyright 2011-2016 ForgeRock AS.
- * Portions Copyright 2024 3A Systems, LLC.
+ * Portions Copyright 2024-2025 3A Systems, LLC.
  */
 package org.opends.server.workflowelement.localbackend;

+import java.util.HashSet;
+import java.util.Set;
 import java.util.concurrent.atomic.AtomicBoolean;

 import org.forgerock.i18n.slf4j.LocalizedLogger;

Source: OpenDJ commit 08aee47. The patch adds a Set of visited DNs to LocalBackendSearchOperation so that the alias dereference loop terminates when a cycle is detected.

Detection Methods for CVE-2025-27497

Indicators of Compromise

OpenDJ instance becomes unresponsive to LDAP queries while the process remains running and consumes no abnormal disk or memory
Recent search operations in access logs containing derefAliases=always targeting alias entries
Worker threads in OpenDJ stuck in alias dereferencing call stacks captured via thread dumps

Detection Strategies

Inspect OpenDJ access logs for repeated SEARCH requests using derefAliases=always from a single source against alias entries
Audit the directory tree for alias entries whose aliasedObjectName attribute forms a cycle
Monitor LDAP service availability with synthetic probes that detect hangs distinct from connection refusals

Monitoring Recommendations

Alert when LDAP search latency exceeds a defined threshold or when responses time out while the OpenDJ process is still active
Capture JVM thread dumps on hang conditions and search for frames inside LocalBackendSearchOperation
Forward OpenDJ access and error logs to a centralized analytics platform for correlation across directory clients

How to Mitigate CVE-2025-27497

Immediate Actions Required

Upgrade OpenDJ to version 4.9.3 or later, which contains the cycle-detection fix
Audit the directory for alias entries that form loops and remove or correct them
Restrict network access to the LDAP and LDAPS ports to trusted clients and administrative networks
Restart any OpenDJ instance currently in a hung state; data integrity is preserved across restart

Patch Information

The fix is committed in OpenDJ commit 08aee47 and released in OpenDJ 4.9.3. The patch modifies opendj-server-legacy/src/main/java/org/opends/server/workflowelement/localbackend/LocalBackendSearchOperation.java to track previously dereferenced entries during a single search operation. See the OpenDJ GitHub Security Advisory GHSA-93qr-h8pr-4593 for the official notice.

Workarounds

Restrict write permissions on alias attributes so that untrusted accounts cannot create cyclic alias entries
Require clients to use derefAliases=never or derefAliases=finding until the upgrade is applied
Place the LDAP service behind an access control list that limits exposure to known directory clients

bash

# Verify the running OpenDJ version and upgrade to 4.9.3 or later
./bin/status --offline | grep -i version

# Search for alias entries that may form loops
ldapsearch -H ldap://opendj.example.com -D "cn=Directory Manager" -W \
  -b "dc=example,dc=com" "(objectClass=alias)" aliasedObjectName

# After review, upgrade using the vendor-provided upgrade tool
./upgrade --acceptLicense