Invisible Threats in the Cloud: When AWS Defaults Become Dangerous by Design
In a discovery that redefines what “secure by default” should mean, security analysts have revealed a hidden flaw lurking not in user errors—but in the very foundations of AWS’s own default configurations.
Rather than being a result of poor cloud hygiene, this threat originates from standard AWS service setups that quietly deploy overly privileged roles—no warning, no alerts. These roles, often created automatically when launching services like SageMaker, Glue, or EMR, carry broad permissions that dramatically overstep their intended scope.
These aren’t just technical leftovers—they’re “shadow roles” with real power.
The core of the issue? Roles routinely granted sweeping S3 access, such as the AmazonS3FullAccess policy. It’s not just about data exposure; it’s about control. With unrestricted access to S3, attackers can manipulate configuration files, code artifacts, and automation assets that underpin many critical AWS services. That opens the door to silent service abuse, lateral movement, and full account compromise.
And it doesn’t end there. These high-risk roles have been found not only in enterprise environments but also embedded within widely-used open-source ecosystems like Ray, compounding their reach.
What appears to be a harmless support role can, under the right conditions, become a launchpad for cross-service exploitation—thanks in part to AWS’s habit of assigning predictable and overly generous permissions by default.
The implications are severe. In cloud environments where speed often trumps scrutiny, these default roles are rarely reviewed, and even less frequently restricted. But with one misstep—or one breach—they can act as a fuse that burns straight to the heart of your infrastructure.
It’s time to challenge assumptions about what “default” really means—and to treat these quiet permissions not as conveniences, but as potential liabilities.
Exploiting Default Roles in AWS Glue and SageMaker: A Deep Dive into a High-Risk Scenario
(Source: Aqua Security)
A critical pattern has emerged across AWS services: default roles tied to tools like CloudFormation, CDK, SageMaker, EMR, and Glue often rely on S3 buckets with highly predictable names. For example:
- CloudFormation:
cf-templates-{hash}-{region} - AWS CDK:
cdk-{qualifier}-assets-{account-ID}-{region} - Similar patterns exist across SageMaker, EMR, and Glue, simplifying an attacker’s path to locating critical buckets.
Weaponizing SageMaker with Malicious AI Models
One of the most alarming attack vectors involves Amazon SageMaker. Aqua Security researchers uncovered that a threat actor can import a malicious Hugging Face model into SageMaker—and that alone can lead to remote code execution.
Here’s the catch: even with trust_remote_code=False, SageMaker still executes any inference.py file present in the model package. That’s because the flag only affects Hugging Face’s model-loading logic—not SageMaker’s own deployment pipeline.
The danger amplifies when you consider SageMaker’s default execution role, which is often granted a near-unrestricted S3 access policy, effectively mirroring AmazonS3FullAccess:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:PutObject”,
“s3:DeleteObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::*”
]
}
]
}
With this role, malicious code embedded in the model gains sweeping control over all S3 buckets in the account. From there, it can manipulate shared configurations, override assets used by other AWS services, or implant persistent backdoors—potentially resulting in full account compromise.
Key Takeaway:
This isn’t a theoretical flaw. It’s a real, exploitable gap in AWS’s default security posture—where over-permissive roles and overlooked execution behaviors create an easy-to-miss, high-impact attack surface.
