CVE-2026-61576 in Lightdash
Summary
by MITRE • 10/29/2026
Lightdash is an open source business intelligence platform. In affected versions through 0.3213.0, the dbt Cloud webhook `POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook` has no authentication middleware or signature validation. In `packages/backend/src/controllers/projectController.ts`, `testWebhook()` accepts `accountId` and `runId` from a `job.run.completed` request and passes them to `createPreviewWithExplores()` in `packages/backend/src/services/ProjectService/ProjectService.ts`. These unsanitized 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. Path traversal through `accountId` changes the requested path on `cloud.getdbt.com` without changing its host, so the credential-bearing request reaches an attacker-influenced path on that fixed host. The advisory claims API-key theft, but the supplied evidence does not establish that the attacker can observe the `Authorization` header. The unauthenticated webhook also allows preview creation. The target must be a `dbt Cloud IDE` project and the attacker must know its `projectUuid`; the UUID is not enumerable but can be discovered in shared or multi-tenant contexts. Version 0.3214.0 fixes identifier path traversal and verifies webhook HMAC signatures only when a secret is configured; without a secret, unsigned webhooks continue to be processed.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/29/2026
Lightdash is an open-source business intelligence platform that integrates with dbt Cloud for data transformation workflows. A critical security vulnerability exists in versions through 0.3213.0 involving the unauthenticated webhook endpoint located at POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook. This endpoint lacks authentication middleware and signature validation, allowing any actor to trigger backend operations without proper authorization checks. The flaw resides within the project controller logic where the testWebhook function accepts parameters such as accountId and runId from incoming job.run.completed requests. These values are passed directly into a service method that constructs server-side API calls to dbt Cloud.
The technical core of this vulnerability is an insecure direct object reference combined with path traversal capabilities. The unsanitized accountId parameter is interpolated into the URL path for requests directed at cloud.getdbt.com. Although the host remains fixed, the attacker can manipulate the path component using directory traversal sequences in the accountId field. This allows the request to reach unintended endpoints on the dbt Cloud API surface while still utilizing the victim project's stored API key within the Authorization header of the outbound HTTP request. This mechanism effectively leverages the application as a proxy or blind server-side request forgery vector, where the application credentials are used against targets influenced by the attacker.
The operational impact centers on unauthorized access to dbt Cloud resources and potential data exfiltration if response bodies are returned to the client. While initial advisories suggested API key theft, technical analysis indicates that direct observation of the Authorization header is not guaranteed unless the server returns sensitive authentication details in its own responses or logs. However, the unauthenticated nature of the webhook also permits unauthorized preview creation within dbt Cloud IDE projects. This requires knowledge of a valid project UUID, which may be discoverable through shared dashboards, public links, or multi-tenant configurations where identifiers are exposed to broader audiences. The ability to trigger these operations can lead to resource exhaustion, unintended data processing, and potential exposure of sensitive dataset previews if the application echoes back response content from the dbt Cloud API.
This vulnerability aligns with CWE-284 Improper Access Control due to missing authentication checks on a critical function, as well as CWE-73 External Control of File Name or Path leading to path traversal issues within an internal service call context. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1190 Exploit Public-Facing Application and potentially T1584 Compromise Infrastructure if the attacker leverages the proxy capability to pivot into other systems via the dbt Cloud API. The lack of HMAC signature verification means there is no integrity check on incoming webhook payloads, allowing arbitrary parameter injection that drives malicious server-side requests.
Mitigation strategies involve upgrading immediately to version 0.3214.0 or later where identifier path traversal has been addressed and strict validation is applied to input parameters. For environments running older versions, administrators should implement network-level controls such as firewall rules or reverse proxy configurations to restrict outbound traffic from the Lightdash server to only necessary endpoints on cloud.getdbt.com with specific allowed paths. Additionally, configuring a webhook secret in dbt Cloud settings ensures that HMAC signatures are verified for incoming requests, adding an essential layer of integrity and authenticity verification. Until patches are applied, restricting public access to the project UUIDs through strict sharing policies can reduce the attack surface by preventing discovery of valid target identifiers.