CVE-2026-35391: Bulwarkmail Webmail Auth Bypass Flaw

CVE-2026-35391 Overview

CVE-2026-35391 is a high-severity vulnerability affecting Bulwark Webmail, a self-hosted webmail client for Stalwart Mail Server. Prior to version 1.4.11, the getClientIP() function in lib/admin/session.ts trusted the first (leftmost) entry of the X-Forwarded-For header, which is fully controlled by the client. This allows an attacker to forge their source IP address to bypass IP-based rate limiting (enabling brute-force attacks against the admin login) or forge audit log entries, making malicious activity appear to originate from arbitrary IP addresses.

Critical Impact

Attackers can bypass IP-based security controls including rate limiting and audit logging, enabling undetected brute-force attacks against admin credentials and forensic evasion through log manipulation.

Affected Products

• Bulwarkmail Webmail versions prior to 1.4.11
• Self-hosted deployments using Stalwart Mail Server with Bulwark Webmail
• Environments relying on IP-based rate limiting for admin login protection

Discovery Timeline

• 2026-04-06 - CVE-2026-35391 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-35391

Vulnerability Analysis

This vulnerability stems from improper validation of client-supplied header data (CWE-348: Use of Less Trusted Source). The getClientIP() function in lib/admin/session.ts parses the X-Forwarded-For HTTP header and trusts the first (leftmost) IP address entry without proper verification. In a properly configured reverse proxy environment, the rightmost entry typically contains the original client IP, while intermediate proxy addresses are appended. By trusting the leftmost entry, the application allows clients to inject arbitrary IP addresses that the server treats as authentic.

The X-Forwarded-For header is a de facto standard header for identifying the originating IP address of a client connecting through an HTTP proxy or load balancer. However, since this header can be arbitrarily set by the client before reaching any proxy, trusting client-controlled portions of this header introduces significant security risks.

Root Cause

The root cause is the improper trust placement in HTTP header parsing within the getClientIP() function. The function reads the X-Forwarded-For header and extracts the first comma-separated value without considering that this value is entirely client-controlled. Properly secured implementations should either use the rightmost untrusted address (when the proxy chain is known) or use a separate, proxy-set header that cannot be spoofed by clients.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by including a forged X-Forwarded-For header in their HTTP requests to the Bulwark Webmail application. This enables two primary attack scenarios:

1. Rate Limit Bypass: By rotating the spoofed IP address in each request, an attacker can circumvent IP-based rate limiting mechanisms designed to prevent brute-force attacks against the admin login interface.

2. Audit Log Manipulation: Malicious activities can be attributed to arbitrary IP addresses in audit logs, complicating forensic investigations and potentially implicating innocent parties.

The vulnerability is exploited by crafting HTTP requests with a malicious X-Forwarded-For header containing a spoofed IP address before the actual client IP. See the GitHub Security Advisory for complete technical details.

Detection Methods for CVE-2026-35391

Indicators of Compromise

• Audit logs showing login attempts or administrative actions from unexpected or impossible IP addresses (e.g., internal/reserved IP ranges from external sources)
• Unusual patterns in X-Forwarded-For header values in web server access logs
• High volumes of failed admin login attempts that don't trigger rate limiting alerts
• IP addresses in logs that don't correlate with known user locations or access patterns

Detection Strategies

• Implement web application firewall (WAF) rules to flag requests with suspicious X-Forwarded-For header patterns
• Monitor for unusually high numbers of unique source IPs accessing the admin login endpoint in short time periods
• Correlate web server logs with reverse proxy logs to identify X-Forwarded-For header manipulation
• Deploy SentinelOne Singularity to detect anomalous authentication patterns and potential brute-force activity

Monitoring Recommendations

• Enable verbose logging on reverse proxies to capture original client IPs before header manipulation
• Set up alerts for admin login attempts from IP ranges that should not have access
• Monitor authentication failure rates independent of reported client IP addresses
• Review audit logs for inconsistencies between reported IPs and expected geographic access patterns

How to Mitigate CVE-2026-35391

Immediate Actions Required

• Upgrade Bulwark Webmail to version 1.4.11 or later immediately
• Review audit logs for signs of exploitation, particularly anomalous IP addresses during the exposure window
• Implement network-level rate limiting at the reverse proxy or load balancer layer as a defense-in-depth measure
• Consider temporarily restricting admin login access to known IP ranges until patching is complete

Patch Information

The vulnerability has been addressed in Bulwark Webmail version 1.4.11. The fix ensures proper handling of the X-Forwarded-For header to prevent client-side IP address spoofing. Organizations should upgrade to this version or later to remediate the vulnerability. Detailed information is available in the GitHub Security Advisory.

Workarounds

• Configure the reverse proxy to strip or overwrite the X-Forwarded-For header before passing requests to Bulwark Webmail
• Implement additional rate limiting at the network infrastructure level (firewall, load balancer) that doesn't rely on application-parsed headers
• Deploy IP allowlisting for admin panel access at the reverse proxy or network layer
• Use alternative authentication mechanisms such as multi-factor authentication to reduce the impact of potential brute-force attacks

# Example nginx configuration to properly set X-Forwarded-For
# Add to your nginx proxy configuration
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;