Skip to the page
CloudArqStart free

The one-character fix that lets other organizations into your cloud

When new repositories stopped matching an old trust condition in July, the quickest repair widened it. Here is how to check yours.

If your GitHub Actions workflows deploy to AWS without stored keys, an IAM role's trust policy decides which workflows may assume it. Usually that means a condition on the token's sub claim. GitHub changed that claim in July.

What changed. GitHub's OIDC reference:

"…repositories created after July 15, 2026 now use an immutable default subject format that includes both the owner ID and repository ID."

The old default subject, and the new one, as GitHub documents them:

repo:octo-org/octo-repo:ref:refs/heads/main              (before 15 July)
repo:octo-org@123456/octo-repo@456789:ref:refs/heads/main (created after)

Older repositories keep the old format "unless you opt in to immutable subject claims", at the organization or repository level.

What it does to conditions you already have. Many trust policies admit a whole organization with StringLike:

"token.actions.githubusercontent.com:sub": "repo:octo-org/*"

That pattern needs repo:octo-org/ at the start. A token from a repository created after 15 July starts repo:octo-org@123456/, so it doesn't match. Deploys from new repositories fail, and the policy has to change.

The quick fix is the dangerous one. Drop the slash, and the new repositories match again:

"token.actions.githubusercontent.com:sub": "repo:octo-org*"

So does repo:octo-org-anything/…: a token from any organization whose name starts with octo-org. Anyone can create such an organization on GitHub.

AWS won't catch it. For GitHub's issuer, IAM refuses only the worst case, and only when you save a policy:

"IAM checks the role trust policy condition to verify that the condition key token.actions.githubusercontent.com:sub is present and that its value is not solely a wildcard character (* and ?) or null."

repo:octo-org* is not solely a wildcard, so it passes. For the policies you already have, AWS doesn't look at all:

"Identity-provider controls will not be evaluated by IAM for existing OIDC role trust policies."

Names were already a problem. AWS's condition-key reference:

"Policies that rely solely on mutable name-based claims (such as repository or actor) could grant access to unintended identities."

And GitHub's own documentation on renaming an organization:

"After changing your organization's name, your old organization name becomes available for someone else to claim."

GitHub retires the old owner-and-repository pair for repositories with Marketplace actions or enough use. For the rest, a condition written against a name trusts whoever holds that name next. The immutable subject exists to end that. It only helps where you use it.

What a fix looks like:

  1. Opt the organization in to immutable subject claims.
  2. Write each condition against the exact owner and repository, IDs included, and the branch or environment that deploys, for example repo:octo-org@123456/octo-repo@456789:environment:production.
  3. Never end an organization's name in *.
  4. Read your old roles again. Nothing on AWS's side will.

Checking yours. If you want a second pair of eyes on one of your trust policies, send it to us with the account IDs stripped. We'll tell you who it admits, and why.

We're building CloudArq, which works out who outside your company can get into your cloud accounts.

Sources (each checked on 19 October 2026):