Loading story…
Researchers and cloud security vendors documented a recurring AWS IAM trust policy flaw in OIDC integrations for Terraform Cloud and GitHub Actions that can let unauthorized external workloads assume customer roles. In both cases, the issue stems from missing or overly broad sub conditions in resource-based trust policies: older AWS-created Terraform Cloud policies could omit app.terraform.io:sub, and GitHub Actions deployments often lacked the repository-specific sub restriction. That weakness meant any valid identity token from the trusted OIDC provider could potentially satisfy the role trust and gain access to the victim AWS account.
Public writeups showed how attackers could exploit broad Terraform Cloud patterns by creating a matching organization, project, and workspace, then using Terraform to provision a backdoored IAM role with AdministratorAccess. The GitHub Actions variant was amplified by copied example code and Terraform JSON duplicate-key behavior, prompting coordinated disclosures by researchers, Wiz, Datadog, AWS, and HashiCorp. AWS updated its console behavior, notified affected customers, blocked creation of some new misconfigured policies, and set enforcement deadlines, while defenders were urged to audit OIDC trust relationships, require precise subject claims, and use controls such as Resource Control Policies and detection rules to prevent arbitrary role assumption.
Map this exposure pattern across your cloud, code, and identities.
10 events from the most recent confirmed update back to the earliest known activity.
A February 2025 technical write-up showed that Terraform Cloud OIDC IAM roles can still be exploitable when administrators use wildcard patterns in the Terraform Cloud organization field within the `sub` condition. The article demonstrated a proof-of-concept path to assume the role and create a backdoored AdministratorAccess IAM role, and noted Resource Control Policies as a mitigation.
AWS's announced enforcement timeline for older Terraform Cloud OIDC trust policies culminated on February 7, 2025. These older AWS-created policies had omitted the required `app.terraform.io:sub` condition, which could otherwise let any valid Terraform Cloud identity token assume the role.
By August 2024, AWS had addressed default-risk concerns involving Terraform Cloud OIDC IAM role trust policies, reflecting changes to how these integrations were configured and constrained. This marked public reporting that the Terraform-related default behavior had been addressed.
AWS planned enforcement for existing GitHub Actions OIDC trust policies missing the required `sub` restriction, following earlier customer notifications and changes to prevent creation of new vulnerable policies. The enforcement date cited was November 1, 2023.
Wiz published a summary of the GitHub Actions OIDC misconfiguration and the coordinated response, noting that AWS had improved its console wizard, blocked creation of new misconfigured trust policies, and planned enforcement for existing ones on November 1. HashiCorp also issued a security bulletin and worked on warnings and Semgrep detection rules.
AWS notified affected customers by email about the GitHub Actions OIDC trust policy issue, warning them about roles missing the required repository restriction. The first customer notification was sent on August 18, 2023.
In 2023, multiple researchers and vendors including Wiz and Datadog investigated the GitHub Actions OIDC trust policy problem, notified affected organizations, and released research and tooling to help identify vulnerable roles.
During 2023, security researchers found that many AWS IAM roles trusting GitHub Actions via OIDC lacked the required `sub` condition, allowing arbitrary GitHub repositories to assume affected roles. The issue was linked to copied example code and Terraform JSON handling of duplicate keys.
GitHub documented an immutable GitHub Actions OIDC subject-claim format that embeds immutable owner and repository IDs, for repositories created after July 15, 2026 or those that opt in. The format is unavailable on GitHub Enterprise Server and can be used in AWS IAM trust-policy restrictions.
Wiz detailed how missing or improperly scoped OIDC trust-policy conditions can enable unauthorized AWS IAM role assumption across integrations including Microsoft Defender, GitLab, Bitbucket, DoIT, env0, and EKS. It noted that providers may require controls other than `sub`, such as `sts:RoleSessionName` or `aws:RequestTag`, and advised validating each integration against vendor documentation.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
9 references tracked. Mallory keeps watching after this page renders.
docs.github.com
Open sourcedocs.aws.amazon.com
Open sourcerezonate.io
Open sourcehackingthe.cloud
Open sourcewiz.io
Open sourcehacktodef.com
Open sourcewiz.io
Open sourcesecuritylabs.datadoghq.com
Open sourcemedium.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A GitHub Actions supply-chain attack compromised widely used actions including **`tj-actions/changed-files`** and components in the **reviewdog** ecosystem after attackers abused insecure workflow patterns to steal maintainer personal access tokens and move trusted tags to malicious code. Investigators traced the intrusion to a malicious pull request against the SpotBugs ecosystem using the dangerous **`pull_request_target`** trigger, which exposed a maintainer token that was later used to implant another workflow, steal additional tokens, and overwrite action tags. The malicious action chain leaked CI/CD secrets and environment variables by dumping runner memory into workflow logs, affecting downstream repositories at scale and including a targeted attempt involving Coinbase, which said the incident did not damage its assets. Separate research showed that GitHub Actions integrations with Azure via OpenID Connect can also be undermined when federated identity credentials trust unsafe subject identifiers such as unprotected branches, tags, environments, or especially **`pull_request`**, allowing contributors to obtain Azure access tokens under weak configurations. The analysis found that even reusable workflows constrained with **`job_workflow_ref`** can still expose cloud access if the workflow permits caller-controlled code execution through mechanisms such as script injection or Terraform plan behavior. Together, the findings show that GitHub Actions trust boundaries can fail both in software supply chains and cloud federation unless organizations pin actions to commit SHAs, protect refs, minimize token permissions, validate reusable workflows, and enforce least-privilege access to secrets and cloud roles.
Aug 19, 2026
Datadog Security Labs disclosed **CVE-2024-28056**, an AWS Amplify flaw that left Cognito-linked IAM roles vulnerable to takeover when trust policies omitted the required Cognito identity pool audience restriction. The issue affected two Amplify variants: older CLI-created projects with insecure default trust policies and projects where the authentication component was later removed, leaving overly permissive roles behind. Researchers identified more than **8,000** public IAM role ARNs with recognizable Amplify naming patterns such as `authRole` and `unauthRole`, and showed that attackers could use Cognito Basic authflow together with STS to obtain short-lived credentials through ```text AssumeRoleWithWebIdentity ``` without additional authorization.
Jun 29, 2026
Security researchers at **Wiz** disclosed a critical **AWS CodeBuild** misconfiguration (dubbed **CodeBreach**) that could have enabled unauthenticated attackers to trigger CI builds from untrusted pull requests, access the build environment, and exfiltrate privileged credentials such as **GitHub admin tokens**. With those tokens, an attacker could have pushed malicious commits into AWS-managed open-source repositories—creating a high-impact **software supply chain** pathway that could have cascaded into widespread compromise, including risk to dependencies like the **AWS JavaScript SDK** and potentially components used by the **AWS Console** itself. AWS was notified on **2025-08-25** and remediated the issue in **September 2025**. The root cause was described as a weakness in CodeBuild’s webhook filtering logic intended to restrict which events/users can trigger builds; affected repositories used an `ACTOR_ID` regex filter that omitted the `^` and `$` anchors, allowing bypass of the intended match constraints. Reported impacted AWS-managed GitHub repositories included `aws-sdk-js-v3`, `aws-lc`, `amazon-corretto-crypto-provider`, and `awslabs/open-data-registry`, all configured to run builds on pull requests. Separate reporting on abuse of **self-hosted GitHub Actions runners** as backdoors (including the **Shai-Hulud** worm technique) is related at a thematic CI/CD level but does not describe the CodeBuild misconfiguration or the AWS repository takeover scenario.
Jun 29, 2026