Bulwark Webmail vulnerabilities

In Bulwark Webmail prior to 1.9.2, the unauthenticated POST /api/fetch-ical endpoint validates a caller-supplied hostname with one DNS lookup and then performs a separate lookup for the connection. An attacker controlling authoritative DNS can return a public address during validation and then rebind the hostname to a loopback, private, link-local, or cloud metadata address, causing the server to return up to 10 MB of an internal HTTP or HTTPS response.

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.

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.

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.

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.

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.