Finsys Dockhand CVE-2026-110256

Exploitation requires that Dockhand (≤1.0.18) is deployed with LDAP authentication enabled, since the flaw lives in the tryLdapAuth LDAP login path - deployments using non-LDAP auth are not affected. The specific prerequisite is that the login username is inserted into the LDAP search filter without escaping wildcard ('*') characters, and the attacker must be able to reach the /api/auth/login endpoint over the network without authentication (PR:N). The practical LIMITING factor is the timing side-channel (reflected as AT:P): the attacker must send many requests and statistically measure response-time differences to infer valid accounts, making exploitation slow, noisy, and sensitive to network jitter; the payoff is limited to username disclosure, not authentication bypass or code execution.

This is a genuinely low-to-moderate priority issue despite the 6.3 (medium) CVSS 4.0 score, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) confirms a network-reachable, unauthenticated flaw, but the impact metrics tell the real story: only VC:L with VI:N/VA:N/SC:N/SI:N/SA:N - a pure confidentiality-limited information-disclosure weakness (username enumeration), not code execution, data tampering, or denial of service despite the 'Code Injection' tag. The AT:P (Attack Requirement: Present) metric reflects that exploitation depends on a timing side-channel requiring repeated measured requests, which lowers reliability. No EPSS score, KEV listing, or public POC is present in the provided data: no public exploit identified at time of analysis, and there is no evidence of active exploitation. The net picture is a reconnaissance-only vulnerability that yields valid usernames (useful for follow-on password-spray/brute-force), not a direct compromise. Priority should be driven far more by the product's tiny deployment footprint than by the CVSS number. Missing data to note: EPSS and POC status are absent from the input and cannot be confirmed either way.

An unauthenticated attacker sends a series of login requests to /api/auth/login containing incremental wildcard usernames (e.g. 'a*', 'ab*') and measures server response timing to distinguish filters that match real LDAP accounts, building a list of valid usernames while the wildcards sidestep per-username rate limiting. The harvested usernames are then fed into downstream credential attacks such as password spraying. No public exploit is identified in the provided data, and the timing-measurement requirement (AT:P) makes exploitation noisy and somewhat unreliable.