CVE-2026-113728: Bulwark Webmail: DNS-rebinding SSRF in public iCalendar fetch endpoint
Bulwark Webmail is a self-hosted webmail client for Stalwart Mail Server. Prior to 1.9.2, the unauthenticated POST /api/fetch-ical endpoint validates a caller-supplied hostname with one DNS lookup and then passes the URL to fetch, which performs a separate lookup for the socket 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 for the connection, causing the server to return up to 10 MB of an internal HTTP or HTTPS response. The same check-then-fetch pattern also existed in authenticated JMAP login and TOTP token-exchange flows. This issue is fixed in version 1.9.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Bulwark Webmailto a version that resolves this vulnerability.Fixed in 1.9.2
Event History
Frequently Asked Questions
Which deployments are exposed without an attacker account?
Deployments running versions before 1.9.2 expose the unauthenticated POST /api/fetch-ical endpoint. An unauthenticated remote attacker can use it to induce server-side requests to internal HTTP or HTTPS services.
What does an attacker need to exploit the issue?
The attacker needs control of authoritative DNS for a hostname they supply. They can return a public IP address during validation, then change the DNS result to a loopback, private, link-local, or cloud metadata address when the server connects.
What information could be exposed?
The affected endpoint can return up to 10 MB of an internal HTTP or HTTPS response. This may expose data reachable from the webmail server through loopback, private, link-local, or cloud metadata addresses.
Are authenticated features also affected?
Yes. The same check-then-fetch DNS pattern existed in authenticated JMAP login and TOTP token-exchange flows, so authenticated users could also reach the vulnerable request behavior.
What should teams do if they cannot patch immediately?
The provided data identifies version 1.9.2 as the fix. It does not provide a workaround or mitigation for earlier versions.