CVE-2026-55652 in Wekan
Summary
by MITRE • 07/16/2026
Wekan is open source kanban built with Meteor. Prior to 9.46, header-login with HEADER_LOGIN_TRUSTED_IPS uses getRequestIp() in server/lib/headerLoginAuth.js to trust the client-supplied X-Forwarded-For header before the real socket address, allowing an unauthenticated attacker to send HEADER_LOGIN_ID for any username and receive a meteor_login_token session, including for admin. This issue is fixed in version 9.46.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability affects Wekan versions prior to 9.46 where the header login authentication mechanism fails to properly validate client IP addresses before trusting the X-Forwarded-For header. This flaw exists within the server/lib/headerLoginAuth.js file and specifically impacts the getRequestIp() function which processes incoming requests. The system incorrectly prioritizes client-supplied headers over actual socket connection information, creating a path for unauthorized access through manipulated HTTP headers.
This authentication bypass vulnerability stems from improper input validation and trust model implementation where the application assumes that X-Forwarded-For headers can be trusted without proper verification against legitimate source IP addresses. The flaw allows attackers to forge authentication requests by simply setting the HEADER_LOGIN_ID header to any desired username, including administrative accounts, while the system processes these requests as if they originated from a trusted source.
The operational impact of this vulnerability is severe as it enables unauthenticated attackers to obtain valid meteor_login_token session identifiers for any user account, including privileged administrator accounts. This creates a complete compromise scenario where attackers can gain unauthorized access to Wekan boards and perform administrative actions without proper authentication. The vulnerability essentially allows privilege escalation from guest level to full administrative control.
The technical implementation flaw aligns with CWE-284 Access Control Issues, specifically related to insufficient validation of trust relationships between components. This vulnerability also maps to ATT&CK technique T1078 Valid Accounts where attackers can leverage valid usernames to establish persistent access. Additionally, it represents a classic case of insecure header processing that could be classified under CWE-352 Cross-Site Request Forgery or CWE-295 Improper Certificate Validation depending on the deployment context.
Mitigation strategies include upgrading to Wekan version 9.46 or later where the fix has been implemented. Organizations should also implement proper IP address validation controls, ensure that X-Forwarded-For headers are properly verified against known trusted proxy servers, and consider implementing additional authentication layers such as multi-factor authentication. Network segmentation and firewall rules should restrict direct access to Wekan services to only trusted IP ranges while ensuring that header-based authentication is never the sole method of access control.
The fix implemented in version 9.46 addresses the core issue by modifying the getRequestIp() function to properly validate source IP addresses before trusting client-supplied headers, ensuring that authentication decisions are based on legitimate connection information rather than potentially forged header values. This remediation follows security best practices by implementing proper input sanitization and trust verification mechanisms that prevent header injection attacks and maintain proper authentication boundaries.