Method
Severity
What an attacker gains
Primary fix
Critical
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.
Never grant iam:CreatePolicyVersion on Resource "*". Scope it to specific, non-privileged policy ARNs only when genuinely required.
High
Managed policies keep up to five versions. iam:SetDefaultPolicyVersion lets a principal switch the active version to any existing one. If an older, more permissive version is still stored on the policy, the attacker can roll the policy back to it and inherit those broader permissions.
Delete old policy versions after editing a policy so a permissive version cannot be reactivated.
Critical
iam:AttachUserPolicy lets a principal attach any managed policy to an IAM user. If the attacker can target their own user, they simply attach AdministratorAccess to themselves and gain full control of the account.
Restrict iam:AttachUserPolicy to specific users and add a condition limiting which policy ARNs can be attached (iam:PolicyARN).
Critical
iam:PutUserPolicy writes an inline policy directly onto an IAM user. Unlike attaching a managed policy, the attacker authors the document themselves, so they can grant any permission to their own user without depending on an existing policy.
Avoid granting iam:PutUserPolicy except to tightly controlled automation, and scope it to specific users.
High
iam:AddUserToGroup lets a principal add an IAM user to any group. If a privileged group exists (for example one with AdministratorAccess attached), the attacker adds their own user to it and inherits the group’s permissions.
Scope iam:AddUserToGroup to specific, non-privileged groups via resource ARNs.
High
iam:CreateAccessKey on Resource "*" lets a principal mint long-lived access keys for any IAM user, including more privileged ones. The attacker creates a key for a powerful user and then operates with that user’s permissions.
Scope iam:CreateAccessKey to the calling user only, using a condition like aws:username matching the principal, or remove it entirely in favor of short-lived role credentials.
High
A login profile is the console password for an IAM user. iam:CreateLoginProfile sets one for a user that has none; iam:UpdateLoginProfile resets an existing one. Either lets an attacker set a known password on a more privileged user and log into the console as them.
Scope these actions to the caller’s own user ARN so a user cannot set passwords for others.
Critical
iam:PassRole lets a principal hand an existing role to an AWS service. Combined with lambda:CreateFunction and a way to invoke the function, an attacker can create a Lambda that runs as a far more privileged role, then execute code with that role’s permissions.
Scope iam:PassRole to specific role ARNs the principal legitimately needs, never Resource "*".
Critical
With iam:PassRole and ec2:RunInstances, an attacker can launch an EC2 instance attached to a privileged instance profile, then read that role’s temporary credentials from the instance metadata service and use them anywhere.
Scope iam:PassRole to specific instance-profile roles and add iam:PassedToService = ec2.amazonaws.com.
Critical
iam:UpdateAssumeRolePolicy rewrites a role’s trust policy — the document that decides who may assume it. An attacker can point a privileged role’s trust policy at their own principal, then assume the role and take on its permissions.
Scope iam:UpdateAssumeRolePolicy to specific, non-privileged role ARNs only.
High
lambda:UpdateFunctionCode lets a principal overwrite the code of an existing Lambda function. If that function already runs as a more privileged execution role, the attacker replaces the code with their own and inherits the role’s permissions the next time it runs — no PassRole required.
Scope lambda:UpdateFunctionCode to specific function ARNs the principal owns, never Resource "*".
Critical
A Glue development endpoint runs as an IAM role and gives interactive (SSH/notebook) access. With iam:PassRole and glue:CreateDevEndpoint, an attacker creates a dev endpoint backed by a privileged role and then reads that role’s credentials from inside the endpoint.
Scope iam:PassRole to specific roles and add iam:PassedToService = glue.amazonaws.com.
Critical
CloudFormation can act with a service role you pass to it, performing every action in the template as that role. With iam:PassRole and cloudformation:CreateStack, an attacker passes a privileged role and deploys a template that does whatever that role allows — including granting themselves admin.
Scope iam:PassRole to specific roles and add iam:PassedToService = cloudformation.amazonaws.com.
Critical
A SageMaker notebook instance runs as an IAM role and gives the user an interactive Jupyter shell. With iam:PassRole and sagemaker:CreateNotebookInstance, an attacker launches a notebook backed by a privileged role and reads that role’s credentials from inside the instance metadata.
Scope iam:PassRole to specific roles and add iam:PassedToService = sagemaker.amazonaws.com.
Critical
A CodeBuild project runs build commands as an IAM service role. With iam:PassRole, codebuild:CreateProject, and codebuild:StartBuild, an attacker creates a project backed by a privileged role and runs arbitrary commands as that role — including exfiltrating its credentials.
Scope iam:PassRole to specific roles and add iam:PassedToService = codebuild.amazonaws.com.
High
AWS Data Pipeline runs activities on EC2 resources that assume a passed IAM role. With iam:PassRole plus datapipeline:CreatePipeline and PutPipelineDefinition, an attacker defines a pipeline that runs shell commands on a resource backed by a privileged role, then reads that role’s credentials.
Scope iam:PassRole to specific roles and add an iam:PassedToService condition for the pipeline resource role.