AWS disclosed CVE-2026-104019 on 2 October 2026 (bulletin 2026-125-AWS), an OS command injection in the Studio Space startup validation script of Amazon SageMaker Distribution as used by SageMaker Unified Studio. An authenticated project contributor can run commands in another project member's Space and take that member's temporary execution role credentials. The CNA scores it 9.0 (CVSS 3.1) and 9.3 (CVSS 4.0). AWS lists no workaround, and two older release families get no fix. We found no report of exploitation.
What happened
AWS published bulletin 2026-125-AWS and the CVE record on 2 October 2026. The flaw sits in the startup process of Studio Spaces in Amazon SageMaker Unified Studio. In AWS's words, "improper sanitization of connection details during this validation could allow arbitrary code to be executed in the Space of another project member." The CVE record adds that the attacker needs project contributor permissions.
Patched releases are 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3. Release 4.5.x is not affected. Those fixed images were published on GitHub on 10 September 2026, 22 days before disclosure, and newer patches followed on 22 September (3.9.13, 4.0.12, 4.1.12, 4.2.9, 4.3.6, 4.4.4 and 4.5.1), so run the fixed release or a later one. AWS says the fix "is deployed globally and will apply to all Spaces automatically on the next startup." Lines 2.8 to 2.13 and 3.3 to 3.8 have reached end of support and will receive no patch, so users on them must move to a supported minor line.
The same day AWS published bulletin 2026-124-AWS covering three flaws in Loom for AWS (CVE-2026-103956 and two others), fixed in 1.7.0. It is a separate product and a separate issue; we cover it in its own story.
Why it matters
Spaces are where data scientists run notebooks with an execution role attached. Code execution in someone else's Space means that person's role credentials, and whatever data and services they reach (we covered how one leaked Azure secret led to a 7-minute deletion run). The attacker only needs contributor access to a shared project, a low bar in a large Unified Studio domain. It is the same class of risk as an AI workflow platform RCE that exposed cloud keys: code running where credentials live.
The CVE record states the credential theft without conditions. The bulletin ties it to Trusted Identity Propagation (TIP): in projects with TIP enabled, a user with project contributor permissions or higher could gain another member's temporary execution role credentials and call downstream TIP-enabled AWS services on their behalf. TIP carries a user's IAM Identity Center identity into AWS data services such as Athena, Redshift, Glue and EMR. Credentials that carry that identity can reach data under that person's permissions. For teams that rely on short-lived credentials, this is a reminder that temporary does not mean safe once they are lifted from a running Space.
Technical details
- CVE: CVE-2026-104019. CWE: CWE-78 (OS command injection); CAPEC-88.
- CVSS 3.1: 9.0 Critical,
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H. CVSS 4.0: 9.3 Critical. Both scores come from the CNA (AMZN); NVD lists the record as Received, with only the CNA's scores. AWS's own bulletin rates it "Important (requires attention)", so the Critical label is the CNA/GitHub advisory rating. - Mechanism: CWE-78 means attacker-influenced connection details reach a shell command in the startup validation without neutralization. AWS does not say which property or how it is set.
- Interaction: the vector rates user interaction as required, consistent with the victim's Space starting or restarting. The record does not spell out the trigger, so treat that as inference.
- Resolution: per the bulletin, Spaces adopt the latest patch of their minor line on restart, so no version selection is needed in Unified Studio.
Release lines at a glance
- Fixed: 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5, 4.4.3.
- End of support, no fix: 2.8 to 2.13 and 3.3 to 3.8.
- Not affected: 4.5.x, and releases older than 2.8.0 and 3.3.0.
- Newest releases at time of writing: 3.9.13, 4.0.12, 4.1.12, 4.2.9, 4.3.6, 4.4.4, 4.5.1.
What defenders should do
- Find the image version of each Space. In Studio, the space's details show the image. From the CLI,
describe-spacereturns the image and image version ARNs and the version alias. - Restart every Space. AWS says the fix is already deployed and applies on the next startup, so no image selection is needed in Unified Studio. Then confirm the version from step 1 is a fixed release or later.
- Anyone on 2.8 to 2.13 or 3.3 to 3.8 must move to a supported minor line. No fix is coming for these.
- Review who holds contributor rights on shared projects, and cut them back where they are not needed. AWS lists no workaround.
- Check CloudTrail for unusual use of Space execution roles since the flaw existed. Scope depends on how long the vulnerable images were running. This is our suggestion, not AWS guidance.
- Where TIP is enabled, treat the Identity Center identity behind any exposed credentials as in scope for review, including calls to downstream TIP-enabled services.
What is still unclear
- Who found the flaw: the CVE record lists discovery as unknown and gives no credits.
- Whether any exploitation has occurred. AWS reports none and we found no PoC or CISA KEV entry, but the disclosure is days old.
- Exactly what starts the injection and which resource property is abused. AWS gives no detail.
- How many Spaces still run vulnerable images, and whether any Space was attacked in the 22 days between the 10 September releases and disclosure.
- Whether NVD will publish its own score beyond the CNA's.