SageMaker Vulnerability Let Attackers Escalate Privileges

A recently highlighted weakness in Amazon SageMaker AI shows how attackers can silently gain higher cloud permissions by abusing notebook instances.

The issue does not rely on a new software bug. Instead, it uses existing SageMaker features in a dangerous way when IAM permissions are too broad.

class="wp-block-heading" id="how-the-attack-works">How the attack works

SageMaker notebook instances are managed compute environments, almost certainly backed by EC2. Each notebook runs with an IAM execution role. That role often has powerful access to data, models, and other AWS services.

If an attacker controls an IAM user or role that can stop, start, and update a SageMaker notebook instance, they can run their own code as that notebook’s execution role.

The key permissions are:

• sagemaker:StopNotebookInstance
• sagemaker:StartNotebookInstance
• sagemaker:UpdateNotebookInstance
• plus the ability to create or manage notebook lifecycle configurations

A lifecycle configuration in SageMaker is a set of shell scripts that run when the notebook is created or started. By design, this is for setup tasks. In this attack, it becomes the execution path.

The attacker first creates a malicious lifecycle configuration. For example, the script can call aws sts get-caller-identity to identify the role in use, then send that data to an external server with curl.

Next, the attacker:

Stops a target notebook instance, updates it to attach the new lifecycle config, and then starts it again.

On boot, SageMaker runs the attached script on the instance, under the notebook’s execution role. This lets the attacker act as that role, without ever being granted it through sts:AssumeRole or PassRole.

AWS is supposed to control who can use which IAM role through the iam:PassRole check, which happens when a role is first attached to a resource.

Here, the attacker never changes the role. They only change the startup code that runs under that role later. That cleanly bypasses the spirit of PassRole while staying inside allowed APIs.

Defenders should monitor CloudTrail for unusual patterns like StopNotebookInstance → UpdateNotebookInstance → StartNotebookInstance, especially from identities that do not usually manage that notebook.

To prevent abuse, tightly limit who can update SageMaker notebook instances and lifecycle configurations, and treat any ability to change startup scripts as equivalent to “run arbitrary code as the execution role.”

Find this Story Interesting! Follow us on Google News, LinkedIn and X to Get More Instant Updates

The post SageMaker Vulnerability Let Attackers Escalate Privileges appeared first on Cyber Security News.