CVE-2026-21881: 
NixOS vulnerability analysis and mitigation

CVE-2026-21881 is a critical authentication bypass vulnerability in Kanboard, an open-source project management application based on the Kanban methodology. When the REVERSE_PROXY_AUTH feature is enabled, the application blindly trusts user-supplied HTTP headers for authentication without verifying that the request originated from a legitimate, trusted reverse proxy. This allows an unauthenticated remote attacker to impersonate any user — including administrators — by simply injecting a spoofed HTTP header. All versions up to and including 1.2.48 are affected; the issue is fixed in version 1.2.49. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Feedly).

The root cause is classified as CWE-287 (Improper Authentication). In vulnerable versions, app/Auth/ReverseProxyAuth.php calls $this->request->getRemoteUser(), which reads the value of the HTTP header defined by REVERSE_PROXY_USER_HEADER (defaulting to REMOTE_USER, or HTTP_X_REMOTE_USER when using the X-Remote-User HTTP header) directly from the server variables without any IP-based source validation. Because no check is performed to confirm the request came from a trusted proxy IP, any client that can reach the Kanboard instance can set this header and be authenticated as the named user. If the specified username does not exist, Kanboard auto-creates the account, further expanding the attack surface. The fix in commit 7af6143 introduces a TRUSTED_PROXY_NETWORKS configuration option that enforces an IP-based allowlist before trusting any proxy-supplied headers (GitHub Advisory, Patch Commit).

A successful exploit grants the attacker full, unauthenticated access to any Kanboard user account, including the administrator. This results in high confidentiality impact (access to all projects, tasks, files, and user data) and high integrity impact (ability to create backdoor admin accounts, modify system configuration, alter or delete project data). Availability is not directly impacted by the vulnerability itself. The ability to auto-create new admin-level accounts enables persistent access even after the initial vulnerability is patched if not detected (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating exploitation with a single curl command. The attack requires no privileges, no user interaction, and is executable over the network with low complexity, making it trivially weaponizable. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation. The EPSS score is approximately 0.074% (0.000740), indicating a currently low but non-negligible probability of exploitation. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing or network-accessible Kanboard instances running version 1.2.48 or earlier. Tools like Shodan or Censys can be used to find exposed instances, or check for the Kanboard login page at common paths (e.g., /login).
2. Verify REVERSE_PROXY_AUTH is enabled: Attempt to access a protected page (e.g., /dashboard) without any authentication header. If the server returns an HTTP 302 redirect to /login, the instance may be vulnerable if REVERSE_PROXY_AUTH is enabled.
3. Identify the proxy header: Determine the configured REVERSE_PROXY_USER_HEADER. The default is HTTP_X_REMOTE_USER, corresponding to the HTTP header X-Remote-User.
4. Send spoofed authentication header: Issue an HTTP request with the spoofed header set to the target username (e.g., admin):

   curl -v -H "X-Remote-User: admin" http://<target>/dashboard

5. Confirm access: A successful bypass returns HTTP 200 with the admin dashboard content and sets a valid session cookie (KB_SID).
6. Escalate or persist: Use the admin session to create a new persistent backdoor admin account, exfiltrate project data, modify system settings, or impersonate other users by repeating the request with different usernames (GitHub Advisory).

• Network: HTTP requests to Kanboard endpoints (e.g., /dashboard, /?controller=ConfigController&action=index) containing X-Remote-User or REMOTE_USER headers originating from IP addresses that are not the configured reverse proxy.
• Logs: Kanboard access logs showing successful HTTP 200 responses to authenticated pages without a preceding login event; repeated requests with varying X-Remote-User header values from the same source IP.
• Application: Unexpected new user accounts created in Kanboard, particularly accounts with administrator privileges that were not provisioned through normal channels.
• Session: New KB_SID session cookies issued to IP addresses not associated with the legitimate reverse proxy infrastructure.
• Configuration: Review of config.php or environment variables showing REVERSE_PROXY_AUTH=true without a corresponding TRUSTED_PROXY_NETWORKS value set (GitHub Advisory).

The primary remediation is to upgrade Kanboard to version 1.2.49 or later, which introduces the mandatory TRUSTED_PROXY_NETWORKS configuration option. In v1.2.49, if REVERSE_PROXY_AUTH is enabled but TRUSTED_PROXY_NETWORKS is not configured, the application will throw an exception and refuse to start. If immediate patching is not possible, disable REVERSE_PROXY_AUTH entirely by setting define('REVERSE_PROXY_AUTH', false) in config.php. As an additional layer of defense, configure the upstream web server (Nginx or Apache) to strip any client-supplied X-Remote-User or REMOTE_USER headers before they reach Kanboard, ensuring only the web server's auth module can set them (GitHub Advisory, Release v1.2.49, Patch Commit).

The vulnerability received coverage from Heise (a major German technology publication) under the headline "Kanboard security vulnerability allows login as any user," indicating notable mainstream tech media attention (Heise). The Hacker Wire and INCIBE (Spain's national cybersecurity agency) also published alerts about the flaw. Social media discussion was observed on Mastodon and Bluesky, primarily from security news aggregators. Community reaction on GitHub was positive toward the fix, with several contributors reacting to the v1.2.49 release.