Lightdash vulnerabilities

Lightdash versions before 0.510.3 have insecure file endpoints that allow directory traversal and do not ensure that an intended file extension (.csv or .png) is used.

In Lightdash through 0.3213.0, the dbt Cloud webhook POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook has no authentication or signature validation. Unsanitized accountId and runId values are interpolated into the server-side dbt Cloud API URL, which is requested with the victim project's API key in the Authorization header.

The dbt Cloud webhook in Lightdash (POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook) has no authentication middleware or signature validation. The accountId and runId values from the request are interpolated into the server-side dbt Cloud API URL, enabling path traversal and a credential-bearing request using the victim project's API key.

Lightdash through 2.556.0 contains an authorization bypass vulnerability that allows authenticated organization members to delete other users' personal access tokens by supplying their UUID. Attackers can send DELETE requests to the personal-access-tokens route with a victim's token UUID, even across organizations, to revoke it and break API integrations.

Lightdash stores the webhook URL supplied with a scheduled delivery and later posts to it from sendWebhook in packages/backend/src/clients/GoogleChat/GoogleChatClient.ts and in packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts. In affected versions both call fetch on the stored URL directly. The validatePublicHttpUrl helper in packages/backend/src/utils/ssrfProtection.ts, used for MCP server URLs, is not applied on either path, and the webhook fields carry no server-side URL constraint. A user able to create or trigger a scheduled delivery can therefore direct the server to issue POST requests to private, loopback and link-local addresses, including cloud metadata endpoints, and can distinguish reachable internal services from unreachable ones through the resulting errors. The upstream response is never returned to the requester; on a failure status its body is written to the server log instead. Version 1.146.4 routes both clients through postSchedulerWebhook from packages/backend/src/utils/schedulerWebhookValidation rather than calling fetch directly.