Visitar URL original
Automatically disable caching on release-shaped triggers? · Issue #984 · astral-sh/setup-uv · GitHub
Skip to content

Automatically disable caching on release-shaped triggers? #984

Description

@woodruffw

This is an idea I've been bouncing around in my head for a while.

TL;DR: setup-uv could disable caching by default when it detects that it's being run from a release-shaped trigger. In practice that means the release trigger plus tag-push events.

Summary

GitHub Actions caching is unfortunately not very secure, and is very easy to poison across workflows/jobs.

We've seen attackers successfully use this to pivot from a low-privilege/low-risk job (like a build step) to a high-privilege one, since cache write access isn't disabled when the user does permissions: {}.

The solution is to never load from cache in "sensitive" jobs. In practice that means that jobs that publish release artifacts, for example, should always run fully uncached (but should of course use a locked resolution).

Proposed solution

setup-uv could check what trigger it was invoked under, and modify its caching behavior based on that trigger.

This should be straightforward to do: every GHA job gets a GITHUB_EVENT_PATH variable, which points to the full webhook payload, which in turn reveals the trigger. GITHUB_EVENT_NAME also exposes the bare event name itself, which is sufficient for e.g. release events.

Here's a (different) example of those being read from:

https://github.com/pypa/gh-action-pypi-publish/blob/dc37677b2e1c63e2034f94d8a5b11f265b73ba33/oidc-exchange.py#L286-L308

Concretely, when the user sets enable-cache: auto, we should disable it under the following new conditions:

  1. The workflow trigger is pull_request_target or workflow_run (fundamentally insecure)
  2. The workflow trigger is release or push with tags (indicates a release flow)

Other context

This would also hush a bunch of findings that come out of zizmor's cache-poisoning audit -- in particular it currently flags most setup-uv invocations since they restore from the cache by default, but if that changes then zizmor can stop emitting those 🙂

Activity

  1. woodruffw commented on Aug 4, 2026

    @woodruffw
    MemberAuthor

    Also for context: I was recently reminded of this because of astral-sh/uv#20946, which shows how we have to set non-default options to ratchet down setup-uv's caching controls on release workflows 🙂

  2. added theissue type on Aug 6, 2026
  3. eifinger commented on Aug 7, 2026

    @eifinger
    Collaborator

    Thank you for the detailed issue, sounds reasonable and straightforward to implement.
    Will be another breaking release though.

    IIRC workflow_run is problematic because a previous workflow without write permissions could poison the cache, trigger another workflow via workflow_run and this workflow might be one with write permissions that would now consume the poisoned cache?

  4. woodruffw commented on Aug 7, 2026

    @woodruffw
    MemberAuthor

    Thanks! And yeah, your description of the risk with workflow_run is correct: it runs on the default branch so the implicit cache token can poison anything "below" the default branch, unlike the implicit cache token for a specific feature branch.

  5. added a commit that references this issue on Aug 10, 2026
    f451684
  6. added a commit that references this issue on Aug 12, 2026
  7. 23 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions