CVE-2026-72846

This SSRF vulnerability in Lightdash's Google Chat and Microsoft Teams webhook integrations is notable less for what it allows and more for what it reveals about the development process. The same codebase contains `validatePublicHttpUrl` — a helper specifically designed to block SSRF — and it's already applied to the MCP server configuration path. Yet the two webhook clients bypass this protection entirely. Both are `fetch()` calls to user-supplied URLs. Both should require the same validation. The absence of that validation in two places, concurrent with its presence in a third, indicates the protection was bolted on reactively to one surface rather than established as a systemic requirement for any outbound HTTP call initiated by user input. The metadata endpoint exposure is the severity amplifier. Access to 169.254.169.254 isn't just information leakage — it's the gateway to cloud credential material that enables lateral movement to other AWS, GCP, or Azure services. Even though the upstream response body isn't returned to the requester, timing differences and error characteristics between reachable and unreachable internal services are sufficient for an attacker to map internal network topology. The response content also leaks into server logs, creating an additional exfiltration channel. Version 1.146.4 addresses this by routing both webhook clients through `postSchedulerWebhook`, which applies the validation. However, the structural problem persists: developers must remember to apply the helper manually. Unless the fix includes a linting rule, compile-time constraint, or a framework-level wrapper that makes unvalidated `fetch()` calls on user-supplied URLs impossible, this is likely the second instance of a recurring vulnerability class, not the last. Audit your codebase for other `fetch()` calls accepting user-supplied URLs — scheduled deliveries are a core workflow feature, so the population of users who can trigger outbound webhooks may be larger than expected. Prioritize any path that takes a user-provided URL and makes an outbound HTTP request. If `validatePublicHttpUrl` exists but isn't mandatory at the framework level, the next feature adding webhook-style functionality will face the same choice: remember to apply validation or skip it.

Reviewed through automated stages and approved by a human before publication.