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.
No advisories yet.
Solution
Update to one of the fixed releases: 7.9.13, 7.10.11, 7.11.7, or 7.12.2. There is no fixed release on the 7.8.x branch; deployments running 7.8.5-7.8.12 must migrate to one of the fixed releases.
Workaround
Disable the OIDC/OAuth2/SSO authentication feature or shut down the Dashboard server.
Thu, 09 Jul 2026 16:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Thu, 09 Jul 2026 13:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Privilege escalation via forged API token creation in Axivion Dashboard OIDC/OAuth2/SSO subsystem | |
| First Time appeared |
Qt
Qt axivion |
|
| Weaknesses | CWE-862 | |
| CPEs | cpe:2.3:a:qt:axivion:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Qt
Qt axivion |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: TQtC
Published:
Updated: 2026-07-09T14:20:19.757Z
Reserved: 2026-06-18T09:26:17.599Z
Link: CVE-2026-12593
Updated: 2026-07-09T14:20:15.130Z
No data.
No data.
OpenCVE Enrichment
Updated: 2026-07-09T16:15:16Z