Yamcs Vulnerable to LDAP Injection in LdapAuthModule
Description
Summary
An LDAP injection vulnerability exists in org.yamcs.security.LdapAuthModule when constructing search filters. The username parameter is inserted directly into the LDAP filter without proper RFC 4515 escaping.
Root
Cause
File: yamcs-core/src/main/java/org/yamcs/security/LdapAuthModule.java:233
The username parameter is inserted directly into an LDAP search filter without RFC 4515 escaping:
// VULNERABLE
var filter = userFilter.replace("{0}", username);
var searchResult = getSingleResult(ctx, userBase, filter, controls);
LDAP wildcard characters (*, (, )) are accepted without sanitization.
Impact
With a known valid password, username=* authenticates as the first user returned by the LDAP search — enabling horizontal privilege escalation between accounts sharing similar passwords or when the attacker knows one valid password.
This affects deployments that use org.yamcs.security.LdapAuthModule in their etc/security.yaml configuration file.
Proof of
Concept
curl -X POST "http://TARGET:8090/auth/token" \
-d "grant_type=password&username=*&password=known_password"
# Returns token for first matching LDAP user
Fix
Apply RFC 4515 escaping before filter construction:
private static String escapeLdapFilter(String input) {
return input
.replace("\\", "\\5c")
.replace("*", "\\2a")
.replace("(", "\\28")
.replace(")", "\\29")
.replace("\0", "\\00");
}
var filter = userFilter.replace("{0}", escapeLdapFilter(username));
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An LDAP injection flaw in Yamcs LdapAuthModule lets an attacker with one valid password authenticate as other users by injecting wildcard characters.
Vulnerability
A LDAP injection vulnerability exists in org.yamcs.security.LdapAuthModule when constructing search filters in file yamcs-core/src/main/java/org/yamcs/security/LdapAuthModule.java:233. The username parameter is inserted directly into an LDAP search filter without proper RFC 4515 escaping, allowing LDAP wildcard characters (*, (, )) to be accepted without sanitization. This affects all deployments that use org.yamcs.security.LdapAuthModule in their etc/security.yaml configuration file prior to versions yamcs-5.12.7 and yamcs-5.13.0 [1][2][3].
Exploitation
An attacker only needs network access to the Yamcs authentication endpoint and one valid password for any user in the LDAP directory. By sending a POST request to /auth/token with grant_type=password&username=*&password=known_password, the injected wildcard character causes the LDAP search to return the first user matching the filter, and if that user's password matches the provided known_password, the attacker receives an authentication token for that user. No additional authentication or special privileges are required [2][3].
Impact
On success, the attacker gains a valid authentication token for a different user account—the first user returned by the LDAP search—enabling horizontal privilege escalation. The attacker can impersonate another user who shares the same password or for whom the attacker can guess a common password. This can lead to unauthorized access to telemetry, commands, or other mission-critical data managed by Yamcs, depending on the privileges of the impersonated account [2][3].
Mitigation
The vulnerability is fixed in Yamcs versions yamcs-5.12.7 [1] and yamcs-5.13.0 [4]. The fix applies RFC 4515 escaping to the username before inserting it into the LDAP filter. Users should upgrade to either fixed version. There is no workaround other than disabling LDAP authentication or restricting network access to the authentication endpoint until the upgrade can be applied [1][2][3][4].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing RFC 4515 escaping of the username parameter before insertion into an LDAP search filter allows LDAP wildcard characters to alter the filter's matching logic."
Attack vector
An attacker who knows a valid password for any LDAP-authenticated account can send a crafted HTTP POST request to the `/auth/token` endpoint with `username=*` and the known password [ref_id=1][ref_id=2]. Because the asterisk wildcard is not escaped, the LDAP search filter matches the first user in the directory, and if that user's password matches the supplied credential, the attacker receives a token for that user [ref_id=1][ref_id=2]. This enables horizontal privilege escalation between accounts that share similar passwords or when the attacker knows one valid password [ref_id=1][ref_id=2].
Affected code
The vulnerability is in `org.yamcs.security.LdapAuthModule` at line 233 of `yamcs-core/src/main/java/org/yamcs/security/LdapAuthModule.java` [ref_id=1][ref_id=2]. The `username` parameter is inserted directly into an LDAP search filter via `userFilter.replace("{0}", username)` without RFC 4515 escaping [ref_id=1][ref_id=2]. Deployments using this module in their `etc/security.yaml` configuration file are affected [ref_id=1][ref_id=2].
What the fix does
The fix introduces an `escapeLdapFilter` method that applies RFC 4515 escaping to the username before it is substituted into the filter template [ref_id=1][ref_id=2]. Characters `\`, `*`, `(`, `)`, and the null byte are replaced with their escaped hexadecimal representations (`\5c`, `\2a`, `\28`, `\29`, `\00`) [ref_id=1][ref_id=2]. This prevents LDAP wildcards and special characters from altering the filter's logic, ensuring the username is treated as a literal value in the search.
Preconditions
- configThe target deployment must use org.yamcs.security.LdapAuthModule in its etc/security.yaml configuration
- authThe attacker must know a valid password for at least one LDAP-authenticated account
- networkThe /auth/token endpoint must be network-accessible to the attacker
- inputThe attacker supplies a crafted username containing LDAP wildcard characters (e.g., *)
Reproduction
```bash curl -X POST "http://TARGET:8090/auth/token" \ -d "grant_type=password&username=*&password=known_password" # Returns token for first matching LDAP user ``` [ref_id=1][ref_id=2]
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.