CVE-2026-113728 in Bulwark Webmail
Summary
by MITRE • 10/21/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Bulwark Webmail prior to version 1.9.2 represents a classic Server-Side Request Forgery (SSRF) flaw rooted in DNS rebinding techniques, specifically exploiting the check-then-fetch race condition inherent in how hostname validation is performed against actual network connections. As a self-hosted webmail client for the Stalwart Mail Server, Bulwark Webmail processes user-supplied URLs to fetch external resources such as calendar data via iCal feeds or other JMAP endpoints. The core technical flaw lies in the endpoint POST /api/fetch-ical and related authenticated flows like JMAP login and TOTP token exchange, where the application validates a caller-supplied hostname by performing an initial DNS lookup to ensure it does not resolve to private IP ranges. However, this validation occurs at a different point in time than the actual socket connection establishment. Because there is no persistent binding between the validated name and the subsequent network request, an attacker who controls authoritative DNS for the target domain can manipulate the resolution process. Specifically, the attacker configures their DNS server to return a public IP address during the initial validation phase, allowing it to pass the security check. Subsequently, before or as the application initiates the actual HTTP/HTTPS connection, the attacker changes the DNS record to point to a loopback address (127.0.0.1), private network range, link-local address, or cloud metadata endpoint (such as 169.254.169.254). This allows the server to bypass internal access controls and communicate directly with local services that are typically inaccessible from external networks.
The operational impact of this vulnerability is significant due to its ability to facilitate unauthorized data exfiltration from internal infrastructure without requiring authentication in the case of the iCal endpoint, or by leveraging valid credentials in authenticated flows. By exploiting DNS rebinding, an attacker can cause the Bulwark Webmail server to act as a proxy for requests directed at sensitive internal services. The vulnerability allows the retrieval of up to 10 MB of data from these internal responses, which may contain confidential information such as cloud instance metadata containing API keys and credentials, database connection strings, or other secrets stored in local configuration files. In authenticated scenarios involving JMAP login or TOTP token exchange, this flaw could potentially be leveraged for further lateral movement within the network by accessing internal administrative interfaces or extracting session tokens that facilitate deeper compromise of the mail server environment. The ability to read responses from cloud metadata services is particularly dangerous as it often provides a direct path to full account takeover in cloud-hosted deployments where Bulwark Webmail might be running on virtual machines with attached instance metadata roles.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically the variant involving DNS rebinding or SSRF via open redirect combined with host validation bypasses. It also maps to MITRE ATT&CK technique T1504 Web Service Discovery, as it enables attackers to probe and interact with internal web services that are not intended for external access. The specific mechanism of manipulating DNS records between a check phase and an execution phase is a well-documented attack vector often referred to as the "check-then-fetch" race condition or time-of-check-to-time-of-use (TOCTOU) vulnerability in network contexts. This pattern highlights the fundamental insecurity of relying solely on static hostname validation for SSRF prevention, especially when dealing with dynamic DNS resolutions that can change rapidly between request stages.
To mitigate this risk, organizations running Bulwark Webmail must immediately upgrade to version 1.9.2 or later, where the developers have addressed these flaws by implementing more robust URL parsing and connection handling logic that prevents DNS rebinding attacks. In addition to upgrading, administrators should enforce strict network segmentation policies ensuring that web-facing applications cannot directly access internal metadata endpoints or sensitive backend services via loopback interfaces unless absolutely necessary for functionality. Implementing egress filtering at the firewall level can also restrict outbound connections from application servers to only known and required external domains, thereby reducing the attack surface even if an SSRF vulnerability were present in future versions. Furthermore, avoiding direct user-controlled input in URL parameters that trigger server-side fetches is a critical architectural best practice; where such functionality is required, it should be sandboxed or proxied through a controlled intermediary that validates not just the hostname but also resolves and verifies IP addresses at connection time while blocking private ranges explicitly during socket creation.