Lightdash CVE-2026-121631

Exploitation requires an authenticated account holding the 'update' Project permission on at least one project (PR:L) plus a valid credential such as a Personal Access Token, and critically requires the attacker to already know the UUID of a specific target dashboard in a project they have no access to, since the endpoints key off the URL projectUuid but operate on the dashboard loaded solely by its UUID. No special non-default configuration or feature flag is needed - the flaw is present in the default RenameService behavior across the affected versions. Exploitation is limited by the need to possess update rights on some project, the need to discover non-enumerable foreign dashboard UUIDs, and the bounded impact (schema-metadata read and dashboard-filter corruption only); these limits are what keep real-world risk low despite the network attack vector.

This is a genuinely low-priority issue despite being network-reachable. The vendor CVSS 4.0 base score is 2.3 (Low), with vector AV:N/AC:H/AT:N/PR:L/UI:N and only Low confidentiality and integrity impact (VC:L/VI:L) and no availability or subsequent-system impact. The vuln.today Decision label is 'monitor', the lowest urgency tier, consistent with the low score. There is no EPSS score and no KEV listing in the input, so there is no signal of active or widespread exploitation. A detailed proof-of-concept is published in the GHSA advisory, but it consists of manual reproduction steps rather than packaged exploit tooling. The practical risk is constrained by two facts that the CVSS captures as PR:L and AC:H: the attacker must already be an authenticated user holding 'update' permission on at least one project, and must know the UUID of a dashboard in a project they cannot access (UUIDs are not enumerable through normal access), which is what justifies the high attack complexity. The impact is bounded - reading table/field schema metadata and corrupting dashboard filters - with no code execution, no data exfiltration beyond schema names, and no availability loss to the server itself. No signals conflict here: low CVSS, low EPSS-equivalent (absent), no KEV, and a 'monitor' decision all point the same direction. Patch and apply at a normal cadence rather than as an emergency.

An authenticated Lightdash user who legitimately holds 'update' permission on Project A uses their Personal Access Token to send a crafted POST to /api/v1/projects/<ProjectA>/rename/dashboard/<DashboardB-UUID>, where the dashboard UUID belongs to Project B which they cannot access; because the service never verifies the dashboard belongs to the URL project, the filter rewrite is applied to the foreign dashboard, breaking its charts for all its users. A GET to the sibling /fields endpoint lets the same user read dimension and metric names from tables in another project. A public PoC reference with step-by-step requests exists in the GHSA advisory, though it is not verified as working exploit code.