CVE-2026-39910: STACKIT IaaS API · Missing Authorization
Affects STACKIT IaaS APISource CVE Database V5
Not known to be exploited · CVSS 7.7 High.
Data as of 30 Oct 2026, 17:18 UTC
Thin evidence
One scorer or none| CNA (VulnCheck) | CVSS 4.0 | 7.7 |
|---|---|---|
| CNA (VulnCheck) | CVSS 3.1 | 8.8 |
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 17% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 8 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| STACKITIaaS API | Affected
| Fixed in– |
AI-suggested
Until an official fix is available, restrict access to the affected API endpoints to trusted users only and monitor for suspicious activity related to service account attachments. Avoid using the vulnerable PUT servers service-accounts endpoint where possible.
Description
STACKIT IaaS API contains a missing authorization check in the PUT servers service-accounts endpoint. An authenticated, low-privileged attacker can attach an arbitrary service account to a virtual machine they control without validation of their permission to use it, then query the Instance Metadata Service (IMDS) to retrieve an OAuth2 token for that service account and act with its privileges. The impact is confined to the attacker’s own project. The STACKIT Identity Provider enforces strict project matching between the target VM and the requested service account during token impersonation, so cross-project and cross-organization exploitation is not possible. Any further access is bounded by the IAM roles already assigned to the targeted service account.