GitHub Actions OIDC Token Security in 2026: Token Theft Patterns, pull_request_target Attacks & Complete Hardening GuideSécurité des Tokens OIDC GitHub Actions en 2026 : Vol de Tokens, Attaques pull_request_target & Guide de Durcissement Complet

On May 11, 2026, attackers published 84 malicious versions across 42 @tanstack/* npm packages in under six minutes — all signed with TanStack’s own trusted identity, with valid SLSA provenance. The weapon: a stolen GitHub Actions OIDC token, extracted from a runner mid-workflow after chaining a pull_request_target misconfiguration with cache poisoning. The attack didn’t compromise TanStack’s secrets vault. It hijacked the CI/CD pipeline itself.

Le 11 mai 2026, des attaquants ont publié 84 versions malveillantes dans 42 packages npm @tanstack/* en moins de six minutes — signées avec la propre identité de confiance de TanStack, avec une provenance SLSA valide. L’arme : un token OIDC GitHub Actions volé, extrait d’un runner en pleine exécution après avoir chainé une mauvaise configuration pull_request_target avec un empoisonnement de cache. L’attaque n’a pas compromis le coffre de secrets de TanStack. Elle a détourné le pipeline CI/CD lui-même.

This incident didn’t happen in isolation. GitHub Actions has become the most targeted layer of the modern software supply chain: 23,000+ repositories compromised via tj-actions/changed-files in March 2025, 75 of 76 trivy-action tags force-pushed in March 2026, and an AI-powered bot systematically scanning public repos for exploitable pull_request_target workflows across seven days in February 2026. This guide covers every major attack pattern, the GitHub 2026 Security Roadmap, and a practical hardening checklist you can apply today.

Cet incident n’est pas isolé. GitHub Actions est devenu la couche la plus ciblée de la chaîne d’approvisionnement logicielle moderne : plus de 23 000 dépôts compromis via tj-actions/changed-files en mars 2025, 75 des 76 tags trivy-action réécrits de force en mars 2026, et un bot automatisé par IA qui a scanné systématiquement les dépôts publics pendant sept jours en février 2026. Ce guide couvre chaque pattern d’attaque majeur, la Roadmap Sécurité GitHub 2026 et une check-list de durcissement applicable dès aujourd’hui.

The GitHub Actions Attack Epidemic: 2025–2026 in Review

L’Épidémie d’Attaques GitHub Actions : Bilan 2025–2026

GitHub Actions went from a convenient automation layer to a primary supply chain attack surface in 18 months. Three incidents defined the threat landscape before TanStack.

GitHub Actions est passé d’une couche d’automatisation pratique à une surface d’attaque supply chain primaire en 18 mois. Trois incidents ont défini le paysage des menaces avant TanStack.

tj-actions/changed-files & reviewdog (March 2025)

tj-actions/changed-files & reviewdog (mars 2025)

Between March 10 and 14, 2025, an attacker injected malicious code into tj-actions/changed-files (CVE-2025-30066, CVSS 8.6), a GitHub Action used by over 23,000 repositories. The compromised action dumped CI runner memory — containing workflow secrets — directly into workflow logs. On public repositories, those logs are visible to everyone. The same attacker simultaneously compromised reviewdog/action-setup (CVE-2025-30154). CISA issued an alert within 48 hours. Despite 23,000+ repos in the blast radius, active secret exfiltration was confirmed in 218 repositories during the compromise window, traced back to a targeted attack on Coinbase that escalated into a broad campaign.

Entre le 10 et le 14 mars 2025, un attaquant a injecté du code malveillant dans tj-actions/changed-files (CVE-2025-30066, CVSS 8.6), une Action GitHub utilisée par plus de 23 000 dépôts. L’action compromise vidait la mémoire du runner CI — contenant les secrets de workflow — directement dans les logs. Sur les dépôts publics, ces logs sont visibles par tout le monde. Le même attaquant a simultanément compromis reviewdog/action-setup (CVE-2025-30154). La CISA a émis une alerte en 48 heures. Malgré 23 000+ dépôts dans le rayon d’action, l’exfiltration active de secrets a été confirmée dans 218 dépôts, remontée à une attaque ciblée sur Coinbase qui a évolué en campagne large.

trivy-action Hijack via Force-Push (March 2026)

Hijack de trivy-action via Force-Push (mars 2026)

In March 2026, the TeamPCP threat actor force-pushed malicious commits to 75 of 76 version tags of trivy-action, the popular container vulnerability scanner used by over 10,000 CI/CD pipelines. Every pipeline that referenced a mutable tag — uses: aquasecurity/trivy-action@v0.28.0 instead of a pinned SHA — silently executed attacker-controlled code. The incident exposed a fundamental weakness: version tags in GitHub Actions are mutable by default and can be rewritten at any time by whoever controls the upstream repository.

En mars 2026, l’acteur de menace TeamPCP a réécrit de force les commits de 75 des 76 tags de version de trivy-action, le scanner de vulnérabilités de containers utilisé par plus de 10 000 pipelines CI/CD. Chaque pipeline référençant un tag mutable — uses: aquasecurity/trivy-action@v0.28.0 plutôt qu’un SHA piné — a silencieusement exécuté du code contrôlé par l’attaquant. L’incident a exposé une faiblesse fondamentale : les tags de version dans GitHub Actions sont mutables par défaut et peuvent être réécrits à tout moment par celui qui contrôle le dépôt upstream.

AI-Powered Automated Scanning (February 2026)

Scan Automatisé par IA (février 2026)

Between February 21 and 28, 2026, researchers documented an AI-powered bot systematically scanning public GitHub repositories for exploitable CI/CD workflow patterns and launching automated attacks using five distinct exploitation techniques, including pull_request_target Pwn Request and cache poisoning. The bot opened hundreds of pull requests across discovered targets in a single day, automating attacks that previously required skilled manual research. This industrialization of GitHub Actions exploitation means that workflow misconfigurations that were once “theoretical risks” are now reliably found and exploited at scale.

Entre le 21 et le 28 février 2026, des chercheurs ont documenté un bot piloté par IA qui scannait systématiquement les dépôts publics GitHub pour trouver des patterns CI/CD exploitables et lançait des attaques automatisées avec cinq techniques d’exploitation distinctes, dont le Pwn Request pull_request_target et l’empoisonnement de cache. Le bot ouvrait des centaines de pull requests sur les cibles découvertes en une seule journée. Cette industrialisation de l’exploitation GitHub Actions signifie que les mauvaises configurations de workflows qui étaient autrefois des “risques théoriques” sont maintenant détectées et exploitées à grande échelle.

How GitHub Actions OIDC Tokens Work — and How They Get Stolen

Comment Fonctionnent les Tokens OIDC GitHub Actions — et Comment Ils Sont Volés

OpenID Connect (OIDC) in GitHub Actions lets your workflow request short-lived tokens directly from cloud providers (AWS, Azure, GCP) or package registries (npm, PyPI) without storing long-lived credentials as GitHub Secrets. The token is scoped to a single job, valid for minutes, and cryptographically bound to the repository, branch, and workflow that requested it. When configured correctly, it eliminates the static-credential attack surface: there are no credentials to steal from a secrets vault because they never exist long-term.

OpenID Connect (OIDC) dans GitHub Actions permet à votre workflow de demander des tokens à courte durée de vie directement aux fournisseurs cloud (AWS, Azure, GCP) ou aux registres de packages (npm, PyPI) sans stocker des identifiants long-terme comme GitHub Secrets. Le token est limité à un seul job, valide quelques minutes, et cryptographiquement lié au dépôt, à la branche et au workflow qui l’a demandé. Correctement configuré, il élimine la surface d’attaque des identifiants statiques : il n’y a pas d’identifiants à voler dans un coffre de secrets car ils n’existent jamais longtemps.

To request an OIDC token, a workflow job needs permissions: id-token: write. This grants the job the ability to call GitHub’s OIDC provider endpoint and receive a signed JWT containing claims about the execution context (repository, branch, workflow file, environment). The token is then exchanged with the target cloud provider for a scoped access credential.

Pour demander un token OIDC, un job de workflow a besoin de permissions: id-token: write. Cela permet au job d’appeler le point de terminaison du fournisseur OIDC de GitHub et de recevoir un JWT signé contenant des claims sur le contexte d’exécution (dépôt, branche, fichier workflow, environnement). Le token est ensuite échangé avec le fournisseur cloud cible contre un identifiant d’accès limité.

The problem is not OIDC itself — it’s how it interacts with GitHub Actions’ trust model. If an attacker can execute code inside a privileged workflow job (one that has id-token: write), they can call the OIDC endpoint themselves and obtain a valid token. The attacker doesn’t need to know any secrets — they just need to run code in the right context. This is exactly what happened in the TanStack incident: a pull_request_target misconfiguration let attacker-controlled code run in the base repository’s context, where it could extract the OIDC token used to publish to npm.

Le problème n’est pas OIDC lui-même — c’est la façon dont il interagit avec le modèle de confiance de GitHub Actions. Si un attaquant peut exécuter du code dans un job de workflow privilégié (celui qui a id-token: write), il peut appeler lui-même le point de terminaison OIDC et obtenir un token valide. L’attaquant n’a pas besoin de connaître des secrets — il doit juste exécuter du code dans le bon contexte. C’est exactement ce qui s’est passé lors de l’incident TanStack : une mauvaise configuration pull_request_target a laissé du code contrôlé par l’attaquant s’exécuter dans le contexte du dépôt de base, où il a pu extraire le token OIDC utilisé pour publier sur npm.

Vulnerable vs. Safe OIDC Permission Scoping

Permissions OIDC Vulnérables vs. Sûres

# VULNERABLE: id-token: write at workflow level
# Any job in this workflow can request an OIDC token
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4  # attacker controls code here
      - run: npm test

  publish:
    needs: build
    steps:
      - run: npm publish  # OIDC token already obtainable from "build" job

---

# SAFE: id-token: write scoped to the specific job that needs it
permissions:
  contents: read  # deny id-token at workflow level

jobs:
  build:
    runs-on: ubuntu-latest
    # No id-token permission here
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  publish:
    needs: build
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    permissions:
      id-token: write  # granted only to this job
    steps:
      - uses: actions/setup-node@v4
      - run: npm publish

The pull_request_target Attack Chain Explained

La Chaîne d’Attaque pull_request_target Expliquée

pull_request_target was introduced to allow workflows to safely access repository secrets when triggered by pull requests from forks. Unlike pull_request, which runs in the fork’s context with read-only permissions, pull_request_target runs in the base repository’s context with full access to secrets and OIDC tokens. The intended use case is auto-labeling, comment posting, or CLA checks — operations that read PR metadata but never execute untrusted code. The attack surface opens the moment you combine pull_request_target with actions/checkout on the PR’s head ref.

pull_request_target a été introduit pour permettre aux workflows d’accéder en toute sécurité aux secrets du dépôt lors des pull requests provenant de forks. Contrairement à pull_request qui s’exécute dans le contexte du fork avec des permissions en lecture seule, pull_request_target s’exécute dans le contexte du dépôt de base avec un accès complet aux secrets et aux tokens OIDC. Le cas d’usage prévu est l’étiquetage automatique, les commentaires ou les vérifications CLA — des opérations qui lisent les métadonnées de PR sans jamais exécuter de code non-fiable. La surface d’attaque s’ouvre dès que vous combinez pull_request_target avec actions/checkout sur le head ref de la PR.

The TanStack attack (CVE-2026-45321) chained three techniques:

L’attaque TanStack (CVE-2026-45321) a chainé trois techniques :

1. Pwn Request — A pull request from a fork included a modified workflow that checked out the fork’s code under pull_request_target, giving it access to the base repository’s privileged context.
2. Cache Poisoning — The attacker poisoned the GitHub Actions cache across the fork→base trust boundary, injecting a malicious build artifact that persisted into subsequent legitimate runs.
3. OIDC Token Extraction — With code execution in the privileged job context, the attacker called GitHub’s OIDC endpoint (ACTIONS_ID_TOKEN_REQUEST_URL), obtained a valid npm publishing token, and used it to publish 84 malicious package versions in approximately six minutes.
4. Pwn Request — Une pull request depuis un fork incluait un workflow modifié qui checkoutait le code du fork sous pull_request_target, lui donnant accès au contexte privilégié du dépôt de base.
5. Empoisonnement de Cache — L’attaquant a empoisonné le cache GitHub Actions à travers la limite de confiance fork→base, injectant un artefact de build malveillant qui a persisté dans les exécutions légitimes suivantes.
6. Extraction du Token OIDC — Avec l’exécution de code dans le contexte du job privilégié, l’attaquant a appelé le point de terminaison OIDC de GitHub (ACTIONS_ID_TOKEN_REQUEST_URL), obtenu un token de publication npm valide et l’a utilisé pour publier 84 versions malveillantes de packages en environ six minutes.

# VULNERABLE: pull_request_target + checkout of PR head = Pwn Request
on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # OIDC access in a job that runs attacker code
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # DANGER: checks out fork code
      - run: npm test  # runs attacker-controlled test scripts

---

# SAFE: split into two workflows
# Workflow 1: runs on pull_request (fork context, no secrets)
on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

# Workflow 2: runs on workflow_run after CI passes (base context, can access secrets)
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  post-ci:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    permissions:
      id-token: write
    steps:
      - run: echo "Safe to publish"

GitHub’s 2026 Actions Security Roadmap: What’s Already Shipped

La Roadmap Sécurité GitHub Actions 2026 : Ce Qui Est Déjà Livré

GitHub published a comprehensive 2026 Security Roadmap for GitHub Actions in response to the wave of supply chain incidents. Several features have already reached general availability or public preview as of May 2026.

GitHub a publié une Roadmap Sécurité 2026 complète pour GitHub Actions en réponse à la vague d’incidents supply chain. Plusieurs fonctionnalités ont déjà atteint la disponibilité générale ou la pré-version publique en mai 2026.

1. Immutable Subject Claims (GA: April 23, 2026)

1. Claims Subject Immuables (GA : 23 avril 2026)

GitHub’s OIDC tokens now support immutable subject claims, preventing attackers from forging or manipulating the sub claim used by cloud providers to verify workflow identity. This closes an attack vector where crafted repository names or branch names could bypass OIDC trust policy matching at the cloud provider level.

Les tokens OIDC de GitHub supportent maintenant des claims subject immuables, empêchant les attaquants de forger ou manipuler le claim sub utilisé par les fournisseurs cloud pour vérifier l’identité du workflow. Cela ferme un vecteur d’attaque où des noms de dépôts ou de branches manipulés pouvaient contourner la correspondance de politique de confiance OIDC du côté du fournisseur cloud.

2. Repository Custom Properties as OIDC Claims (March 12, 2026)

2. Propriétés Custom du Dépôt comme Claims OIDC (12 mars 2026)

Organization admins can now include repository custom properties (e.g., business_unit, data_classification, environment_tier) as claims in OIDC tokens, enabling attribute-based access control (ABAC) policies in cloud providers and artifact registries. Instead of hard-coding allowed repository names in IAM policies, you can drive access decisions from repository metadata.

Les administrateurs d’organisation peuvent maintenant inclure des propriétés custom de dépôt (ex : business_unit, data_classification, environment_tier) comme claims dans les tokens OIDC, activant des politiques ABAC (Attribute-Based Access Control) dans les fournisseurs cloud et les registres d’artefacts. Plutôt que d’encoder en dur des noms de dépôts autorisés dans des politiques IAM, vous pouvez piloter les décisions d’accès depuis les métadonnées du dépôt.

3. Workflow Dependency Locking (Public Preview 2026)

3. Verrouillage des Dépendances de Workflow (Preview 2026)

GitHub is adding a dependencies section to workflow files that locks direct and transitive Action dependencies to specific commit SHAs, verified before each job executes. This turns Action dependencies from mutable runtime references (tags, branches) into something closer to a managed dependency graph — changes appear as reviewable diffs in pull requests. This feature directly addresses the trivy-action and tj-actions attack vectors.

GitHub ajoute une section dependencies aux fichiers de workflow qui verrouille les dépendances d’Action directes et transitives sur des SHA de commit spécifiques, vérifiées avant chaque exécution de job. Cela transforme les dépendances d’Action de références mutables en temps réel (tags, branches) en quelque chose ressemblant à un graphe de dépendances géré — les changements apparaissent comme des diffs reviewables dans les pull requests. Cette fonctionnalité adresse directement les vecteurs d’attaque trivy-action et tj-actions.

4. Layer 7 Native Egress Firewall (Planned 2026)

4. Pare-feu de Sortie Natif Layer 7 (Prévu 2026)

GitHub is shipping a Layer 7 egress firewall for hosted runners that operates outside the runner VM. Even if an attacker gains root access inside the runner, they cannot disable or bypass the firewall. Organizations can define allowlists of permitted egress destinations, with an observe-first mode to collect real traffic data before activating enforcement — preventing accidental breakage of legitimate CI dependencies.

GitHub déploie un pare-feu de sortie Layer 7 pour les runners hébergés qui opère en dehors de la VM du runner. Même si un attaquant obtient un accès root à l’intérieur du runner, il ne peut pas désactiver ou contourner le pare-feu. Les organisations peuvent définir des listes blanches de destinations de sortie autorisées, avec un mode d’observation d’abord pour collecter les données de trafic réel avant d’activer l’application — évitant toute rupture accidentelle de dépendances CI légitimes.

5. Scoped Secrets (Planned 2026)

5. Secrets Limités (Prévu 2026)

Currently, GitHub Secrets are scoped at repository or organization level, making them flow broadly through all jobs in a workflow. Scoped Secrets will let you bind credentials to specific execution contexts: a particular branch, environment, workflow path, or trusted reusable workflow. A publishing secret that only flows to the publish job running on main cannot be exfiltrated from a build job running on a PR branch.

Actuellement, les GitHub Secrets ont une portée au niveau du dépôt ou de l’organisation, ce qui les fait circuler largement à travers tous les jobs d’un workflow. Les Scoped Secrets permettront de lier les identifiants à des contextes d’exécution spécifiques : une branche particulière, un environnement, un chemin de workflow ou un workflow réutilisable de confiance. Un secret de publication qui ne circule que vers le job publish s’exécutant sur main ne peut pas être exfiltré depuis un job build s’exécutant sur une branche de PR.

Complete GitHub Actions Hardening Checklist for 2026

Check-list Complète de Durcissement GitHub Actions pour 2026

Apply these controls in order of impact. Controls 1–4 address the highest-severity attack vectors documented in 2025–2026 incidents.

Appliquez ces contrôles par ordre d’impact. Les contrôles 1–4 adressent les vecteurs d’attaque les plus sévères documentés dans les incidents 2025–2026.

# Instead of:
uses: actions/checkout@v4

# Use:
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

# NEVER do this in a pull_request_target workflow:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
  with:
    ref: ${{ github.event.pull_request.head.sha }}

# If you must use pull_request_target, never run untrusted code
# Use workflow_run pattern to separate CI from privileged jobs

# Set restrictive defaults at workflow level
permissions:
  contents: read  # deny id-token by default

jobs:
  publish:
    # Only the job that needs to publish gets write access
    if: github.ref == 'refs/heads/main'
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/setup-node@cdca7365b2dadb8aad0a33bc7601856ffabcc48e  # v4
      - run: npm publish

// AWS IAM Trust Policy — pin to specific repo, branch AND workflow
{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:sub":
        "repo:myorg/myrepo:ref:refs/heads/main:workflow:.github/workflows/publish.yml",
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    }
  }
}

# Cache keys must include a hash of the input files, not just branch/PR
- uses: actions/cache@5a3ec84eff668545956fd18022155c47e93e2684  # v4
  with:
    path: node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    # Explicit restore-keys that don't cross trust boundaries:
    restore-keys: |
      ${{ runner.os }}-node-${{ github.sha }}-

- name: Lint GitHub Actions workflows
  uses: raven-actions/actionlint@01fce4f43a270a612932d2e7a1b2d3da4e25a232  # v2
  # Detects: pull_request_target + checkout, missing SHA pins,
  # over-scoped permissions, expression injection patterns

Frequently Asked Questions

Questions Fréquentes

grep -rn "uses:" .github/workflows/ | grep -v "@[0-9a-f]\{40\}" | grep -v "^#"
# Output: every Action reference not pinned to a full 40-char SHA

version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly
    groups:
      actions:
        patterns: ["*"]