Live › vulnerability › CVE-2026-113728
Go to dashboardBulwark Webmail's unauthenticated /api/fetch-ical endpoint checks a hostname with one DNS lookup, then fetches it with a second lookup, so an attacker's DNS can point the second lookup at loopback, private, or cloud metadata addresses. The attacker gets up to 10 MB of the internal HTTP or HTTPS response returned to them.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that self-host Bulwark Webmail as a front end for a Stalwart Mail Server are exposed when the instance is reachable from the internet and runs a version before 1.9.2. Because the flaw is in the unauthenticated iCal fetch endpoint, a login is not required. The sources also say the same check-then-fetch pattern existed in authenticated JMAP login and TOTP flows, so those paths are affected too in versions before 1.9.2.
No product ranges from the sources yet.
1.9.2.POST /api/fetch-ical to the internet.1.9.2 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-113728")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.