Overview Cline is an open-source AI coding tool that integrates with developer IDEs such as VSCode and its many forks. Users can download Cline through the VS Code Marketplace or OpenVSX. Since Cline is an open-source project the team uses a GitHub for development. On December 21st, 2025, Cline maintainers added an AI agent to triage issues created on the repository. This AI agent ran within a GitHub Actions workflow and ran with broad privileges. You might be able to guess where this is heading… Between Dec 21st, 2025 and Feb 9th, 2026 a prompt injection vulnerability in Cline’s (now removed) Claude Issue Triage workflow allowed any attacker with a GitHub account to compromise production Cline releases on both the Visual Studio Code Marketplace and OpenVSX and publish malware to millions of developers! The attack chain leverages GitHub Actions cache poisoning to pivot from the triage workflow to the Publish Nightly Release and Publish NPM Nightly workflows and steal the VSCE_PAT , OVSX_PAT , and NPM_RELEASE_TOKEN secrets. These nightly credentials have the same access as production publication credentials due to the credential models of VSCode marketplace, OpenVSX, and NPMJS. I will update this blog post once the vulnerability is addressed. My attempts to reach someone were fruitless - I doubt this will be. Cline only addressed this issue after public disclosure despite multiple attempts to contact the Cline team. There is also some evidence an actor attempted to exploit this directly. It is unclear if this is another researcher or an actual threat actor. As of writing there have been no malicious updates to Cline. While the initial vulnerability is fixed, Cline users should exercise caution consuming Cline updates and make sure auto-updates are disabled until Cline can provide details on this and confirm no impact to users (in case a bad actor did steal their production release credentials). Background Cline’s AI-Powered Issue Triage The Cline issue triage workflow used claude-code-action to automatically triage incoming issues. When a new issue is opened, the workflow spins up Claude with access to the repository and a broad set of tools to analyze and respond to the issue. The intent: automate first-response to reduce maintainer burden. GitHub Actions Cache Scope A critical but often misunderstood property of GitHub Actions is that any workflow can read from and write to the cache with full control of cache keys/versions , even if it does not explicitly use caching. Workflows triggered on the default branch have access to the default branch cache scope. Cacheract and GitHub Actions Cache Poisoning In my previous research, I released Cacheract — an open-source proof-of-concept for “Cache Native Malware” that exploits GitHub Actions cache misconfigurations. Cacheract automates the process of poisoning cache entries from within a build and persisting across workflow runs by hijacking the actions/checkout post step to achieve code execution in consuming workflows. There’s a catch, though: cache entries in GitHub Actions are immutable until they age off or are explitly deleted. Once set, a given key + version combination cannot be overwritten - only deleted via the API using a credential with actions: write permission. Cline’s issue triage workflow doesn’t have that privilege, so an attacker can’t simply replace existing cache entries directly. This is where GitHub’s recent policy change comes in. On November 20th 2025, GitHub updated their cache eviction policy to evict cache entries immediately after the cache exceeds 10 GB (unless users pay more) per repository. GitHub uses a least-recently-used (LRU) eviction policy, meaning older entries are purged first. An attacker can exploit this by flooding the cache with >10 GB of junk data, forcing GitHub to evict the legitimate entries. Once those keys are vacant, an attacker can claim them with poisoned entries — all within minutes, from a single workflow run. Before this change GitHub only evicted entries every 24 hours, making cache poisoning exploitation much harder without the ability to delete cache entries. Since December 2025, Cacheract automates this entire “single execution” cache poisoning technique. I’ve used it successfully for multiple disclosures already. Technical Deep Dive The Vulnerable Workflow Cline’s (now removed) issue triage workflow ran on the issues event and configured the claude-code action with allowed_non_write_users: "*" , meaning anyone with a GitHub account can trigger it simply by opening an issue. Combined with --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch" , this gave Claude arbitrary code execution within default-branch workflow. - name : Run Issue Response & Triage id : triage uses : anthropics/claude-code-action@v1 with : anthropic_api_key : ${{ secrets.ANTHROPIC_API_KEY }} github_token : ${{ secrets.GITHUB_TOKEN }} allowed_non_write_users : "*" claude_args : --model claude-opus-4-5-20251101 --allowedTool...