In a cloud environment built for scale, defaults are meant to simplify. But what happens when those defaults quietly open doors you never intended?
New research has revealed a troubling pattern across multiple AWS services: default IAM roles—automatically created or recommended during setup—often include overly broad permissions. Chief among them is AmazonS3FullAccess, a policy that grants full access to every S3 bucket in your account. This can turn a seemingly harmless service role into a launchpad for lateral movement, privilege escalation, and ultimately, full account compromise.
This post explores real-world attack paths made possible by default AWS roles, including SageMaker, Glue, and EMR. We’ll walk through two demonstration scenarios, explain how these issues were responsibly disclosed, and offer clear guidance on how to secure your cloud environment.
The Core Problem: Default Roles with Excessive Privileges
AWS Identity and Access Management (IAM) governs access to resources by assigning users, groups, and services to roles and policies. To streamline operations, AWS services often create or suggest default roles when they are first launched.
For example, AWS Glue creates a default role called AWSGlueServiceRole, while Amazon SageMaker generates an AmazonSageMaker-ExecutionRole-<timestamp> during domain creation. These roles are typically granted policies like AmazonS3FullAccess—a blanket permission set that allows read and write access to all S3 buckets within the account.
This is where the danger begins. S3 isn’t just a storage service—it’s the backbone for many AWS operations. Glue jobs, SageMaker models, EMR notebooks, CloudFormation templates, and CDK assets often depend on S3. If an attacker compromises any of these overly-permissive roles, they can manipulate configurations, deploy backdoors, and even inject admin-level policies through indirect routes.
Why AmazonS3FullAccess Is So Dangerous
The AmazonS3FullAccess policy sounds self-explanatory—but its implications are often misunderstood. With access to all S3 buckets, an attacker can do far more than exfiltrate data:
- Tamper with Glue job scripts
- Alter SageMaker models and training data
- Inject malicious CloudFormation templates
- Compromise CDK deployment files
- Execute lateral movement across services
Worse still, many AWS services follow predictable S3 bucket naming conventions:
- CloudFormation: cf-templates-{Hash}-{Region}
- CDK: cdk-{qualifier}-assets-{account-ID}-{Region}
- SageMaker: sagemaker-{Region}-{Account-ID}
- EMR: aws-emr-studio-{Account-ID}-{Region}
- Glue: aws-glue-assets-{Account-ID}-{Region}
This makes bucket discovery and exploitation trivial once access is granted.
Real-World Attack Scenario 1: From SageMaker AI to Glue Compromise
In this scenario, an attacker uploads a malicious model to Hugging Face and tricks a SageMaker user into importing it. The model contains an inference.py file with embedded code that scans for Glue asset buckets and modifies job scripts to exfiltrate IAM credentials.
SageMaker, by default, executes this script during model loading—even if trust_remote_code=False is set, due to a quirk in its implementation. Since the default execution role allows near-full S3 access, the attacker can inject a backdoor into every accessible Glue job.
The result? A SageMaker notebook becomes a stepping stone to compromise another service entirely—no brute force, no user interaction, just misconfigured defaults.
Real-World Attack Scenario 2: Escalation from Glue to Admin Access
Glue jobs run under AWSGlueServiceRole, which—until recently—was often paired with AmazonS3FullAccess.
An attacker with permissions to create or edit Glue jobs can leverage this default role to:
- Enumerate buckets across the account
- Locate CDK or CloudFormation asset buckets
- Modify templates to include admin roles
- Wait for a privileged user to deploy the compromised asset
This attack doesn’t require direct admin access. It hijacks the deployment lifecycle, using AWS itself to escalate privileges. If an altered CloudFormation stack is executed, the attacker could gain full administrative control over the environment.
Open-Source Exposure: The Ray Framework
This issue extends beyond AWS services. Ray, a popular open-source framework for distributed workloads, creates a default IAM role (ray-autoscaler-v1) with the AmazonS3FullAccess policy hardcoded.
If an attacker compromises a Ray worker node, they can tamper with any S3-backed service in the environment—just like with SageMaker or Glue. Other projects using Terraform or Python scripts often follow similar insecure patterns, creating overly permissive IAM roles to simplify setup at the cost of security.
AWS Response and Remediation
Upon responsible disclosure, AWS acted swiftly:
- SageMaker: Scoped down default S3 access during domain creation.
- Glue: Updated documentation and restricted role permissions.
- EMR: Limited default access to S3 buckets.
- Lightsail: Removed documentation recommending AmazonS3FullAccess.
Additionally, AWS notified affected users via email and updated best practices for service roles. Documentation for safe IAM role usage across services like CDK, Glue, and EMR has also been enhanced.
Best Practices for AWS CDK IAM Security
What You Should Do Now
If you’re using AWS Glue, SageMaker, EMR, CDK, or related services, it’s time to act.
✅ Audit IAM Roles:
Review roles created automatically or during service setup. Look for any roles with AmazonS3FullAccess or wildcard S3 permissions.
✅ Scope Down Policies:
Replace broad permissions with narrowly defined, resource-specific policies. Avoid using managed policies unless they’re tightly controlled.
✅ Enforce Least Privilege:
Adopt a “deny by default” approach. Only allow access to the exact resources required, and nothing more.
✅ Monitor Role Usage:
Use AWS CloudTrail and GuardDuty to track role activity. Unusual use of default roles should trigger alerts and reviews.
Defaults are helpful—but only when they’re secure.
As this research shows, overly permissive default roles can silently introduce critical vulnerabilities into even the most well-architected environments. From compromised notebooks to poisoned deployment pipelines, attackers can exploit these roles to escalate privileges, tamper with services, and take control of entire accounts.
The fix is simple, but not easy: audit, restrict, and monitor. It’s time to treat IAM role scoping as a first-class security priority.
Because in the cloud, the biggest risks are often the ones you didn’t create yourself.
Need help with your businesses automated updates? Talk to us today to find out more about our available patch and privilege management strategies.