CVE-2026-55652: Wekan Authentication Bypass Vulnerability

CVE-2026-55652 Overview

Wekan is an open source kanban board application built with Meteor. Versions prior to 9.46 contain an authentication bypass in the header-login feature. The getRequestIp() function in server/lib/headerLoginAuth.js trusts the client-supplied X-Forwarded-For header before the real socket address when evaluating the HEADER_LOGIN_TRUSTED_IPS allowlist. An unauthenticated remote attacker can spoof a trusted proxy IP, submit an arbitrary HEADER_LOGIN_ID, and receive a valid meteor_login_token session for any account, including administrators. The issue, tracked as GHSA-jggc-qvfc-jr6x and dubbed ProxyBleed, is fixed in Wekan 9.46.

Critical Impact
Unauthenticated attackers can forge session tokens for any Wekan user, including admin accounts, leading to full application takeover.

Affected Products

Wekan versions prior to 9.46
Wekan deployments using HEADER_LOGIN_TRUSTED_IPS header-based authentication
Wekan instances deployed behind reverse proxies without strict X-Forwarded-For sanitization

Discovery Timeline

2026-07-15 - CVE-2026-55652 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-55652

Vulnerability Analysis

Wekan supports a header-based single sign-on flow gated by the HEADER_LOGIN_TRUSTED_IPS allowlist. The intent is to accept a HEADER_LOGIN_ID header only when the request originates from a trusted reverse proxy. The check is implemented in server/lib/headerLoginAuth.js using a helper named getRequestIp(). That helper returns the first value found in the X-Forwarded-For header before falling back to the true socket peer address. Because X-Forwarded-For is client-controllable, an attacker who can reach the Wekan HTTP endpoint directly can set the header to any address on the allowlist. Wekan then treats the request as if it came from a trusted proxy and issues a meteor_login_token for the username supplied in HEADER_LOGIN_ID. This maps to Improper Authentication [CWE-287].

Root Cause

The root cause is trust placement. The application derives the security-critical client IP from an HTTP header instead of the TCP socket. No verification confirms that the immediate upstream peer is itself a trusted proxy, so the allowlist check operates on attacker-controlled data.

Attack Vector

Exploitation requires network access to the Wekan HTTP listener and knowledge that header-login is enabled. The attacker sends a single HTTP request containing a spoofed X-Forwarded-For value matching an entry in HEADER_LOGIN_TRUSTED_IPS, along with HEADER_LOGIN_ID set to a target username such as admin. Wekan responds with a valid session token that grants full access to boards, cards, attachments, and administrative functions.

text

     HEADER_LOGIN_FIRSTNAME="" \
     HEADER_LOGIN_LASTNAME="" \
     HEADER_LOGIN_EMAIL="" \
+    HEADER_LOGIN_TRUSTED_IPS="" \
+    HEADER_LOGIN_TRUSTED_PROXIES="" \
     LOGOUT_WITH_TIMER=false \
     LOGOUT_IN="" \
     LOGOUT_ON_HOURS="" \

Source: Wekan patch commit b181889. The patch introduces HEADER_LOGIN_TRUSTED_PROXIES so the socket peer must belong to a trusted proxy set before any X-Forwarded-For value is honored.

Detection Methods for CVE-2026-55652

Indicators of Compromise

HTTP requests to Wekan containing both HEADER_LOGIN_ID and a client-supplied X-Forwarded-For header from untrusted network segments.
Successful issuance of meteor_login_token values for administrative accounts without a preceding interactive login flow.
New or unexpected sessions for admin users originating from IPs that do not match your reverse proxy topology.
Board, user, or permission changes performed shortly after anomalous session creation events.

Detection Strategies

Inspect reverse proxy and Wekan access logs for requests carrying HEADER_LOGIN_ID where the true peer IP is not a known proxy.
Alert on X-Forwarded-For values inside your allowlisted proxy range that arrive at the Wekan container from an external network hop.
Correlate Meteor session creation events with source IP metadata to surface tokens issued without a corresponding password or OAuth exchange.

Monitoring Recommendations

Enable verbose HTTP request logging on the Wekan front-end proxy, including all forwarding headers and the true source address.
Forward Wekan and proxy logs to a centralized analytics platform for correlation across authentication and administrative actions.
Baseline normal admin login sources and alert on deviations, especially token issuance outside business hours or from unusual ASNs.

How to Mitigate CVE-2026-55652

Immediate Actions Required

Upgrade Wekan to version 9.46 or later, which corrects the trust logic in headerLoginAuth.js.
If upgrade is not immediately possible, unset HEADER_LOGIN_TRUSTED_IPS to disable header-based authentication entirely.
Rotate all meteor_login_token sessions and force re-authentication for administrative users.
Audit user, board, and permission changes since header-login was enabled to identify unauthorized activity.

Patch Information

The fix is delivered in Wekan release v9.46 via commit b181889a565254bc9bf79379a34fc7f617ccda28. The patch introduces a new HEADER_LOGIN_TRUSTED_PROXIES variable that requires the actual TCP peer address to be a known proxy before any X-Forwarded-For value is evaluated against the login allowlist. Full advisory details are available in GHSA-jggc-qvfc-jr6x.

Workarounds

Terminate all client traffic at a reverse proxy that strips inbound X-Forwarded-For headers and rewrites them from the true peer address.
Bind the Wekan HTTP listener to a loopback or internal interface so it is unreachable except through the sanitizing proxy.
Enforce network-level ACLs that permit connections to the Wekan port only from the reverse proxy hosts.

bash

# Disable header-login until upgrade to 9.46
unset HEADER_LOGIN_ID
unset HEADER_LOGIN_TRUSTED_IPS

# After upgrade, define both variables to enforce socket-peer validation
export HEADER_LOGIN_TRUSTED_IPS="10.0.0.10,10.0.0.11"
export HEADER_LOGIN_TRUSTED_PROXIES="10.0.0.10,10.0.0.11"