Contents / ProxyBleed

CVE	Vulnerability name	Date	Responsible Security Disclosure by	Vulnerabilities
GHSA-jggc-qvfc-jr6x CVE requested	ProxyBleed	2026-06-15	rz1027 (coordinated disclosure) and Claude Did send detailed report with PoC!	1. ProxyBleed — header-login IP allowlist bypass via X-Forwarded-For spoofing CVSS: 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) Affected Wekan v9.44 and earlier Fixed at WeKan v9.46 release

Details

1. ProxyBleed — header-login IP allowlist bypass via X-Forwarded-For spoofing (CWE-290, CWE-287, CWE-348)

Wekan's header-login feature (reverse-proxy / SSO style passwordless login) lets a trusted front-end proxy authenticate a user by passing the username in a request header (e.g. X-Auth-User: admin). Because this mints a full login session with no password, it is gated on a source-IP allowlist, HEADER_LOGIN_TRUSTED_IPS, so that only requests coming from the trusted proxy are honored.

The vulnerability was that the source IP used for this allowlist check was taken from the client-supplied X-Forwarded-For request header rather than the real TCP connection. An unauthenticated attacker who can reach the Wekan app port directly therefore only had to send a single GET request with a forged X-Forwarded-For set to any allowlisted IP, plus the username header:

GET / HTTP/1.1
Host: wekan.example.com
X-Forwarded-For: 10.0.0.5        # any IP in HEADER_LOGIN_TRUSTED_IPS
X-Auth-User: admin               # any existing username, including admin

The allowlist check read the attacker-controlled X-Forwarded-For value, saw an allowlisted IP, and accepted the header login. Wekan then minted and returned a usable passwordless login session (a meteor_login_token) for the named user.

Impact: complete account takeover and admin impersonation. By setting X-Auth-User: admin (or any existing username), an unauthenticated attacker who can reach the app port obtained a full session for that account — no password, no credentials, a single request. An empty HEADER_LOGIN_TRUSTED_IPS allowlist also failed open, accepting header logins from anywhere.

Fix

The source IP is now derived from the real TCP socket peer (the immediate connecting client) instead of trusting X-Forwarded-For blindly. X-Forwarded-For is only honored when the immediate peer is itself a configured trusted proxy, in which case the right-most untrusted hop is used as the client IP. The allowlist now also fails closed: if HEADER_LOGIN_TRUSTED_IPS is unset or empty, header login is refused rather than accepted from anywhere.

Timeline	Details
2026-06-15	Report received from rz1027 (coordinated disclosure, GHSA-jggc-qvfc-jr6x, CVE requested).
v9.46 release	Fixed at WeKan v9.46 release, by deriving the header-login source IP from the real TCP socket peer, only honoring `X-Forwarded-For` from configured trusted proxies, and failing closed when the allowlist is unset.