[BUG]: cache-poisoning false positive for Swatinem/rust-cache with save-if

[wpfleger96]

Pre-submission checks

• I am not filing a feature request. These should be filed via the feature request form instead.
• I have checked the Troubleshooting Guide for my problem.
• I have looked through both the open and closed issues for a duplicate report.

zizmor version

1.23.1

Expected behavior

Swatinem/rust-cache with save-if: ${{ github.event_name != 'pull_request' }} should not trigger cache-poisoning, since save-if: false prevents cache writes entirely — the same mitigation as lookup-only: true but less restrictive (cache restoration still works on PRs for build speed).

Actual behavior

zizmor flags the step as cache-poisoning regardless of the save-if value. Looking at cache_poisoning.rs, the Swatinem/rust-cache ActionCoordinate only registers lookup-only as the control field:

ActionCoordinate::Configurable {
    uses_pattern: "Swatinem/rust-cache".parse().unwrap(),
    control: ControlExpr::single(
        Toggle::OptOut,
        "lookup-only",
        ControlFieldType::Boolean,
        true,
    ),
},

save-if is not recognized at all, even though it directly controls whether cache writes happen.

Reproduction steps

on:
  push:
    branches: [main]
    tags: ['v*']
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Swatinem/rust-cache@v2
        with:
          save-if: ${{ github.event_name != 'pull_request' }}
      - run: cargo build

Running zizmor on this workflow reports a cache-poisoning finding on the Swatinem/rust-cache step, despite save-if preventing cache writes on PR events.

Suggested fix

Add save-if as a second recognized control field for Swatinem/rust-cache in cache_poisoning.rs, as an OptOut boolean toggle (when save-if: false, no cache is written — same effect as lookup-only: true for the poisoning vector).

Additional context

Related issues:

• Feature: cache-poisoning (finer grained) #2050 — finer-grained cache-poisoning expression evaluation
• [BUG]: zizmor currently flags maturin's generated workflow for sccache: ${{ !startsWith(github.ref, 'refs/tags/') }} being vulnerable to a cache poisoning attack #1940 — similar false positive for sccache: parameter on PyO3/maturin-action

save-if documentation in Swatinem/rust-cache

[woodruffw]

Hi @wpfleger96, thanks for opening an issue.

I'm actually not sure this is a false positive: disabling cache saving is not equivalent to disabling cache restoration, since GitHub Actions has no concept of "provenance" when restoring cache entries.

In other words: disabling saves via save-if prevents Swatinem/rust-cache itself from saving to the cache, but any other action can still compromise the cache restore step by predicting the cache key that Swatinem/rust-cache will restore from. This is trivial in practice, since cache keys are (1) fully controlled but the client side, and (2) are fully public information (e.g. are typically a pure function of repository state visible to an attacker).

TL;DR: loading, not saving, is the more relevant action for cache poisoning, since it's difficult for zizmor to statically demonstrate the security of cache save operation everywhere in your CI/CD (particularly when cache writes can be deeply nested inside called actions). Consequently we rely on being able to prove that "release-shaped" workflows don't load from cache. I strongly recommend using lookup-only: true (or one of the heuristics we support, see #1954 and #2050) if you want to protect release-shaped workflows from cache poisoning.

[wpfleger96]

hi @woodruffw thanks for the reply! that totally makes sense, I think my initial understanding of this was a little backwards. I've switched to lookup-only: true to for our release workflow and will close this out, thanks again for the explanation!

[woodruffw]

No problem!