Lightdash Scheduled Webhook SSRF via Unvalidated Delivery URLs
First seen Aug 21, 2026 · Updated Aug 21, 2026 · CVSS 6.4
Lightdash's scheduled delivery feature lets a user-supplied webhook URL be posted to directly by the GoogleChat and MicrosoftTeams clients without applying the existing SSRF protection used for MCP server URLs. This allows an authenticated user to force the server to make requests to internal, loopback, or cloud metadata endpoints and infer reachability from logged error responses. It is a classic SSRF issue in a webhook delivery path rather than an attack on agent reasoning or an AI-specific exploit, though it touches the same URL-validation utility used to secure MCP server connections.
Technical Analysis
The vulnerability stems from inconsistent application of the validatePublicHttpUrl helper: it is enforced for MCP server URL configuration but omitted from the sendWebhook code paths in GoogleChatClient.ts and MicrosoftTeamsClient.ts, which call fetch directly on a stored, user-controlled webhook URL. An attacker who can create or trigger a scheduled delivery supplies a URL pointing to private IP ranges, link-local addresses, or cloud metadata services (e.g., 169.254.169.254), and the backend server performs the outbound POST on their behalf. Although the response body is not returned to the requester, differences in logged failure behavior (timeout vs. connection refused vs. success) let an attacker perform blind SSRF-based internal network reconnaissance and potentially interact with metadata services to harvest cloud credentials. The fix in 1.146.4 routes both clients through postSchedulerWebhook, presumably applying the same validation used for MCP URLs, closing the inconsistency between trusted and untrusted URL-accepting code paths.
Affected Systems
Lightdash; protocols: MCP
Detection Signatures
- Outbound fetch/POST requests from Lightdash backend to RFC1918, 127.0.0.0/8, 169.254.0.0/16, or cloud metadata IPs (169.254.169.254, metadata.google.internal)
- Webhook URL fields containing internal hostnames or IP literals instead of expected external chat service domains
- Server logs showing repeated scheduled-delivery webhook failures correlated with probing of varied internal addresses
- Requests to GoogleChatClient/MicrosoftTeamsClient sendWebhook endpoints with anomalous non-Google/non-Microsoft target URLs
Remediation Steps
- 1
Upgrade Lightdash
Update to version 1.146.4 or later, which routes GoogleChat and MicrosoftTeams webhook delivery through postSchedulerWebhook with proper URL validation.
- 2
Enforce consistent SSRF validation
Ensure validatePublicHttpUrl (or equivalent) is applied uniformly to all user-supplied outbound URL fields, including webhook, MCP server, and any future integration URLs.
- 3
Network egress controls
Restrict the application server's outbound network access via firewall rules or a proxy allow-list so it cannot reach private IP ranges or cloud metadata endpoints regardless of application-layer validation.
- 4
Limit scheduled delivery creation privileges
Restrict which users/roles can create or trigger scheduled deliveries to reduce the pool of potential attackers.
- 5
Sanitize and rate-limit logging
Avoid logging full response bodies from webhook failures and rate-limit delivery attempts to reduce the value of error-based internal reconnaissance.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.