Webmail EUVD-2026-19480

Bulwark Webmail versions prior to 1.4.11 deployed behind a proxy/load balancer that forwards X-Forwarded-For headers. Remote unauthenticated attacker forges X-Forwarded-For header to bypass IP-based rate limiting on admin login or manipulate audit logs. No victim interaction required.

The CVSS 4.0 score of 8.7 accurately reflects significant real-world risk due to the combination of network accessibility (AV:N), no authentication requirement (PR:N), low complexity (AC:L), and high integrity impact (VI:H). The attack requires no special privileges or user interaction, making it trivially exploitable. While EPSS data is not provided, the technical simplicity suggests high exploitability-attackers need only send crafted HTTP headers, a well-understood technique. No public exploit identified at time of analysis, and the vulnerability is not present in CISA KEV, indicating no confirmed active exploitation campaigns at this time. However, the authentication bypass tag and brute-force enablement make this a high-priority issue for any organization running vulnerable versions. The CVSS vector shows no confidentiality impact (VC:N) but high integrity impact (VI:H), correctly categorizing this as a security control bypass rather than data exfiltration risk. Real-world risk is elevated for internet-facing Bulwark Webmail admin interfaces, where IP-based rate limiting is a common brute-force defense. Organizations relying on IP allowlisting or geofencing for admin access are particularly vulnerable. The availability impact is rated None (VA:N), meaning this is not a denial-of-service vector but rather a persistent security control evasion.

An attacker targets a Bulwark Webmail admin login interface protected by IP-based rate limiting that blocks accounts after five failed login attempts per IP address. The attacker crafts HTTP requests with forged X-Forwarded-For headers containing different spoofed IP addresses for each login attempt (e.g., X-Forwarded-For: 192.0.2.1, then X-Forwarded-For: 192.0.2.2, etc.). Because the vulnerable getClientIP() function trusts the leftmost client-supplied value, each failed login appears to originate from a different IP address, completely bypassing rate limiting controls. The attacker can now conduct unlimited password guessing attacks against admin accounts while evading detection, and all malicious login attempts are logged with the forged IP addresses rather than the attacker's true source, frustrating incident response and forensic investigation.