Lightdash EUVD-2026-96912

Exploitation requires an authenticated Lightdash account with at least organization-member privileges (PR:L) and knowledge of the target's personal-access-token UUID, which must be supplied in a DELETE request to the personal-access-tokens route; because PAT UUIDs are not easily enumerable, obtaining the victim's UUID is the primary limiting factor (reflected as AC:H). No victim user interaction is needed, and the missing ownership check applies even across organization boundaries, so multi-tenant/hosted deployments are affected. Impact is limited to revoking the victim's token and breaking their API integrations (denial of service to integrations); there is no data disclosure or code execution.

This is a genuinely low-priority issue, and the available signals are consistent in saying so. The vendor CVSS 4.0 score is 2.3 (Low) with vector AV:N/AC:H/AT:N/PR:L/UI:N and only VI:L/VA:L impact - network-reachable but high attack complexity, requiring an authenticated low-privileged account, with impact limited to low integrity/availability and no confidentiality loss. The AC:H reflects that an attacker must obtain or guess the victim's personal-access-token UUID, which is not readily enumerable. There is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or probable widespread exploitation; however, a public technical write-up (hackmd) with a detailed proof-of-concept describing the DELETE request exists, so publicly available exploit information does exist. The one notable aggravating factor is cross-organization scope: in a multi-tenant Lightdash deployment, any authenticated member of one organization can revoke tokens belonging to users in other organizations. Even so, the harm is denial-of-service to API integrations (token revocation), not data theft or code execution. No key signals conflict; the main missing data is an EPSS probability and any exploitation telemetry.

An authenticated low-privileged Lightdash organization member who obtains another user's personal-access-token UUID sends a crafted DELETE request to the personal-access-tokens route specifying that victim UUID. Because the server does not verify ownership, the victim's token is revoked, breaking their automated API integrations. A public proof-of-concept write-up documents the exact request, and the flaw works even across organization boundaries in multi-tenant deployments.