GitHub hat am 26. Juni 2026 die Cache-Rechte in Actions verschärft: Workflows mit Auslösern wie pull_request_target, issue_comment oder workflow_run aus Forks erhalten nur noch lesende Tokens für den Cache des Standardbranches. Das verhindert Cache-Poisoning, bei dem manipulierte Einträge später in vertrauenswürdigen Workflows landen. Der Artikel erklärt die Änderung und was Teams anpassen müssen.
Seit dem 26. Juni 2026 scheitert das Speichern von Caches in Workflows mit unsicheren Auslösern, weil GitHub dort nur noch lesende Tokens vergibt. Wer bisher so Caches befüllt hat, sieht eine Warnung statt eines gespeicherten Eintrags.
Das Wichtigste in Kürze
- Fremd auslösbare Workflows dürfen den Cache des Standardbranches nur noch lesen. Betroffen sind unter anderem pull_request_target, issue_comment und workflow_run-Ketten aus Forks.
- Die Änderung ist bereits aktiv. Sie gilt auf github.com und bei GitHub mit Datenresidenz.
- Das Speichern schlägt mit einer Warnung fehl. Schritt und Job laufen laut Dokumentation weiter.
- Der Cache wird aus einem vertrauenswürdigen Workflow befüllt, etwa über einen push-Trigger.
GitHub hat die Meldung am 26. Juni 2026 veröffentlicht. Die Seite wurde zuletzt am 29. Juni 2026 geändert.
GitHub Actions: Warum GitHub eingreift
Bisher erhielt jeder Workflow ein Token mit Schreibrecht auf den Cache. Wer Code in einem fremd auslösbaren Workflow beeinflussen konnte, etwa durch Skript-Injektion, legte vergiftete Einträge im Cache des Standardbranches ab. Ein vertrauenswürdiger Workflow wie push oder schedule stellte diese Einträge später wieder her. So gelangte fremder Code in Pipelines mit Zugriff auf Produktions-Secrets.
Wie das in der Praxis aussieht, beschreibt SafeDep zum TanStack-Vorfall. Am 11. Mai 2026 löste ein Pull Request aus einem Fork einen pull_request_target-Workflow aus, der einen manipulierten pnpm-Speicher in den gemeinsamen Cache schrieb. Die Release-Pipeline stellte ihn wieder her. Der Schadcode lief dort mit Schreibrechten und holte ein OAuth-Token, mit dem Angreifer kompromittierte Pakete auf npm veröffentlichten.
Welche Trigger betroffen sind
Das Token ist nur dann lesend, wenn zwei Bedingungen zusammentreffen: Der Auslöser ist unsicher, also ohne Schreibrecht möglich, und der Cache-Bereich gehört zum Standardbranch.
| Gruppe | Auslöser | Cache-Recht |
|---|---|---|
| Unsicher | pull_request_target, issue_comment, workflow_run aus Fork-PRs | Nur lesen |
| Vertrauenswürdig | push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package, page_build | Lesen und schreiben |
Was Teams jetzt tun
Prüfe zuerst, welche Workflows mit den genannten Auslösern einen Cache speichern. Suche dafür nach actions/cache und setup-Aktionen mit eingebautem Cache.
Danach legst du einen eigenen Workflow mit vertrauenswürdigem Trigger an, der den Cache befüllt. Die unsicheren Workflows stellen ihn nur noch wieder her. Die Dokumentation zu pull_request_target empfiehlt genau dieses Vorgehen.
Ein Schalter für einen schreibenden Cache-Modus existiert, doch die Dokumentation warnt, er bringe das Risiko zurück. Nutze ihn nur mit gutem Grund. Wie du zusätzlich Aktionen in Workflows absicherst, zeigt der Artikel zu Lockfiles für Workflows.
Fazit
Die Änderung schliesst einen bekannten Angriffsweg, ohne dass du etwas einstellen musst. Rechne mit Warnungen in Workflows, die bisher Caches geschrieben haben, und verlagere das Befüllen in einen vertrauenswürdigen Workflow.
Quellen: GitHub Changelog, GitHub Docs, SafeDep. Foto: LAWJR / Pixabay. Stand: 29. Juni 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.