iam:CreatePolicyVersion Privilege Escalation

A principal allowed iam:CreatePolicyVersion on a managed policy can publish a brand-new policy version with full administrator permissions and set it as the default in a single call. Because the new version becomes the active one immediately, any identity attached to that policy — including the attacker — instantly gains those permissions.

Permissions an attacker needs

iam:CreatePolicyVersion

How the escalation works

The attacker identifies a customer-managed policy they (or a role they hold) are attached to.
They call CreatePolicyVersion with --set-as-default and a document granting Action "*" on Resource "*".
AWS activates the new version immediately. The attacker now has administrator access through the policy they were already attached to.

Example vulnerable policy

A policy like this grants the dangerous permission. Paste your own policy into the free AI-Powered IAM analyzer to see if you are exposed.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:CreatePolicyVersion",
      "Resource": "*"
    }
  ]
}

Example exploitation

For illustration only — run against accounts you own or are authorized to test.

aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/example \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
  --set-as-default

How to detect and prevent it

Never grant iam:CreatePolicyVersion on Resource "*". Scope it to specific, non-privileged policy ARNs only when genuinely required.
Apply a permissions boundary so newly created policy versions cannot exceed the boundary, even if the document says Action "*".
Alert on CreatePolicyVersion calls in CloudTrail, especially where SetAsDefault is true.

FAQ

Why is iam:CreatePolicyVersion dangerous?

It lets a principal rewrite the contents of a policy they are attached to and activate the change instantly, which is equivalent to granting themselves whatever permissions the new version contains — including full admin.

Does a permissions boundary stop it?

A permissions boundary on the attacker’s identity still caps their effective permissions, so the new admin policy is constrained by the boundary. This is the most reliable mitigation when the action cannot be removed entirely.

Related escalation methods

Check your IAM policies for this — free

Shieldly's AI-Powered analyzer flags privilege-escalation paths, wildcards, and risky PassRole in seconds. No signup, no AWS credentials. Also ships as CLI, VS Code extension, GitHub Action, and CDK Guard.

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.