WeKan CVE-2026-25560

The target WeKan instance must have LDAP authentication enabled (the wekan-ldap package configured with User_Search_Field, User_Authentication_Field/BaseDN, or a Default_Domain DN), and the WeKan login interface must be network-reachable to the attacker; the version must be prior to 8.19. No authentication, no user interaction, and no special client privileges are required (AV:N/AC:L/PR:N/UI:N), so default LDAP-enabled deployments are exposed. Exploitation is LIMITED to deployments that actually use LDAP - installations relying on local accounts or OAuth/OIDC are not affected - which is the primary factor narrowing real-world risk.

Signals are mixed and should be weighed carefully. The CVSS 4.0 base score of 8.7 (High) reflects a genuinely low barrier - network reachable, low complexity, no authentication, no user interaction - targeting the pre-authentication LDAP flow, which is why it rates high. However EPSS is only 0.05% (16th percentile), there is no CISA KEV listing, and no public exploit code has been identified, so there is no evidence of active or widespread exploitation; the risk is currently theoretical/targeted rather than mass-exploited. The vendor vector scopes impact to confidentiality only (VC:H, VI:N, VA:N), consistent with directory-query manipulation and potential information disclosure/authentication tampering rather than full system compromise. A notable caveat: exploitation is only relevant to deployments that actually enable LDAP authentication - installs using local accounts or OAuth/OIDC are unaffected, which materially narrows the real-world exposure below what the raw 8.7 implies. Overall this is a real pre-auth issue worth prioritizing for LDAP-integrated WeKan instances, but not an emergency for the general WeKan population.

An attacker reaches the WeKan login page of an LDAP-integrated instance and submits a username containing LDAP filter metacharacters (for example a wildcard or an injected sub-filter) instead of a normal account name. Because the input is concatenated unescaped into the LDAP search filter and DN, the crafted query alters the directory lookup, letting the attacker manipulate authentication logic or probe directory contents. No authenticated session or user interaction is required, and no public proof-of-concept has been published at time of analysis.