CVE-2026-12593
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk20th percentile - higher than 20% of all known CVEs
Summary
An internal and undocumented Dashboard API endpoint (POST /api/users/~/{user}/tokens) failed to enforce sufficient permissions when creating an API token for another user. An attacker knowing the login name of a privileged internal user and authenticated via OAuth/OIDC could forge a token creation request on their behalf.
Risk Assessment
In the worst case, the attacker could gain Dashboard Administrator privileges and perform all administrative actions. Combined with another weakness, this could lead to code execution on the host system with the privileges of the OS user running the Dashboard server.
Recommendation
Immediately update the Dashboard to a version that fixes the permission check for the API token creation endpoint. Additionally, restrict Dashboard access to trusted OAuth/OIDC users only.
Other vulnerabilities in Dashboard
See all- CVE-2026-42127High
The public dashboard query endpoint does not limit request body size before processing, allowing unauthenticated attackers to trigger excessive memory allocation by sending arbitrarily large JSON payloads. This can lead to denial of service through memory exhaustion.
- CVE-2026-33377High
An Editor can overwrite a dashboard not owned by them to acquire admin on that specific dashboard. The user must have write access to escalate privilege.
Original NVD description (English source)
The implementation of an internal and undocumented Dashboard API endpoint (POST /api/users/~/{user}/tokens) forgot to ensure an HTTP request for creating an API Token for another user had sufficient permission to do so. Precondition for successful exploitation was a preexisting internal user (with more privileges than the attacker), the attacker knowing its login name and the attacker being able to authenticate to the Dashboard via OAuth/OIDC. The attacker would then have had to forge a token creation API request on behalf of the other user and could have authenticated and finalized the token creation with their own OAuth/OIDC credentials. In the worst case, this would mean an attacker could have become Dashboard Administrator and been able to perform all administrative actions if the preexisting internal user had administrative privileges. In combination with a separate weakness, this could have further led to code execution on the host system running the Dashboard with the privileges of the OS-User running the Dashboard server.