CVE-2026-34834
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk17th percentile - higher than 17% of all known CVEs
Summary
Bulwark Webmail before version 1.4.10 has a vulnerability in verifyIdentity() that returned true when no session cookies were present. This allows unauthenticated attackers to bypass security and access the /api/settings endpoint, modifying user settings.
Risk Assessment
Unauthenticated attackers can alter user settings, potentially leading to account takeover or data leakage.
Recommendation
Upgrade Bulwark Webmail to version 1.4.10 or later.
Other vulnerabilities in Bulwark Webmail
See all- CVE-2026-35391High
In Bulwark Webmail before 1.4.11, the getClientIP() function trusts the first (leftmost) entry of the X-Forwarded-For header, which is fully controlled by the client. An attacker can forge their source IP to bypass IP-based rate limiting (enabling brute-force attacks on the admin login) or forge audit log entries.
- CVE-2026-35390Medium
Bulwark Webmail prior to version 1.4.11 sets the Content-Security-Policy-Report-Only header instead of the enforcing Content-Security-Policy header. This means XSS attacks are logged but not blocked, allowing arbitrary JavaScript execution via crafted email HTML.
- CVE-2026-35389High
In Bulwark Webmail prior to 1.4.11, S/MIME signature verification did not validate the certificate trust chain, so any email signed with a self-signed or untrusted certificate was displayed as having a valid signature.
- CVE-2026-34833High
Bulwark Webmail prior to version 1.4.10 exposed the user's plaintext password in the JSON response from the GET /api/auth/session endpoint. This exposed credentials to browser logs, local caches, and network proxies.
Original NVD description (English source)
Bulwark Webmail is a self-hosted webmail client for Stalwart Mail Server. Prior to version 1.4.10, the verifyIdentity() function contained logic that returned true if no session cookies were present. This allowed unauthenticated attackers to bypass security checks and access/modify user settings via the /api/settings endpoint by providing arbitrary headers. This issue has been patched in version 1.4.10.