GitHub Actions Supply Chain Security in 2026: Trivy Hijacked, prt-scan & How to Protect Your PipelinesSécurité Supply Chain GitHub Actions en 2026 : Trivy Hijacké, prt-scan & Comment Protéger vos Pipelines

On March 19, 2026, developers woke up to a nightmare: 82 tags of aquasecurity/trivy-action and setup-trivy had been silently force-pushed overnight with malicious code. Every pipeline that ran a Trivy security scan that day — the tool you use to catch vulnerabilities — was exfiltrating AWS keys, GCP credentials, Kubernetes tokens, SSH keys, and Docker configs to an attacker-controlled server. Over 10,000 CI/CD pipelines were exposed. Over 1,000 cloud environments were confirmed infected. This wasn't a theoretical risk. This was March 2026.

Le 19 mars 2026, les développeurs se sont réveillés face à un cauchemar : 82 tags de aquasecurity/trivy-action et setup-trivy avaient été silencieusement force-pushés la nuit précédente avec du code malveillant. Chaque pipeline qui avait lancé un scan de sécurité Trivy ce jour-là — l'outil que vous utilisez pour détecter les vulnérabilités — exfiltrait des clés AWS, identifiants GCP, tokens Kubernetes, clés SSH et configs Docker vers un serveur contrôlé par l'attaquant. Plus de 10 000 pipelines CI/CD ont été exposés. Plus de 1 000 environnements cloud ont été confirmés infectés. Ce n'était pas un risque théorique. C'était mars 2026.

The Trivy incident wasn't isolated. One year earlier, CVE-2025-30066 compromised tj-actions/changed-files across 23,000+ repositories. Weeks later, the AI-assisted prt-scan campaign submitted 500+ malicious PRs targeting misconfigurations in pull_request_target workflows. March 2026 became the month that proved: your GitHub Actions are your most dangerous dependency, and most teams treat them like trusted code.

L'incident Trivy n'était pas isolé. Un an plus tôt, CVE-2025-30066 avait compromis tj-actions/changed-files dans plus de 23 000 dépôts. Quelques semaines après, la campagne prt-scan assistée par IA a soumis plus de 500 PRs malveillantes ciblant des mauvaises configurations dans les workflows pull_request_target. Mars 2026 est devenu le mois qui a prouvé : vos GitHub Actions sont votre dépendance la plus dangereuse, et la plupart des équipes les traitent comme du code de confiance.

The Trivy Action Hijack: How TeamPCP Turned Your Security Scanner Against You

Le Hijack de Trivy Action : Comment TeamPCP a Retourné Votre Scanner de Sécurité Contre Vous

At 00:00 UTC on March 19, 2026, the threat actor group TeamPCP (also tracked as DeadCatx3, PCPcat, and ShellForce) began force-pushing malicious code to aquasecurity/trivy-action. By morning, 75 of 76 version tags had been replaced. Seven additional tags of setup-trivy were also compromised — 82 tags in total. The attack had two phases: the initial compromise of an Aqua Security maintainer account (method undisclosed), followed by automated poisoning of every tag.

À 00h00 UTC le 19 mars 2026, le groupe d'acteurs malveillants TeamPCP (également suivi sous les noms DeadCatx3, PCPcat et ShellForce) a commencé à force-pusher du code malveillant sur aquasecurity/trivy-action. Au matin, 75 des 76 tags de version avaient été remplacés. Sept tags supplémentaires de setup-trivy étaient également compromis — 82 tags au total. L'attaque s'est déroulée en deux phases : la compromission initiale d'un compte mainteneur Aqua Security (méthode non divulguée), suivie de l'empoisonnement automatisé de chaque tag.

The payload was sophisticated: a credential harvester encrypted with AES-256-CBC and RSA-4096 that silently extracted every secret it could find in the runner environment. AWS access keys, Google Cloud service account tokens, Azure credentials, Kubernetes kubeconfigs, SSH private keys, Docker registry credentials, Git tokens — everything was sent to a typosquatted C2 domain (scan.aquasecurtiy[.]org, note the misspelling). The whole operation happened inside the runner process, invisible to logs and standard monitoring.

Le payload était sophistiqué : un collecteur d'identifiants chiffré en AES-256-CBC avec hybridation RSA-4096 qui extrayait silencieusement tous les secrets accessibles dans l'environnement du runner. Clés AWS, tokens de comptes de service Google Cloud, identifiants Azure, kubeconfigs Kubernetes, clés SSH privées, identifiants de registres Docker, tokens Git — tout était envoyé vers un domaine C2 typosquatté (scan.aquasecurtiy[.]org, notez la faute d'orthographe). Toute l'opération se déroulait dans le processus du runner, invisible aux logs et au monitoring standard.

TeamPCP didn't stop at Trivy. Within four days, they extended the campaign to checkmarx/ast-github-action (v2.3.28), and LiteLLM on PyPI was compromised on March 24. Over 1,000 cloud environments were confirmed infected according to The Register, with Microsoft Security Blog publishing explicit guidance on detection and remediation.

TeamPCP ne s'est pas arrêté à Trivy. En quatre jours, ils ont étendu la campagne à checkmarx/ast-github-action (v2.3.28), et LiteLLM sur PyPI a été compromis le 24 mars. Plus de 1 000 environnements cloud ont été confirmés infectés selon The Register, Microsoft Security Blog ayant publié des directives explicites sur la détection et la remédiation.

CVE-2025-30066: The tj-actions Attack That Hit 23,000 Repos

CVE-2025-30066 : L'Attaque tj-actions Qui a Touché 23 000 Dépôts

Exactly one year before Trivy, another widely-used GitHub Action was silently compromised. tj-actions/changed-files — used in 23,000+ repositories to detect file changes between commits — was poisoned on March 12, 2025. The CVE received a CVSS score of 8.6 (High). All versions up to v45.0.7 were affected; v46.0.1 was the clean release.

Exactement un an avant Trivy, une autre GitHub Action largement utilisée a été silencieusement compromise. tj-actions/changed-files — utilisée dans plus de 23 000 dépôts pour détecter les changements de fichiers entre commits — a été empoisonnée le 12 mars 2025. Le CVE a reçu un score CVSS de 8.6 (High). Toutes les versions jusqu'à v45.0.7 étaient affectées ; v46.0.1 était la version propre.

The attack vector was a long supply chain: an attacker had stolen a GitHub Personal Access Token from the SpotBugs project on November 28, 2024 (three months earlier). That token had write access to reviewdog/action-setup. The attacker waited, then compromised reviewdog/action-setup via CVE-2025-30154, which in turn gave them access to tj-actions. The malicious commit (0e58ed8671d6b60d0890c21b07f8835ace038e67) injected code that scanned runner memory for secrets and wrote them to the workflow's public logs — where anyone could read them. Initial target was Coinbase's agentkit repository.

Le vecteur d'attaque était une longue chaîne supply chain : un attaquant avait volé un Personal Access Token GitHub du projet SpotBugs le 28 novembre 2024 (trois mois plus tôt). Ce token avait un accès en écriture sur reviewdog/action-setup. L'attaquant a attendu, puis compromis reviewdog/action-setup via CVE-2025-30154, ce qui lui a donné accès à tj-actions. Le commit malveillant (0e58ed8671d6b60d0890c21b07f8835ace038e67) a injecté du code qui scannait la mémoire du runner pour trouver des secrets et les écrivait dans les logs publics du workflow — là où n'importe qui pouvait les lire. La cible initiale était le dépôt agentkit de Coinbase.

CISA issued an alert. The window of risk: March 12, 2025 00:00 UTC through March 15, 2025 12:00 UTC. Any repo that ran tj-actions/changed-files in that window with secrets in the runner environment should have treated all those secrets as compromised.

La CISA a émis une alerte. La fenêtre de risque : du 12 mars 2025 00h00 UTC au 15 mars 2025 12h00 UTC. Tout dépôt ayant exécuté tj-actions/changed-files dans cette fenêtre avec des secrets dans l'environnement runner aurait dû traiter tous ces secrets comme compromis.

The prt-scan Campaign: AI-Assisted Supply Chain Attacks at Scale

La Campagne prt-scan : Attaques Supply Chain Assistées par IA à Grande Échelle

March 2026 brought a third vector: not a compromised action, but an attacker exploiting misconfigurations in your own workflows. Starting March 11, 2026, a single threat actor began submitting pull requests to open-source repositories — not random spam, but precisely crafted attacks targeting a specific GitHub Actions misconfiguration: pull_request_target.

Mars 2026 a apporté un troisième vecteur : non pas une action compromise, mais un attaquant exploitant des mauvaises configurations dans vos propres workflows. À partir du 11 mars 2026, un seul acteur malveillant a commencé à soumettre des pull requests sur des dépôts open-source — pas du spam aléatoire, mais des attaques précisément ciblées exploitant une mauvaise configuration spécifique de GitHub Actions : pull_request_target.

The attack scaled rapidly: 475+ PRs in a 26-hour window from a single account (ezmtebo), at a rate of ~7 PRs per hour sustained over 22 hours. Across 6 waves of activity, the actor submitted 500+ PRs total. PR titles were generic: "ci: update build configuration". Branch names followed the pattern prt-scan-{12-hex-chars}. Payloads were AI-generated and adapted to each target's language, framework, and test runner.

L'attaque a rapidement pris de l'ampleur : plus de 475 PRs en 26 heures depuis un seul compte (ezmtebo), à un rythme de ~7 PRs/heure soutenu pendant 22 heures. Sur 6 vagues d'activité, l'acteur a soumis plus de 500 PRs au total. Les titres de PR étaient génériques : "ci: update build configuration". Les noms de branches suivaient le modèle prt-scan-{12-hex-chars}. Les payloads étaient générés par IA et adaptés au langage, framework et test runner de chaque cible.

The success rate was under 10% — but the secrets stolen were real: AWS access keys, Cloudflare API tokens, Netlify authentication tokens. Two npm packages (@codfish/eslint-config, @codfish/actions) were compromised with 106 versions published. The exfiltration was clever: no C2 server contact. Secrets were sent either through GitHub's own API or directly to cloud metadata endpoints (link-local), making network blocking ineffective.

Le taux de réussite était inférieur à 10% — mais les secrets volés étaient réels : clés AWS, tokens API Cloudflare, tokens d'authentification Netlify. Deux packages npm (@codfish/eslint-config, @codfish/actions) ont été compromis avec 106 versions publiées. L'exfiltration était astucieuse : pas de contact de serveur C2. Les secrets étaient envoyés soit via l'API de GitHub lui-même, soit directement vers les endpoints de métadonnées cloud (link-local), rendant le blocage réseau inefficace.

The pull_request_target Trap: Why Your Workflow May Already Be Vulnerable

Le Piège pull_request_target : Pourquoi Votre Workflow Est Peut-être Déjà Vulnérable

The pull_request_target trigger was designed to let maintainers run workflows on external PRs with access to repository secrets — useful for comment bots and status updaters. The problem: if your workflow checks out or runs code from the fork's PR branch inside a pull_request_target trigger, an attacker submitting a PR can execute arbitrary code with full access to your production secrets.

Le trigger pull_request_target a été conçu pour permettre aux mainteneurs d'exécuter des workflows sur des PRs externes avec accès aux secrets du dépôt — utile pour les bots de commentaires et les mises à jour de statut. Le problème : si votre workflow checkout ou exécute du code depuis la branche PR du fork à l'intérieur d'un trigger pull_request_target, un attaquant soumettant une PR peut exécuter du code arbitraire avec un accès complet à vos secrets de production.

Over 100,000 GitHub repositories contain dangerous pull_request_target configurations. MITRE's mitre-attack/car, Splunk's security_content, and repositories from Microsoft, Google, NVIDIA, and DataDog were found vulnerable. The pattern is simple to check:

Plus de 100 000 dépôts GitHub contiennent des configurations pull_request_target dangereuses. Les dépôts mitre-attack/car de MITRE, security_content de Splunk, et des dépôts de Microsoft, Google, NVIDIA et DataDog ont été trouvés vulnérables. Le pattern est simple à vérifier :

# DANGEROUS: checks out PR code inside pull_request_target
on: pull_request_target
jobs:
  test:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # ← fork code!
      - run: npm test  # ← attacker controls this

# SAFE: separate job, no checkout of PR code
on: pull_request_target
jobs:
  comment-only:
    steps:
      - name: Post status
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment(...)
            # No checkout, no code execution from fork

The Fix: Pin Every GitHub Action to a Full Commit SHA

La Solution : Pinnez Chaque GitHub Action sur un SHA de Commit Complet

The root cause of the Trivy and tj-actions attacks was the same: both used mutable tags (@v3, @v2) that attackers could force-push to point at malicious commits. A version tag is not immutable. A commit SHA is.

La cause profonde des attaques Trivy et tj-actions était identique : les deux utilisaient des tags mutables (@v3, @v2) que les attaquants pouvaient force-pusher pour pointer vers des commits malveillants. Un tag de version n'est pas immuable. Un SHA de commit l'est.

GitHub's official recommendation: pin every action to a full 40-character commit SHA with a version comment for readability:

La recommandation officielle de GitHub : pinnez chaque action sur un SHA de commit complet de 40 caractères avec un commentaire de version pour la lisibilité :

# VULNERABLE: tag can be force-pushed
- uses: actions/checkout@v4
- uses: aquasecurity/trivy-action@master

# SECURE: SHA is immutable
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332  # v4.1.7
- uses: aquasecurity/trivy-action@dc78c41fbbfe63b0d5a07a4fc03fe1975b9498f4  # v0.30.0

An attacker who force-pushes a tag cannot change what SHA that SHA resolves to — they would need to rewrite Git history, which GitHub doesn't allow. Your workflow will only ever run the exact code that existed at that commit hash, regardless of what the tag now points to.

Un attaquant qui force-pushe un tag ne peut pas changer ce à quoi ce SHA correspond — il faudrait réécrire l'historique Git, ce que GitHub n'autorise pas. Votre workflow n'exécutera jamais que le code exact qui existait à ce hash de commit, peu importe vers quoi le tag pointe maintenant.

Keep SHAs Updated with Dependabot

Maintenez les SHAs à Jour avec Dependabot

SHA-pinning raises an immediate concern: how do you keep your actions up-to-date? The answer is Dependabot. As long as you include a version comment after the SHA, Dependabot reads it and submits automatic PRs when new versions are available:

Le pinning par SHA soulève une préoccupation immédiate : comment maintenir vos actions à jour ? La réponse est Dependabot. Tant que vous incluez un commentaire de version après le SHA, Dependabot le lit et soumet des PRs automatiques quand de nouvelles versions sont disponibles :

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot will then open PRs like: "Bump actions/checkout from 692973e to a5ac7e5 (v4.2.0)". You review and merge. Your SHA is always current, and always pinned.

Dependabot ouvrira ensuite des PRs du type : "Bump actions/checkout de 692973e à a5ac7e5 (v4.2.0)". Vous examinez et mergez. Votre SHA est toujours à jour, et toujours pinné.

GitHub's 2026 Security Roadmap: What's Coming for Actions

Roadmap Sécurité GitHub 2026 : Ce Qui Arrive pour les Actions

In direct response to the March 2026 incidents, GitHub published a 2026 security roadmap for Actions. Three features stand out for developers:

En réponse directe aux incidents de mars 2026, GitHub a publié une roadmap de sécurité 2026 pour Actions. Trois fonctionnalités se distinguent pour les développeurs :

1. Native workflow lockfile (dependencies: section). GitHub is adding a dependencies: block to workflow YAML files — analogous to go.mod + go.sum. Every direct and transitive action dependency will be locked to a SHA, verified at runtime. This is currently in public preview with GA expected within 6 months (from Q1 2026 announcement).

1. Lockfile de workflow natif (section dependencies:). GitHub ajoute un bloc dependencies: aux fichiers YAML de workflow — analogue à go.mod + go.sum. Chaque dépendance d'action directe et transitive sera verrouillée sur un SHA et vérifiée à l'exécution. Actuellement en preview publique, GA attendu dans 6 mois (annonce Q1 2026).

2. Organization-level SHA pinning policy. Since August 2025, GitHub Enterprise and organization admins can enforce SHA pinning as a mandatory policy. Any workflow that uses a tag or branch reference instead of a full SHA will be blocked by the runner. Enable it in Settings > Actions > General > Policies.

2. Politique de SHA pinning au niveau de l'organisation. Depuis août 2025, les admins GitHub Enterprise et d'organisation peuvent imposer le SHA pinning comme politique obligatoire. Tout workflow utilisant une référence de tag ou de branche au lieu d'un SHA complet sera bloqué par le runner. À activer dans Settings > Actions > General > Policies.

3. Egress firewall for hosted runners. GitHub is adding network-level egress control to GitHub-hosted runners, letting organizations define which outbound domains are allowed. This would have directly blocked the Trivy attack's C2 exfiltration to scan.aquasecurtiy[.]org.

3. Pare-feu d'egress pour les runners hébergés. GitHub ajoute un contrôle d'egress réseau aux runners hébergés par GitHub, permettant aux organisations de définir quels domaines sortants sont autorisés. Cela aurait directement bloqué l'exfiltration C2 de l'attaque Trivy vers scan.aquasecurtiy[.]org.

Complete GitHub Actions Security Hardening Checklist for 2026

Checklist Complète de Durcissement des GitHub Actions en 2026

The Real Problem: Only 7% of Projects Do This Correctly

Le Vrai Problème : Seulement 7% des Projets Le Font Correctement

A March 2025 study analyzed 100 popular security-focused open-source projects and their GitHub Actions configurations. The finding was stark: only 7 out of 100 had every action correctly pinned to a full SHA. Even when including actions from "trusted creators" (GitHub, Docker, AWS, Google), the rate rose to only 12%. The average repository used 16 distinct third-party actions — each one a potential attack surface.

Une étude de mars 2025 a analysé 100 projets open-source populaires axés sur la sécurité et leurs configurations GitHub Actions. Le constat était saisissant : seulement 7 sur 100 avaient chaque action correctement pinnée sur un SHA complet. Même en incluant les actions de "créateurs de confiance" (GitHub, Docker, AWS, Google), le taux ne montait qu'à 12%. Le dépôt moyen utilisait 16 actions tierces distinctes — chacune une surface d'attaque potentielle.

This matters beyond compliance: the Trivy attack specifically targeted security scanning actions. Projects that pride themselves on running vulnerability scans in CI were the ones executing malicious credential harvesters. The tool you add for security can become the mechanism of your breach.

Cela a des implications au-delà de la conformité : l'attaque Trivy a spécifiquement ciblé les actions de scan de sécurité. Les projets qui se vantent d'exécuter des scans de vulnérabilités en CI étaient ceux qui exécutaient des collecteurs d'identifiants malveillants. L'outil que vous ajoutez pour la sécurité peut devenir le mécanisme de votre brèche.

The manual audit is simple. Search your .github/workflows/ directory for any uses: line that doesn't contain a 40-character hex SHA:

L'audit manuel est simple. Cherchez dans votre répertoire .github/workflows/ toute ligne uses: qui ne contient pas un SHA hexadécimal de 40 caractères :

# Find unpinned actions (uses tag or branch, not full SHA)
grep -r "uses:" .github/workflows/ | grep -v "@[0-9a-f]\{40\}"

# Example output:
# deploy.yml:      - uses: actions/checkout@v4          ← UNPINNED
# deploy.yml:      - uses: actions/setup-node@main      ← UNPINNED
# deploy.yml:      - uses: actions/checkout@692973e...  ← pinned ✓

Frequently Asked Questions

Questions fréquentes