SageMaker Vulnerability Enables Privilege Escalation By Attackers

AWS SageMaker provides managed Jupyter notebook instances for data science tasks. These instances link to IAM execution roles with broad permissions for storage, compute, and model access.

Attackers need only four key permissions: sagemaker: StopNotebookInstance, sagemaker: CreateNotebookInstanceLifecycleConfig (or update existing), sagemaker: UpdateNotebookInstance, and sagemaker: StartNotebookInstance.​

The process unfolds in sequence. First, stop a target notebook instance if running. Next, create a lifecycle config a base64-encoded shell script that executes on start.

This script can fetch the instance’s identity via “aws sts get-caller-identity” and send credentials to an attacker-controlled endpoint.

Then, update the stopped instance to use this config. Finally, restart it. The script runs as root under the execution role, enabling data theft or further attacks.

Proof-of-concept code automates this: check for config existence, build an exfiltration payload, attach via an update, and restart while waiting on status.

CloudTrail logs show the pattern: StopNotebookInstance → UpdateNotebookInstance → StartNotebookInstance from unusual principals.

Step	Description	Key API Call
1	Halt running instance	StopNotebookInstance
2	Build malicious config	CreateNotebookInstanceLifecycleConfig
3	Attach config	UpdateNotebookInstance (lifecycle-config-name)
4	Restart instance	StartNotebookInstance
5	Exfiltrate via script	sts:get-caller-identity in lifecycle

​This bypasses IAM: PassRole, checked only at role assignment, not runtime code changes.​

Broader Risks and Fixes

The flaw extends beyond notebooks, potentially to SageMaker Studios, Lambda code updates, and CloudFormation changesets. Execution roles decouple from code mods post-setup, creating gaps.

Detect anomalies on stop-update-start chains via CloudTrail, especially involving non-admin users.

Prevent by restricting lifecycle and update actions to admins, using SCPs to block broad PassRole, and mandating reviews for restarts. Treat config changes as code execution equivalents.

AWS sees this as a misconfiguration under shared responsibility, with no patch yet after the VDP notice audit roles via tools like HackingTheCloud.

Similar issues have persisted since 2016 with EC2 userData hooks.

​