Secrets Scoping Partially Effective But Bypassable Via Shared Caches

Issue 65 Edition 2026-03-06 6 min read

General

Sources: 1 • Confidence: High • Updated: 2026-04-13 03:56

Key takeaways

GitHub Actions caches can share the same name across different workflows, and Cline used the same cache key for node_modules in both the issue triage workflow and the nightly release workflow.
Cline ran an AI-powered issue triage workflow that invoked anthropics/claude-code-action@v1 with tool access (including Bash, Read, and Write) whenever any user opened an issue.
A malicious issue title could instruct the agent to run an npm install of a GitHub-hosted package as part of the triage workflow, introducing attacker-controlled code into the workflow environment.
The published compromised package reportedly only added OpenClaw installation and did not take more destructive actions.
Because the triage prompt included the issue title, an attacker could craft an issue title intended to coerce Claude into executing arbitrary commands.

GitHub Actions caches can share the same name across different workflows, and Cline used the same cache key for node_modules in both the issue triage workflow and the nightly release workflow.
A prompt injection against the issue triage workflow could poison the shared cache and lead the nightly release workflow to load it, enabling theft of npm publishing secrets used by the release workflow.
The issue triage workflow did not have access to key secrets such as those used to publish releases to npm.
GitHub evicts Actions caches that grow beyond 10GB, and the cacheract package exploited this by forcing cache eviction and then caching new files containing a secret-stealing mechanism.

Cline ran an AI-powered issue triage workflow that invoked anthropics/claude-code-action@v1 with tool access (including Bash, Read, and Write) whenever any user opened an issue.
Because the triage prompt included the issue title, an attacker could craft an issue title intended to coerce Claude into executing arbitrary commands.
The attack chain against the Cline GitHub repository began with a prompt injection embedded in the title of a newly opened GitHub issue.

A malicious issue title could instruct the agent to run an npm install of a GitHub-hosted package as part of the triage workflow, introducing attacker-controlled code into the workflow environment.
An installed npm package can execute arbitrary code via a preinstall script defined in its package.json.

The published compromised package reportedly only added OpenClaw installation and did not take more destructive actions.

What exact commands (if any) were executed by the tool-enabled agent during the issue triage runs, and are there complete logs that confirm execution paths?
What were the precise GitHub Actions permissions (GITHUB_TOKEN scopes, repository permissions) granted to the issue triage workflow at the time of the incident?
Is there definitive evidence that caches were successfully poisoned and then consumed by the nightly release workflow in the described manner?
What were the exact cache keys and cache restore/save steps in both the issue triage and nightly release workflows, and did they include workflow identity or trust-level separation?
Was npm publishing credential exfiltration confirmed, and were tokens rotated after the incident?

Broader scrutiny of CI cache isolation across GitHub Actions workflows, especially where untrusted triggers share cache keys with release workflows, could drive urgent remediation and potential disruption for teams using shared caches.
Heightened concern over tool-enabled LLM agents in automation pipelines, where untrusted metadata like issue titles can become command inputs, may lead to tightening or disabling such workflows and increased demand for safer agent integrations.
Supply chain risk focus on dependency installation inside CI as an execution bridge, including npm lifecycle scripts, could accelerate adoption of controls that restrict installs in untrusted contexts and require stronger provenance checks.

Release of complete workflow definitions showing identical cache keys and restore save steps across issue triage and nightly release, demonstrating trust boundary crossing via caches.
Logs or artifacts confirming the tool-enabled agent executed commands influenced by issue titles, including npm install, and that resulting cache contents were later restored in the release workflow.
Disclosure of the exact GitHub Actions permissions for the triage workflow and whether any credential access or token usage occurred during or after the triage runs.

Evidence that cache keys were separated by workflow identity or otherwise isolated, preventing any cache sharing from the untrusted triage workflow to the release workflow.
Definitive logs showing no attacker-influenced command execution occurred in triage runs, or that prompts and tool policies prevented arbitrary command execution.
Verification that no release workflow consumed poisoned artifacts and no credential exfiltration occurred, including confirmation of token integrity and rotation where applicable.