LDAP injection is an attack that manipulates Lightweight Directory Access Protocol queries by inserting specially crafted characters into user-supplied input before it reaches a directory server. Applications that authenticate users, look up group memberships, or search employee records against services like Active Directory or OpenLDAP often build LDAP search filters by concatenating raw input into a query string. When that input isn't sanitized, an attacker can alter the filter's logic — turning a single-record lookup into a query that returns every entry in the directory, or forging a login filter that always evaluates to true. The result ranges from silent authentication bypass to full enumeration of usernames, group structures, and organizational data. LDAP injection is tracked as CWE-90 and falls under the OWASP Top 10's A03:2021-Injection category, which affected 94% of applications tested in OWASP's 2021 dataset and logged over 274,000 individual findings.
What Is LDAP Injection?
LDAP injection is a code-injection technique where an attacker inserts LDAP metacharacters — such as *, (, ), \, and NUL — into input fields that get embedded directly into an LDAP search filter. LDAP filters use a prefix notation like (&(uid=alice)(userPassword=secret)), and because the filter is built as a string, any unescaped special character an attacker controls changes how the directory server parses and evaluates the boolean logic. This is structurally identical to SQL injection, but instead of manipulating a SQL WHERE clause, the attacker is manipulating an LDAP filter's AND/OR/NOT operators. The vulnerability class was formally cataloged by OWASP in the early 2000s and remains listed in the OWASP Testing Guide and MITRE's CWE-90 entry today.
How Does an LDAP Injection Attack Work?
An LDAP injection attack works by injecting filter operators into a field the application never expects to contain them, changing what the directory server matches and returns. The textbook example is a login form that builds the filter (&(uid= + username + )(userPassword= + password + )). If an attacker submits *)(uid=*))(|(uid=* as the username, the resulting filter becomes malformed in a way that evaluates to true regardless of the password supplied, because the injected * wildcards and extra | (OR) clause short-circuit the intended AND logic. The same technique applies to search fields: injecting *)(mail=* into a "search by department" box can force the directory to return every user record instead of one department's roster, exposing usernames, phone numbers, and org-chart data that the application was never designed to disclose in bulk.
What Damage Can LDAP Injection Cause?
LDAP injection can cause authentication bypass, full directory enumeration, and in some configurations, unauthorized write access to directory attributes. Because LDAP directories frequently serve as the identity backbone for single sign-on, VPN access, and internal tooling, a successful injection against the login path doesn't just compromise one application — it can hand an attacker a valid session as any user whose distinguished name (DN) the attacker can guess or enumerate. Blind LDAP injection, where the application doesn't display query results directly but behaves differently based on true/false filter outcomes, lets attackers extract directory contents one boolean answer at a time, similar to blind SQL injection. In directories that allow write operations through the application layer, injected filters combined with modify requests have been used to alter group memberships, effectively granting privilege escalation without ever touching an access-control list.
Which Real-World Vulnerabilities Show LDAP Injection in Action?
Real-world LDAP injection vulnerabilities include CVE-2023-51446, disclosed February 1, 2024, in the GLPI IT asset management platform, where the authentication form failed to sanitize input before building the LDAP bind filter, allowing an attacker to manipulate the login query. The issue carried a CVSS score of 5.9, affected GLPI versions 0.70 and later, and was fixed in version 10.0.12 (GHSA-p995-jmfv-c7r8). It's a useful case study because it hit exactly the pattern OWASP describes: a login form, a concatenated filter, and no escaping of LDAP metacharacters in the username field. LDAP also shows up adjacent to one of the highest-severity vulnerabilities in recent memory: Log4Shell (CVE-2021-44228, disclosed December 10, 2021, CVSS 10.0). Log4Shell itself is a JNDI injection flaw, not classic LDAP injection, but its most common exploitation path had attackers point vulnerable JNDI lookups at attacker-controlled LDAP servers to serve malicious Java objects — a reminder that LDAP's role as a network protocol makes it a target both for direct filter injection and as a delivery mechanism in broader injection chains.
How Do You Prevent LDAP Injection?
You prevent LDAP injection primarily by escaping LDAP special characters in any user input before it's used in a filter, and by using parameterized or API-based query construction instead of string concatenation. Most modern LDAP client libraries — including Java's UnboundID SDK, .NET's System.DirectoryServices, and Python's ldap3 — provide filter-escaping functions (e.g., RFC 4515-compliant escaping of *, (, ), \, and NUL bytes) that should wrap every piece of user-controlled input before it's inserted into a filter string. Input allowlisting on fields like usernames (restricting to alphanumeric characters, for instance) adds a second layer of defense. Applying least-privilege bind accounts — so the credential the application uses to query LDAP can only read the attributes it actually needs — limits the blast radius if a filter is successfully manipulated. OWASP's LDAP Injection Prevention Cheat Sheet, maintained since the mid-2000s, remains the standard reference implementation guide for these controls.
How Is LDAP Injection Different From SQL Injection?
LDAP injection differs from SQL injection in the query language and data model being attacked, but shares the identical root cause of unsanitized input reaching a query interpreter. SQL injection manipulates relational query syntax (SELECT, WHERE, UNION) against a database, while LDAP injection manipulates hierarchical directory filter syntax (AND, OR, NOT operators in prefix notation) against a directory service. Both are classified under OWASP's consolidated A03:2021-Injection category and both are defeated by the same architectural principle — never build a query by concatenating untrusted strings — but the specific escaping functions, special characters, and client libraries differ entirely, which is why generic "input sanitization" guidance without protocol-specific escaping routinely misses LDAP-specific payloads during code review.
How Safeguard Helps
Safeguard helps security and engineering teams find and fix LDAP injection risk before it ships, rather than discovering it in a directory audit. Griffin AI reviews code paths that construct LDAP filters and flags string-concatenated queries built from user input, distinguishing genuinely exploitable patterns from filters built with safe, parameterized escaping. Reachability analysis confirms whether a vulnerable LDAP client library or filter-construction pattern is actually invoked from an internet-facing or authentication code path, so teams prioritize the login forms and directory-search endpoints attackers can actually reach instead of chasing every match. SBOM generation and ingest give teams visibility into which services embed LDAP client libraries — including transitive dependencies — across their portfolio, and Safeguard's auto-fix PRs can apply the correct escaping call or parameterized query pattern directly, turning a finding into a merge-ready fix.