CVE-2026-108747 in Lightdash
Summary
by MITRE • 10/11/2026
Lightdash through 2.556.0 contains an authorization bypass vulnerability that allows authenticated organization members to delete other users' personal access tokens by supplying their UUID. Attackers can send DELETE requests to the personal-access-tokens route with a victim's token UUID, even across organizations, to revoke it and break API integrations.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The identified security flaw resides within Lightdash versions up through 2.560 and represents a critical failure in server-side access control mechanisms for user authentication artifacts. Specifically, the vulnerability allows authenticated organization members to bypass intended authorization checks when interacting with the personal-access-tokens endpoint. In secure systems, operations that modify or delete sensitive credentials must be strictly bound to the identity of the requesting user, ensuring that individuals can only manage their own tokens. However, in this instance, the application logic relies on client-supplied identifiers without adequately validating whether those identifiers belong to the authenticated session making the request. This design oversight creates a direct path for unauthorized modification of security credentials belonging to other users within the same organization or potentially across organizational boundaries if multi-tenancy isolation is not strictly enforced at the database level.
From a technical perspective, this vulnerability constitutes an Insecure Direct Object Reference (IDOR), which aligns with CWE-639 in the Common Weakness Enumeration taxonomy. The core issue lies in the absence of proper authorization checks on the DELETE method for personal access tokens. When a user initiates a request to revoke a token by providing its universally unique identifier, the backend processes this instruction without verifying ownership. An attacker can exploit this by crafting HTTP DELETE requests that target specific UUIDs associated with other users' tokens. Because the system accepts these identifiers as valid targets regardless of their association with the current session, it effectively grants any authenticated user the ability to manipulate the authentication state of others. This flaw is particularly severe because personal access tokens are often used for programmatic API integrations and automated workflows that operate without continuous human oversight.
The operational impact of this vulnerability is significant, primarily due to its potential to cause denial of service against legitimate business processes rather than leading directly to data exfiltration or privilege escalation in the traditional sense. By revoking other users' personal access tokens, an attacker can abruptly terminate active API connections and automated scripts that rely on these credentials for execution. This disruption affects system availability and integrity, as dependent services will fail when their authentication mechanisms are invalidated without warning. Furthermore, if multi-tenancy controls are weak, this capability could extend across organizational boundaries, allowing a member of one tenant to disrupt the operations of another, thereby violating isolation guarantees essential in SaaS environments. The ability to act across organizations suggests that the vulnerability may also involve CWE-284 Improper Access Control or CWE-15 External Control of System or Configuration Setting if the underlying architecture fails to properly scope resource access by organization ID during token deletion logic.
Mitigation strategies must focus on implementing robust server-side authorization checks for all state-changing operations involving user-specific resources. Developers should ensure that every request to delete a personal access token includes validation steps that confirm the requesting user's identity matches the owner of the target token UUID. This can be achieved by joining the token table with user or organization tables during the deletion query and verifying ownership before executing the database command. Additionally, implementing rate limiting on authentication-related endpoints can help mitigate brute-force attempts to discover valid token identifiers. For organizations currently running vulnerable versions, immediate patching to a version where this authorization logic has been corrected is essential. In the interim, monitoring logs for unusual patterns of DELETE requests against personal-access-tokens routes may provide early detection indicators for potential exploitation activities aligned with MITRE ATT&CK technique T1530 Data from Cloud Storage or T1497 Virtualization/Sandbox Evasion if used to disrupt security monitoring tools themselves.