Read-only access. No write permissions. No delete permissions. Safe. Or so the policy claimed.
Privilege escalation in AWS S3 read-only roles is one of the most overlooked security gaps in cloud environments. Attackers know that "read-only" often means much more than it should. In AWS, permission boundaries, policy misconfigurations, and overlooked trust relationships can turn a harmless role into a credential harvesting point or a stepping stone to full account compromise.
An S3 read-only role should only allow s3:GetObject and s3:ListBucket. But many IAM policies aimed at read-only access include wildcard actions, resource-wide grants, or inherited permissions via group policies. The danger grows when combined with permissions for other services—like the ability to assume roles, query sensitive metadata, or enumerate resource ARNs. With these, an attacker can map infrastructure and pivot to roles with higher privileges.
Common privilege escalation vectors include:
- Cross-account trust where a read-only role can assume a more powerful role.
- Overly broad policies (
s3:* or *:*) hidden within managed policy attachments. - Access to sensitive configuration files stored in public or misconfigured S3 buckets that contain IAM keys or service credentials.
- Metadata exposure when the read-only role also allows EC2 instance introspection.
Stopping this requires strict adherence to least privilege. Audit every policy with the principle of explicit allow and explicit deny. Avoid wildcards. Use AWS Access Analyzer to detect unintended access paths. Monitor for unexpected role assumptions. Enforce Service Control Policies (SCPs) at the AWS Organization level to ensure no read-only role can escalate without detection.
Attackers thrive on assumptions. Do not assume read-only means safe. Test every access path, simulate attacks in staging, and confirm that your S3 read-only roles cannot be chained into full account control.
See how to detect and break privilege escalation paths in AWS with live cloud environments. Try it on hoop.dev and go from theory to real exploits in minutes.