CVE-2026-61654 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 Lightdash versions through 0.3213.0 involving the unauthenticated handling of webhook requests from dbt Cloud. Specifically, the endpoint POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook lacks authentication middleware and signature validation mechanisms. This architectural flaw allows any actor with network access to this endpoint to trigger backend operations without proving their identity or the integrity of the request payload. The vulnerability stems from insufficient input validation in the testWebhook function located within packages/backend/src/controllers/projectController.ts, which accepts accountId and runId parameters directly from incoming job.run.completed events.
The technical core of the flaw lies in how these unsanitized inputs are processed by the createPreviewWithExplores service method found in packages/backend/src/services/ProjectService/ProjectService.ts. The application interpolates the provided accountId value into a server-side URL targeting cloud.getdbt.com, which is then requested using the victim project's stored API key within the Authorization header. Because there is no path traversal mitigation or strict validation on the accountId parameter, an attacker can manipulate this field to alter the request path while keeping the host constant. This constitutes a Server-Side Request Forgery (SSRF) vulnerability where the application acts as a proxy for maliciously crafted requests directed at internal or external resources controlled by the victim's credentials.
The operational impact of this SSRF is significant, primarily due to the use of legitimate project API keys in outbound requests initiated by the server. While initial advisories suggested that an attacker could steal these API keys by observing response headers, practical exploitation evidence indicates that direct header exfiltration may not be feasible depending on network configurations and browser security policies. However, the ability to forge authenticated requests allows attackers to perform actions as the victim project within dbt Cloud. This includes triggering data processing jobs or accessing sensitive dataset previews without authorization. The requirement for a valid projectUuid limits the attack surface slightly, as UUIDs are not enumerable by default but can be discovered in shared dashboards, public reports, or multi-tenant environments where identifiers might be exposed to unauthorized users.
This vulnerability aligns with CWE-918 Server-Side Request Forgery and falls under MITRE ATT&CK technique T1557 Adversary-in-the-Middle if the attacker uses the forged requests to intercept or manipulate communications between Lightdash and dbt Cloud services. It also reflects CWE-20 Improper Input Validation due to the failure to sanitize special characters in path segments that could alter resource location. The lack of HMAC signature verification means there is no cryptographic assurance that the webhook originated from a trusted source, violating fundamental principles of secure API design regarding message integrity and authenticity.
Mitigation strategies involve upgrading to version 0.3214.0 or later, which addresses identifier path traversal issues by implementing stricter validation on input parameters. Furthermore, administrators should configure HMAC secrets for their dbt Cloud webhook integrations within Lightdash settings. Although the fix only enforces signature verification when a secret is explicitly configured, enabling this feature ensures that all incoming webhooks are validated against expected cryptographic signatures before processing begins. This prevents unauthorized actors from injecting malicious payloads even if they can reach the endpoint network-wise. Additionally, organizations should audit their public-facing resources to ensure project UUIDs and other sensitive identifiers are not inadvertently exposed in shared links or embedded content, thereby reducing the attack surface for discovery-based exploitation attempts.