https://thedavidpage.pages.dev/tags/privilege-escalation/Recent content in Privilege Escalation on The David PageHugo -- gohugo.ioenSat, 01 Aug 2026 09:00:00 +0700https://thedavidpage.pages.dev/posts/cloud/aws/iam/iam-passrole-privilege-escalation/Sat, 01 Aug 2026 09:00:00 +0700https://thedavidpage.pages.dev/posts/cloud/aws/iam/iam-passrole-privilege-escalation/<p><strong>A developer account with nothing but <code>lambda:CreateFunction</code> and a wildcard <code>iam:PassRole</code> can walk itself up to full Administrator — no exploit, no misconfigured bucket, just permissions doing exactly what they were asked to do.</strong></p> <p>Hi everyone 👋</p> <p>This one doesn&rsquo;t show up as a vulnerability scan finding or a CVE — it&rsquo;s a permissions grant that looks completely reasonable in a policy review, right up until someone connects the dots.</p> <h2 id="-the-convenient-habit">😱 The convenient habit</h2> <p>To make deployments easier, it&rsquo;s extremely common to grant developer accounts <code>iam:PassRole</code> against <code>*</code> (a wildcard covering every role in the account). The reasoning is simple and, on its own, sounds harmless: developers need to attach an IAM role to whatever they deploy — a Lambda function, an EC2 instance — and wildcarding <code>PassRole</code> means nobody has to update a policy every time a new role gets created.</p>