Prompt-Injection As A Ci Entry Point Via Issue Metadata

Issue 65 Edition 2026-03-06 6 min read

Not accepted General

Sources: 1 • Confidence: Medium • Updated: 2026-04-12 10:23

Key takeaways

Cline ran an AI-powered issue triage workflow that executed anthropics/claude-code-action@v1 with tool access (including Bash, Read, and Write) when any user opened an issue.
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 malicious issue title could direct the agent to run an npm install of an attacker-controlled, GitHub-hosted package as part of triage.
The published compromised package reportedly only added OpenClaw installation and did not take more destructive actions.
The issue triage prompt included the issue title as input to the agent.

Cline ran an AI-powered issue triage workflow that executed anthropics/claude-code-action@v1 with tool access (including Bash, Read, and Write) when any user opened an issue.
The issue triage prompt included the issue title as input to the agent.
If a tool-capable agent receives an untrusted issue title, an attacker can craft that title to coerce the agent into executing commands.
The attack chain against the Cline GitHub repository began with a prompt injection embedded in the title of a newly opened issue.

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 successful compromise of the issue triage workflow could poison a shared cache that the nightly release workflow later restores, enabling theft of the release workflow's npm publishing secrets.
The issue triage workflow did not have access to key secrets such as npm publishing credentials, which initially limited impact.
GitHub evicts Actions caches that grow beyond 10GB, and the cacheract package exploited this by expanding cached paths to about 11GB to force eviction and then caching new files that enabled secret stealing.

A malicious issue title could direct the agent to run an npm install of an attacker-controlled, GitHub-hosted package as part of triage.
An npm package can execute arbitrary code during installation via a preinstall script defined in package.json.

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

What exact GitHub Actions workflow YAML, permissions, and runner environment settings were in place for the issue triage and nightly release workflows at the time of the incident?
Is there direct evidence (logs/artifacts) that the issue-title prompt injection executed commands and installed attacker-controlled packages during triage runs?
Were npm publishing secrets actually exfiltrated from the nightly release workflow, and if so, what tokens/identities were affected and for how long?
What specific cache keys, scopes, and restore/save behaviors enabled cross-workflow cache reuse, and can untrusted workflows write to caches later restored by trusted workflows?
What is the precise behavior of the compromised published package (including install-time scripts and any network or filesystem side effects) across the full distribution artifact?

Increased demand for CI hardening around AI agents and untrusted inputs like issue titles, especially controls that block tool access or command execution triggered by public events.
Heightened focus on GitHub Actions cache isolation and key hygiene as a cross-workflow trust boundary risk, potentially driving adoption of safer caching patterns or tooling to audit cache reuse.
Renewed attention to dependency installation during automation runs as a supply-chain insertion path, increasing appetite for policies that prevent network installs or npm lifecycle script execution in untrusted workflows.

Release of the exact GitHub Actions workflow YAML, permissions, and runner settings showing untrusted issue events triggering tool-capable agents and writing caches later restored by higher-privilege workflows.
Logs or artifacts demonstrating the issue-title prompt injection caused command execution and installed attacker-controlled packages during triage runs.
Evidence that npm publishing secrets were exfiltrated via the nightly release workflow, including which tokens were affected and duration of exposure.

Verified workflow configurations showing untrusted issue triage could not write caches that are later restored by trusted workflows, or that cache keys and scopes prevented cross-workflow reuse.
Forensic confirmation that no triage runs executed injected commands and no attacker-controlled packages were installed as part of the agent workflow.
Validated analysis of the compromised package showing no install-time side effects beyond the limited described action and no indicators of secret access or exfiltration.