In a recent revelation shaking the cloud security landscape, cybersecurity researchers from Aqua Security have uncovered alarming risks hidden in default Identity and Access Management (IAM) roles within Amazon Web Services (AWS). These roles, often created automatically by AWS services like SageMaker, Glue, EMR, and Lightsail, come with overly permissive access — particularly, AmazonS3FullAccess — and open dangerous pathways for privilege escalation and lateral movement across services.
When setting up services like SageMaker or EMR, AWS often recommends or auto-generates IAM roles to streamline integration. However, Aqua researchers Yakir Kadkoda and Ofek Itach warn that these roles can quietly introduce security holes.
For instance, the AmazonSageMaker-ExecutionRole, AWSGlueServiceRole, and AmazonEMRStudio_RuntimeRole all include AmazonS3FullAccess, which essentially grants read/write access to all S3 buckets in the account.
This excessive privilege becomes a major threat vector when exploited by a bad actor who gains access to just one of these roles.
Unlike traditional “bucket takeover” attacks that depend on clever naming patterns, attackers leveraging these IAM roles don’t even need to guess bucket names. With broad access in hand, they can:
- Enumerate and explore all S3 buckets.
- Modify CloudFormation templates, EMR scripts, and SageMaker artifacts.
- Inject malicious payloads to escalate privileges.
- Move laterally between AWS services, possibly gaining full account control.
One chilling example? A malicious ML model uploaded to Hugging Face could be imported into SageMaker. Once executed, it could hijack SageMaker’s permissions, steal credentials, and use Glue or EMR to pivot and backdoor the rest of the infrastructure.
In response to Aqua’s findings, AWS has updated the AmazonS3FullAccess policy applied to these default roles, scoping it down to limit unnecessary access. Here’s what AWS confirmed:
- AWS CDK, Glue, EMR, and SageMaker services are now functioning with revised role policies.
- Amazon Lightsail has updated its documentation, guiding users to create custom, limited-access roles instead.
- The CDK now restricts asset uploads to user-owned buckets, adding another layer of protection.
While these are steps in the right direction, the responsibility still lies heavily with AWS users to audit, revise, and monitor IAM roles actively.
If you’re using AWS in any capacity, here’s what you should consider doing immediately:
- Audit IAM Roles – Identify any default or overly permissive roles in your account.
- Restrict Policies – Use least privilege principles. Grant access only to required resources.
- Use Service Control Policies (SCPs) – For organizations using AWS Organizations, SCPs help enforce security boundaries.
- Monitor Role Assumptions – Set up CloudTrail and IAM Access Analyzer to detect unusual access patterns.
- Educate Your Teams – Developers should be aware that convenience often comes at the cost of security.
In a related disclosure, Varonis researchers uncovered a privilege escalation vulnerability affecting Azure AI and HPC workloads. The culprit? A utility called AZNFS-mount, which includes a vulnerable SUID binary up to version 2.0.10. This could allow any unprivileged user on a Linux machine to escalate privileges to root.
Microsoft patched this issue in version 2.0.11 (released January 30, 2025), but if you’re running an earlier version, it’s critical to update immediately.
Cloud services have brought incredible flexibility and power to developers and businesses. But as these platforms grow more complex, so do the risks — especially when default configurations are taken at face value. If you’re leveraging AWS or Azure, never assume default means secure. Take the time to review your IAM roles and permissions — your cloud security depends on it.
