Don't cache automatically in privileged workflows

[caugner]

Description:
In #1348, caching was enabled by default if the package.json includes the packageManager field.

This side-effect is dangerous in privileged workflows with access to secrets and credentials, because it makes them vulnerable to cache poisoning. Code injection in one privileged workflow can be exploited to steal higher value secrets, and credentials in another privileged workflow.

Action version:
v5.0.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
npm (but issue is not specific)

Repro steps:

1. Create a repo with package.json incl. packageManager field.
2. Create a pull_request_target workflow incl. actions/setup-node usage.

Expected behavior:
Caching should not be enabled by default in privileged workflows.

Actual behavior:
Caching is enabled by default.

[aparnajyothi-y]

Hello @caugner, Thank you for creating this issue. This behavior is expected with actions/setup-node v5. In this release, caching is automatically enabled if your package.json includes a valid packageManager field (such as pnpm, yarn, or npm). This update is aimed at simplifying dependency caching by default.

To turn off automatic caching and restore the previous behavior, set package-manager-cache: false in your setup-node step:

steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
  with:
    package-manager-cache: false

For more information on this update and recommended configuration, please refer to:
v5.0.0 Release Notes
README – Caching Packages

Please feel free to reach us in case of any further calrifications/concerns.

[caugner]

Thanks for the quick response, and for confirming the intended behavior.

I would like to clarify that I'm not asking to restore the old behavior. I'm concerned about the security implications of enabling caching by default in privileged workflows (e.g. pull_request_target with access to secrets).

As mentioned above, automatic caching creates a vector for cache poisoning, where malicious code in one workflow can inject content into the cache, and later exfiltrate secrets or credentials from another privileged job.

In this case, opening a seemingly harmless PR that adds the packageManager field to the package.json can open the door for this attack.

I understand the goal of simplifying caching, but I believe that safe defaults are important, especially for workflows that run with elevated privileges.

Possible mitigations here include:

• Disable automatic caching by default in privilehed workflows like pull_request_target and workflows with write access to secrets.
• Emit a warning when caching is auto-enabled in such workflows.
• Document the risks of using this action in privileged workflows explicitly in the README, and in the v7.0.0 elease notes.

Would the maintainers of this action be open to one of these approaches?

[aparnajyothi-y]

Hello @caugner, thanks again for raising this important point. We’ve enhanced the logs to clearly indicate when auto-caching is enabled, and updated the documentation to emphasize the associated risks in privileged workflows. These changes were introduced as part of PR#1336 which is going to release in the upcoming patch release.

That said, due to technical constraints, the action cannot reliably detect if it’s running in a privileged workflow, since it only has access to its own runtime context and not the full workflow or secret configuration. The most effective mitigation remains clear documentation and logs, along with the ability for workflow authors to explicitly disable caching in privileged contexts using package-manager-cache: false.

Please feel free to reach out in case of any further questions or concerns.

[mrgrain]

That said, due to technical constraints, the action cannot reliably detect if it’s running in a privileged workflow, since it only has access to its own runtime context and not the full workflow or secret configuration.

In that case, this is the wrong default and should be changed back. The recent weeks of supply change attacks hopefully have taught us something. With the change, there's a new attack vector for attacks to open PRs with seemingly innocent changes like @caugner has pointed out.

I don't believe a warning or documentation is enough. The warning is too late, at this point the workflow is already running. The documentation might not be read when using automated upgrade workflows like Dependabot. As of today, this risk is not even called-out in the release notes.

I also believe this may violate L3 requirements of SLSA (https://slsa.dev/spec/v1.1/requirements#isolated) but I am no expert in that area.

---

Also given the issues highlighted in #1374, maybe this just wasn't meant to be in the first place.

[janbrasna]

Well a "Bump ts-jest from 29.1.2 to 29.4.1…" changeset is a little unfortunate place for such a major and important info as "… and document breaking changes in v5" to be folded along with it but well that's what we have #1358 I guess.

Now given this will differ even based on the package manager used, judging from #1374 and other related issues, most likely asking for yet another breaking major version release, this will get even more fragmented and unclear.

On the bright side, the cache pwn attack mentioned was only due to other factors that have hopefully been mitigated since (IIUC the cache immutability once the run ends?) so it's not exactly reproducible in the form it was originally — however making sure consumers understand what impacts that can have just out of the blue, depending on how their actions are set up, is a good warning to have — ideally bubbling up through all the changelogs visibly to the bot PRs eagerly upgrading everyone right away…

[aparnajyothi-y]

Hello everyone, As part of PR #1374, we introduce detection support for devEngines.packageManager, enabling automatic caching for npm dependencies. This update will be included in the upcoming patch release of v5. We hope this enhancement helps streamline workflows and improve consistency across your projects.

Your feedback and suggestions are appreciated. Please take a look and share your thoughts.