CVE-2026-110256 in Dockhand
Summary
by MITRE • 10/14/2026
Finsys Dockhand through 1.0.18 contains an LDAP injection vulnerability in the tryLdapAuth function in src/lib/server/auth.ts, which inserts the login username into the LDAP search filter without escaping wildcard characters. Unauthenticated attackers can submit incremental wildcard patterns such as 'a*' to /api/auth/login and measure response timing to enumerate valid LDAP usernames while evading per-username rate limiting.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Finsys Dockhand versions through 1.0.18 represents a critical authentication bypass mechanism rooted in improper input validation within the Lightweight Directory Access Protocol (LDAP) integration layer. Specifically, the flaw resides in the tryLdapAuth function located in the source file src/lib/server/auth.ts. This component is responsible for validating user credentials against an external LDAP directory service to authenticate users attempting to access the application. The core technical deficiency involves the direct concatenation of the login username provided by the client into an LDAP search filter without performing necessary sanitization or escaping of special characters, particularly wildcards such as the asterisk symbol. In standard LDAP query syntax, the wildcard character allows for pattern matching rather than exact string comparison, a feature that is typically intended for administrative discovery tasks but becomes dangerous when exposed to unauthenticated user input during the authentication process.
From an operational perspective, this architectural flaw enables unauthenticated attackers to perform efficient username enumeration attacks against the backend directory service. By submitting incremental wildcard patterns such as 'a' or '@domain.com' into the /api/auth/login endpoint, an attacker can exploit the variance in server response times associated with LDAP search operations. When a submitted pattern matches existing entries in the directory, the resulting query may return results more quickly than when no match is found due to differences in network latency and processing overhead. This timing side-channel allows attackers to iteratively guess valid usernames by observing these subtle performance discrepancies. Crucially, this method effectively circumvents per-username rate limiting mechanisms that are typically deployed to prevent brute-force attacks on specific accounts. Because the attacker does not target a single static username but rather shifts across multiple potential matches using wildcard patterns, traditional countermeasures designed to lock out or throttle individual identities fail to detect or mitigate the enumeration activity.
The impact of this vulnerability extends beyond simple information disclosure. Successful exploitation allows adversaries to build an accurate map of valid user accounts within the organization's LDAP directory. This intelligence is often a precursor to more severe attacks, including targeted credential stuffing, phishing campaigns tailored to specific individuals identified through enumeration, and eventual privilege escalation if weak credentials are discovered for high-privilege accounts. The ability to bypass rate limiting significantly reduces the time required to gather this data, increasing the likelihood of successful subsequent exploitation attempts. This behavior aligns with CWE-90, which classifies improper neutralization of special elements used in an LDAP query as a code injection vulnerability, and maps directly to MITRE ATT&CK technique T1087.002, known as Account Discovery: Local Account, where adversaries seek to identify valid accounts on the system or network to facilitate further lateral movement or access.
Mitigation strategies must address both the immediate technical flaw and broader authentication security postures. The primary remediation involves implementing strict input validation for all user-supplied data before it is incorporated into LDAP search filters. Developers should escape special characters, specifically wildcards like asterisks and question marks, using appropriate encoding functions provided by the underlying LDAP library or framework. Alternatively, if wildcard searches are not required for standard authentication flows, these features should be explicitly disabled in the query construction logic to prevent injection entirely. Additionally, implementing constant-time comparison mechanisms for response handling can help mitigate timing-based side-channel attacks, although input sanitization remains the most effective defense against this specific vector. Organizations running affected versions of Finsys Dockhand are strongly advised to upgrade to version 1.0.19 or later where these issues have been addressed. In environments where immediate patching is not feasible, deploying a Web Application Firewall with rules capable of detecting and blocking LDAP injection patterns in authentication endpoints can provide an interim layer of defense against exploitation attempts.