Wekan’s header‑login feature uses a trusted‑IP allowlist to decide whether to accept the client‑supplied X‑Forwarded‑For header as the source address. Because the getRequestIp() function processed the X‑Forwarded‑For header before the real socket address, an unauthenticated attacker could send a spoofed header to trick the application into treating any arbitrary user ID as a local request. The attacker would then receive a valid meteor_login_token for that user, effectively authenticating without credentials. This authentication bypass (CWE‑287, CWE‑290) allows full control of any account, including super users.

All Wekan releases prior to version 9.46 are vulnerable. The issue is fixed in v9.46 and later. The affected product is the open‑source Kanban application Wekan, governed by the wekan:wekan CNA designation.

The CVSS score of 9.8 indicates critical severity, while the EPSS score of under 1 % suggests a low but non‑zero likelihood of real‑world exploitation at the time of analysis. The vulnerability is not listed in CISA’s KEV catalog. An attacker can trigger the header‑login flow from any external HTTP request capable of controlling the X‑Forwarded‑For header, supply the target username, and immediately obtain an active session token. No additional privileges or system access are required beyond the ability to send HTTP requests.