AWS service roles’ default configuration includes serious flaws that have been discovered by recent security research.
These flaws show how default permissions can increase attack surfaces, allow privilege escalation, and in some situations, make it easier to hack an entire AWS account.
These issues stem from the broad permissions-specifically AmazonS3FullAccess-routinely granted to automatically generated roles across multiple core AWS services, including SageMaker, Glue, EMR, and popular open-source deployments like Ray.
Default Service Roles Pose Critical Security Risk
AWS Identity and Access Management (IAM) is designed to granularly control user and service permissions. However, the cloud giant frequently simplifies onboarding by auto-generating “default roles” with pre-attached managed policies for ease of use.
While convenient, these default roles sometimes carry excessive permissions that inadvertently open critical vectors for exploitation.
For instance, AWS Glue creates the AWSGlueServiceRole with AmazonS3FullAccess attached, and SageMaker’s initial setup provisions an execution role with near-equivalent S3 privileges.
Such unrestricted access not only exposes sensitive data but also enables attackers to traverse between AWS services, manipulate infrastructure-as-code assets, and subvert isolation boundaries.
The core of the risk lies in S3’s centrality to AWS workflows. Services such as CloudFormation, SageMaker, EMR, Glue, and the AWS CDK utilize S3 buckets for storing critical assets, including scripts and configuration files.
When roles hold AmazonS3FullAccess, they gain the ability to enumerate, read, and modify these assets across predictable bucket naming patterns.
According to the Report, this allows a compromised low-privilege service to tamper with CloudFormation templates or EMR scripts, enabling lateral movement or even code execution with administrative context elsewhere in the account.
Over-Permissive S3 Access Facilitates Lateral Movement and Account Takeover
Real-world examples demonstrate the reach of these threats. A malicious Hugging Face model imported into SageMaker can execute arbitrary code under a privileged role, access any S3 bucket, and inject malicious payloads into the scripts of services like Glue.
Similarly, default roles in open-source projects, like Ray’s ray-autoscaler-v1, grant AmazonS3FullAccess by default-offering attackers similar privilege escalation opportunities if the underlying compute is compromised.
Despite the potential for wide-reaching impact, AWS responded promptly to responsible disclosure from security researchers, scoping down the permissions of default roles, updating documentation, and actively notifying affected customers.
SageMaker and EMR have tightened their role policies, Glue reduced default permissions, and Lightsail now directs users to create narrowly scoped S3 policies rather than blanket access.
Mitigation recommendations are clear: organizations must actively audit all IAM roles for overly broad policies-especially AmazonS3FullAccess-and rigorously apply the principle of least privilege.
Default service roles should never be assumed secure by design; instead, they require continual review and restriction to only those resources and actions strictly necessary for service operation.
As AWS continues to refine service defaults and offer improved security guidance, the onus is on customers to scrutinize and lock down their environments, ensuring that convenience does not override security and that attackers are denied easy paths to privilege escalation and account compromise.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant updates
