"Clinejection"으로 AI 봇을 공급망 공격으로 전환

February 19, 2026 On February 9, 2026, security researcher Adnan Khan publicly disclosed a vulnerability chain (dubbed "Clinejection") in the Cline repository that turned the popular AI coding tool's own issue triage bot into a supply chain attack vector. Eight days later, an unknown actor exploited the same flaw to publish an unauthorized version of the Cline CLI to npm, installing the OpenClaw AI agent on every developer machine that updated during an eight-hour window. The attack chain is notable not for any single novel technique, but for how it composes well-understood vulnerabilities (indirect prompt injection, GitHub Actions cache poisoning, credential model weaknesses) into a single exploit that requires nothing more than opening a GitHub issue. For Cline's 5+ million users, the actual impact was limited. The unauthorized [email protected] was live for roughly eight hours, and its payload (installing OpenClaw globally) was not overtly destructive. But the potential impact, pushing arbitrary code to every developer with auto-updates enabled, is what makes this incident worth studying in detail. Snyk and Cline have an existing security partnership focused on keeping AI-assisted coding secure, and this incident reinforces why that kind of collaboration matters across the industry. An AI agent with too many permissions On December 21, 2025, Cline's maintainers added an AI-powered issue triage workflow to their GitHub repository. The workflow used Anthropic's claude-code-action to automatically respond to new issues. The configuration looked like this: Two configuration choices made this dangerous: allowed_non_write_users: "*" meant any GitHub user could trigger the workflow by opening an issue.--allowedTools "Bash,Read,Write,Edit,..." gave the AI agent arbitrary code execution on the GitHub Actions runner. The issue title was interpolated directly into the prompt. That is a textbook indirect prompt injection surface. Step 1: Prompt injection via issue title An attacker could craft a GitHub issue title containing instructions that would override Claude's intended behavior: The github:cline/cline#aaaaaaaa reference points to a specific commit. Because of GitHub's fork architecture, an attacker can push a commit to their own fork, and that commit becomes accessible via the parent repository's URL, even after the fork is deleted (a technique known as a "dangling commit"). The commit replaces package.json with a version containing a malicious preinstall script: When Claude runs npm install via its Bash tool, the preinstall script executes automatically. There is no opportunity for the AI agent to inspect what runs. Khan confirmed that Claude "happily executed the payload in all test attempts" on a mirror of the Cline repository. This is a pattern Snyk has been tracking closely. In our toxic flow analysis research, we describe exactly this class of vulnerability: untrusted data flowing into an AI agent's context, combined with tool access that allows code execution, creating a "toxic flow" where the attacker controls what the agent does. The Cline incident is a real-world example of toxic flows playing out in CI/CD, not just in local development environments. Step 2: Pivoting via GitHub Actions cache poisoning The prompt injection alone compromised the triage workflow runner. But the triage workflow had restricted GITHUB_TOKEN permissions and no access to publication secrets. To reach the release pipeline, the attacker needed to pivot. This is where GitHub Actions cache poisoning comes in. A critical property of GitHub Actions is that any workflow running on the default branch can read from and write to the shared Actions cache, even workflows that don't explicitly use caching. The low-privilege triage workflow shared the same cache scope as the high-privilege nightly release workflow. GitHub's cache eviction policy uses least-recently-used (LRU) eviction once the cache exceeds 10 GB per repository. An attacker can exploit this by: Filling the cache with \>10 GB of junk data from the triage workflow Forcing LRU eviction of legitimate cache entries Setting poisoned cache entries matching the nightly workflow's cache keys Khan's open source tool Cacheract automates this entire process. It poisons cache entries and persists across workflow runs by hijacking the actions/checkout post step. Cline's nightly release workflow consumed cached node_modules directories: When the nightly publish workflow ran at \~2 AM UTC and restored the poisoned cache, the attacker could execute arbitrary code in a workflow with access to VSCE_PAT , OVSX_PAT , and NPM_RELEASE_TOKEN . Step 3: Nightly credentials \= production credentials One might assume that nightly release credentials would be scoped differently from production credentials. They weren't. Both the VS Code Marketplace and OpenVSX tie publication tokens to publishers, not individual extensions. Cline's production and nightly extensions were published by the same identity (saou