Summary
Bulwark Webmail contains a server-side request forgery vulnerability in its iCalendar fetch functionality. An unauthenticated attacker who controls authoritative DNS can exploit DNS rebinding to make the server request loopback, private, link-local, or cloud metadata addresses and return part of the internal response.
Bulwark Webmail contains a server-side request forgery vulnerability in its iCalendar fetch functionality. An unauthenticated attacker who controls authoritative DNS can exploit DNS rebinding to make the server request loopback, private, link-local, or cloud metadata addresses and return part of the internal response.
Affected context
The issue affects Bulwark Webmail deployments using the iCalendar fetch endpoint before version 1.9.2. The endpoint performs a DNS-based hostname validation and later resolves the hostname again when establishing the connection, creating a time-of-check/time-of-use gap. Similar check-then-fetch behavior was also present in authenticated JMAP login and TOTP token-exchange flows.
The issue affects Bulwark Webmail deployments using the iCalendar fetch endpoint before version 1.9.2. The endpoint performs a DNS-based hostname validation and later resolves the hostname again when establishing the connection, creating a time-of-check/time-of-use gap. Similar check-then-fetch behavior was also present in authenticated JMAP login and TOTP token-exchange flows.
Exploit preconditions
- Attack surface: The unauthenticated
POST /api/fetch-icalendpoint, with related authenticated JMAP flows - Required access: No authentication is required for the iCalendar fetch endpoint; authenticated access may be required for the related JMAP paths
- Trigger point: Server-side HTTP or HTTPS retrieval after hostname validation
- Why exploitation is possible: A DNS-controlled hostname can resolve to a public address during validation and then resolve to an internal address when the connection is created
- Attack surface: The unauthenticated
POST /api/fetch-icalendpoint, with related authenticated JMAP flows - Required access: No authentication is required for the iCalendar fetch endpoint; authenticated access may be required for the related JMAP paths
- Trigger point: Server-side HTTP or HTTPS retrieval after hostname validation
- Why exploitation is possible: A DNS-controlled hostname can resolve to a public address during validation and then resolve to an internal address when the connection is created
Why this happens
The vulnerability results from validating a user-influenced hostname through one DNS lookup and using the same hostname for a later network connection that performs a separate lookup. This check-then-use pattern allows DNS rebinding to change the destination between validation and request execution. The behavior maps to CWE-918: Server-Side Request Forgery, because the server can be induced to send requests to unintended internal destinations.
The vulnerability results from validating a user-influenced hostname through one DNS lookup and using the same hostname for a later network connection that performs a separate lookup. This check-then-use pattern allows DNS rebinding to change the destination between validation and request execution. The behavior maps to CWE-918: Server-Side Request Forgery, because the server can be induced to send requests to unintended internal destinations.
Potential impact
- An attacker may read up to 10 MB of internal HTTP or HTTPS response data
- Requests could reach loopback, private-network, link-local, or cloud metadata services
- Cloud instance credentials or sensitive service information could be disclosed
- Internal services could receive attacker-selected requests
- The webmail host could become a pivot point for additional network activity
- An attacker may read up to 10 MB of internal HTTP or HTTPS response data
- Requests could reach loopback, private-network, link-local, or cloud metadata services
- Cloud instance credentials or sensitive service information could be disclosed
- Internal services could receive attacker-selected requests
- The webmail host could become a pivot point for additional network activity
General mitigation guidance
Mitigation generally focuses on eliminating DNS-resolution races and reducing trust in user-supplied destinations.
Common defensive patterns include:
- Resolve hostnames once and bind validation to the exact destination used for the connection
- Revalidate resolved addresses immediately before and during connection establishment where supported
- Block loopback, private, link-local, reserved, and cloud metadata address ranges for outbound requests
- Prefer explicit destination allowlists over arbitrary URL fetching
- Restrict outbound network access at the application, container, and platform levels
- Apply authentication and authorization consistently to server-side fetch functionality
- Limit response size, redirects, protocols, and connection targets
- Run the service with only the network and filesystem privileges it requires
Mitigation generally focuses on eliminating DNS-resolution races and reducing trust in user-supplied destinations.
Common defensive patterns include:
- Resolve hostnames once and bind validation to the exact destination used for the connection
- Revalidate resolved addresses immediately before and during connection establishment where supported
- Block loopback, private, link-local, reserved, and cloud metadata address ranges for outbound requests
- Prefer explicit destination allowlists over arbitrary URL fetching
- Restrict outbound network access at the application, container, and platform levels
- Apply authentication and authorization consistently to server-side fetch functionality
- Limit response size, redirects, protocols, and connection targets
- Run the service with only the network and filesystem privileges it requires
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis rules identifying user-controlled URLs passed to HTTP clients
- Code review checks for separate hostname validation and connection resolution
- Searches for DNS lookups followed by later URL fetches without destination binding
- Tests using controlled DNS responses that change between validation and connection
- Egress monitoring for requests from the webmail service to private, link-local, loopback, or metadata addresses
- Network policies that alert on or block prohibited destination ranges
Automated security review tools may help identify unsafe URL-fetching patterns, but runtime egress monitoring is useful for detecting deployment-specific exposure.
Organizations can look for SSRF risks through:
- Static analysis rules identifying user-controlled URLs passed to HTTP clients
- Code review checks for separate hostname validation and connection resolution
- Searches for DNS lookups followed by later URL fetches without destination binding
- Tests using controlled DNS responses that change between validation and connection
- Egress monitoring for requests from the webmail service to private, link-local, loopback, or metadata addresses
- Network policies that alert on or block prohibited destination ranges
Automated security review tools may help identify unsafe URL-fetching patterns, but runtime egress monitoring is useful for detecting deployment-specific exposure.
