[BUG] TOCTOU DNS Rebinding Vulnerability in Webhook Dispatch #3169

Bug Description

The application allows outbound webhooks. To prevent Server-Side Request Forgery (SSRF), it checks isSafeUrl(), which performs a DNS lookup to ensure the IP isn't internal (e.g., 127.0.0.1, AWS Metadata 169.254.169.254). However, after passing the check, fetch(webhook.url) is called. This forces a second DNS resolution.

This introduces a classic Time-of-Check to Time-of-Use (TOCTOU) vulnerability. An attacker can set up a DNS server with an extremely low TTL. The first request (the check) returns a safe, public IP. The second request (the fetch) returns an internal IP (like 169.254.169.254). The attacker can then exfiltrate the serverless container's IAM roles, internal network topology, or hit internal databases.

Steps to Reproduce

1. Register an outbound webhook with a URL pointing to an attacker-controlled DNS server (e.g., http://rebind.attacker.com).
2. Configure the DNS server to return 8.8.8.8 on the first resolution, and 169.254.169.254 on the second resolution.
3. Trigger the webhook dispatch.
4. Observe that the SSRF check passes, but the subsequent fetch hits the internal AWS Metadata IP or local services.

Affected Area

API Routes

Screenshots

No response

Browser & OS

No response

Environment

Both

Additional Context

Suggested Fix:

1. Modify isSafeUrl to return the resolved, safe IP address instead of a boolean.
2. Pass this exact IP address directly to the fetch call.
3. Override the Host header in the fetch options to match the original URL's hostname so the target server processes it correctly, ensuring the IP used is explicitly pinned.