CVE-2026-108747: Authorization Bypass in Lightdash Lets Authenticated Users Delete Other Users’ Personal Access Tokens Across Organizations

Summary

Lightdash through version 2.556.0 contains an authorization bypass vulnerability, classified as CWE-639 (Authorization Bypass Through User-Controlled Key), that allows authenticated organization members to delete personal access tokens belonging to other users. An attacker sends a DELETE request to the personal-access-tokens route with a victim’s token UUID, and the server revokes the token without verifying that the requesting account owns it. Notably, the description states this works even across organizations, so the token does not need to belong to the attacker’s own organization.

The practical result is the revocation of another user’s API credential: any integration that depends on the deleted token stops working. The CVSS 4.0 base score is 2.3 (LOW), reflecting low integrity and availability impacts with no confidentiality impact — the attack destroys a token but does not reveal its value.

Technical Analysis

CWE-639 describes a familiar failure pattern: the application accepts a user-supplied identifier — here, the UUID of a personal access token — and uses it to locate the object on which the requested operation is performed, without confirming that the authenticated principal is authorized to act on that specific object. In CVE-2026-108747, that operation is deletion. The personal-access-tokens route accepts a DELETE request carrying a victim’s token UUID, and the backend revokes the token even though it belongs to a different user — and, per the advisory description, potentially to a user in a different organization entirely.

The references published with the advisory point into the Lightdash backend source tree, specifically packages/backend/src/models/DashboardModel/PersonalAccessTokenModel.ts at lines 157–162 and packages/backend/src/services/PersonalAccessTokenService.ts at lines 107–134. These locations correspond to the model and service layers that handle personal access tokens, and they mark where the deletion logic lives. The advisory data does not include the code content itself, so the precise check that is missing or misapplied is not fully disclosed; what is established is the observable behavior: an authenticated member of one organization can cause the deletion of a token owned by another user, including a user in another organization.

UUID-keyed resources are a recurring source of CWE-639 findings. Identifiers like UUIDs feel unguessable, which can create a false sense of access control: a developer may reason that an attacker who does not know the UUID cannot cause harm, and skip the ownership check. That reasoning fails as soon as a UUID leaks through any other channel — shared logs, collaboration tools, or a user pasting their own token identifier into a shared context. The authorization decision must not depend on the secrecy of the identifier.

The CVSS 4.0 vector breaks down as follows. The attack vector is network (AV:N): the DELETE request is sent over the network to the application. Attack complexity is high (AC:H): the attacker must supply a specific victim token UUID, and UUIDs are large identifier values that are not practical to guess by brute force, so the attacker would typically need to obtain the UUID by some other means — the advisory data does not specify how such UUIDs might be discovered in practice. Privileges required are low (PR:L): any authenticated organization member qualifies, with no user interaction (UI:N) and no attack prerequisites (AT:N). Impact metrics show no confidentiality impact (VC:N) — nothing in the description indicates the token’s secret value is exposed — but low integrity (VI:L), because the token resource is destroyed, and low availability (VA:L), because integrations relying on the token lose access. There is no impact on subsequent systems (SC:N/SI:N/SA:N).

The cross-organization aspect is the most architecturally significant part of this finding. Many authorization implementations scope checks to the requesting user’s own organization; a bypass that crosses organization boundaries suggests the deletion path may not be enforcing tenant scoping at all. The vulnerability was discovered by HaiND from the Post and Telecommunication Institute of Technology, and the CVE was assigned by VulnCheck.

Affected Software and Versions

The affected product is Lightdash, whose source code is published at github.com/lightdash/lightdash. According to the advisory description, all versions through 2.556.0 are affected. The vulnerable component is the backend’s personal access token handling — the model and service code paths cited in the references.

Product: Lightdash
Affected versions: through 2.556.0 (no earlier bound is given, so all released versions up to and including 2.556.0 should be treated as affected)
Fixed version: not disclosed in the provided advisory data — verify current fix status in the upstream repository and the VulnCheck advisory before relying on any specific release
Component: backend personal access token deletion (PersonalAccessTokenModel and PersonalAccessTokenService, per the referenced source paths)
KEV status: not listed in CISA’s Known Exploited Vulnerabilities catalog per the provided data

Impact

The direct impact is unauthorized revocation of personal access tokens. A personal access token is an API credential; when it is deleted, every client, script, or pipeline that authenticated with it stops working. The advisory description states this plainly: the attack revokes the token and breaks API integrations.

Mapping this to the CVSS 4.0 metrics: integrity impact is low (VI:L) because the token resource is modified — specifically, destroyed — by someone other than its owner. Availability impact is low (VA:L) because the owner’s API integrations lose their credential and fail. There is no confidentiality impact (VC:N): the attacker deletes the token but does not learn its value, and nothing in the description suggests account takeover or data exposure beyond the deletion itself.

Two aggravating characteristics are worth noting even at a LOW base score. First, the cross-organization reach means the usual tenant boundary does not protect a victim: an authenticated member of organization A can revoke the token of a user in organization B. Second, the victim has no obvious signal about who deleted the token or why; from the owner’s perspective, integrations simply begin failing with authentication errors. Recovery requires noticing the token is gone, re-issuing one, and updating every dependent integration.

That said, the ceiling of this vulnerability is disruption. The description does not indicate privilege escalation, data theft, or persistence — the attacker cannot use the deleted token, read it, or create new tokens under someone else’s name based on what is disclosed.

Exploitation Scenario

The following scenario is illustrative and is derived directly from the advisory description; it does not describe a specific observed attack.

An attacker holds a low-privilege authenticated account on a Lightdash instance — or, in a deployment with multiple organizations, an account in any one organization.
The attacker learns the UUID of a victim’s personal access token. The advisory data does not specify how UUIDs would be obtained; the CVSS high attack complexity rating is consistent with this being the limiting factor, since a UUID is not practical to guess.
The attacker sends a DELETE request to the personal-access-tokens route, supplying the victim’s token UUID.
The backend processes the deletion without verifying that the requesting account owns the token — or, apparently, that the token even belongs to the same organization — and revokes it.
The victim’s API integrations begin failing. If the victim is in a different organization, they may have no operational relationship with the attacker at all, complicating both diagnosis and attribution.

Detection and Mitigation

Detection. Operators can look for the signature of this flaw in existing logs:

Search application or reverse-proxy logs for DELETE requests targeting the personal-access-tokens route, and compare the authenticated account on each request with the owner of the token identified by the UUID. A mismatch is the vulnerability being exploited.
Treat any DELETE on this route that crosses an organization boundary as a high-signal indicator, since legitimate self-service deletion should never cross tenants.
Correlate reports of failing API integrations with token revocation events to identify victims after the fact.

Mitigation. The provided advisory data does not disclose a patched release, so the first step is to check the upstream Lightdash repository and the VulnCheck advisory for current fix status. For this class of defect (CWE-639), the durable fix is server-side authorization on the deletion path: before honoring a DELETE, verify that the authenticated principal owns the token identified by the UUID and belongs to the same organization. Interim measures follow from the attack requirements:

Keep an inventory of issued personal access tokens with their owners and UUIDs, so unexpected revocations are detectable and tokens can be quickly re-issued.
Minimize the number of active tokens and rotate them periodically, limiting the blast radius of any single deletion.
Restrict who can register or authenticate to the instance, since PR:L means any authenticated organization member is a potential source of deletion requests.
If a token is suspected deleted, re-issue a replacement and update dependent integrations.
Where a fix has been released, validate it on a non-production instance by reproducing the two-account deletion flow and confirming the request is rejected with an authorization error.

Proof-of-Concept: curl and Burp

The advisory description supplies the request shape: a DELETE to the personal-access-tokens route carrying a victim’s token UUID, sent with an authenticated session. The full API path prefix and the exact authentication header format are not disclosed in the provided data, so the examples below use the route name as given and a placeholder for the session credential.

curl -k -X DELETE "http://<TARGET>/personal-access-tokens/<VICTIM_TOKEN_UUID>" -H "Authorization: Bearer <VALID_SESSION_TOKEN>"

DELETE /personal-access-tokens/<VICTIM_TOKEN_UUID> HTTP/1.1
Host: <TARGET>
Authorization: Bearer <VALID_SESSION_TOKEN>
Connection: close

For authorized testing only — test only systems you are permitted to test.

Bug Bounty Angle

This vulnerability sits squarely in the broken object-level authorization class — one of the most consistently rewarded report categories, because a single missing ownership check is easy to demonstrate and easy for a developer to fix. The demonstration pattern is standard: provision two accounts you control, ideally in two different organizations if the deployment supports that, have account B create a personal access token, then issue the DELETE from account A using B’s token UUID. The request succeeding from an unrelated account is the entire finding.

Two points matter for impact framing. First, the base score here is LOW (2.3), and the direct damage is limited to revocation — no secret disclosure, no takeover. Second, the cross-organization reach is what elevates the finding beyond a routine intra-user IDOR: tenant isolation failures are usually weighed more heavily by program triagers than same-tenant object access issues, because they break an architectural guarantee. Documenting a concrete downstream effect — for example, an integration that stops authenticating after the deletion — makes the availability impact tangible.

The provided data does not state whether Lightdash operates a bug bounty program or what its scope covers, so verify the program’s existence and rules before testing, and confine testing to instances you are authorized to assess. The practical barrier is obtaining a victim token UUID; within a bounty context, using your own second account sidesteps that entirely and keeps testing clean.

Frequently Asked Questions

What is CVE-2026-108747?

An authorization bypass (CWE-639) in Lightdash through 2.556.0. Authenticated organization members can delete other users’ personal access tokens by sending a DELETE request to the personal-access-tokens route with the victim’s token UUID, even across organizations.

How severe is CVE-2026-108747?

CVSS 4.0 base score 2.3 (LOW): network vector, high attack complexity, low privileges required, no user interaction. Impacts are low integrity and low availability; there is no confidentiality impact, so token values are not exposed.

Who discovered CVE-2026-108747?

HaiND from the Post and Telecommunication Institute of Technology. The CVE was assigned by VulnCheck, which also published an advisory; a technical writeup appears on HackMD under the haind03 account.

Is there a fixed version of Lightdash?

The provided advisory data does not disclose a patched release; affected versions are Lightdash through 2.556.0. Check the upstream GitHub repository and the VulnCheck advisory for current fix status.

Discovery and Credits: Discovered by HaiND from the Post and Telecommunication Institute of Technology. CVE assigned by VulnCheck. Technical writeup: HackMD (@haind03); advisory: VulnCheck.