Lightdash CVE-2026-72846

Exploitation requires an authenticated Lightdash user account with permission to create or trigger scheduled deliveries - the CVSS PR:L metric confirms that low-privilege access is sufficient and no administrative role is needed. The attacker must be able to supply or modify the webhook URL field for a scheduled delivery using either the Google Chat or Microsoft Teams integration path. No non-default server configuration is required; scheduled delivery is standard Lightdash functionality. Exploitation is inherently blind: the attacker cannot read the HTTP response body returned by the internal target (it is never relayed to the user); failure response bodies are written to server logs only. This means exploitation yields reachability intelligence (reachable vs. unreachable host distinction) and potential log-exposed data rather than direct full-response exfiltration. Impact is further bounded to the network reachability of the Lightdash backend process.

The CVSS 4.0 score of 5.3 (Medium) is consistent with the bounded exploitation model: PR:L requires an authenticated session, subsequent-system impact is rated SC:L/SI:L, and the Lightdash instance itself incurs no direct confidentiality, integrity, or availability impact (VC/VI/VA all N). Real-world risk is meaningful but conditional - exploitation demands a legitimate account with scheduled delivery permissions, which limits opportunistic mass exploitation. The blind nature of the SSRF further constrains what an attacker can extract: the response body of a successful internal request is not relayed, and failure bodies are written only to server logs. However, cloud-hosted Lightdash deployments face meaningfully elevated risk because the 169.254.169.254 metadata endpoint is reachable from most cloud VMs and can be used to enumerate instance credentials or IAM roles in insufficiently hardened environments. No EPSS data was included in the provided intelligence, and the absence of a KEV entry suggests exploitation has not been observed at measured scale - though teams running Lightdash in cloud environments or collocated with sensitive internal services should treat this as a near-term patch priority rather than a deferred item.

An authenticated Lightdash user with scheduled delivery permissions creates a delivery and sets the webhook URL to an internal address such as http://169.254.169.254/latest/meta-data/ or an internal microservice endpoint. When the delivery fires, the Lightdash backend issues an unvalidated POST to that address; by observing whether the server logs a connection failure versus an HTTP-level error, the attacker maps reachable internal services. In cloud environments, reaching the metadata endpoint without error can expose IAM role credentials or user-data payloads, enabling lateral movement. No public proof-of-concept has been identified, but the vulnerability class is well understood and requires only a low-privilege Lightdash session.