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.