Cline 的分类机器人被提示注入劫持：未授权的 cline@2.3.0 上架约 8 小时，约 4,000 次下载（第三方估算）Cline's triage bot was hijacked through prompt injection: an unauthorised cline@2.3.0 sat on npm for about eight hours and was downloaded roughly 4,000 times (third-party estimate)

The chain researcher Adnan Khan demonstrated: Cline's issue-triage bot had wildcard trigger permissions, so any GitHub account could invoke it; the bot itself carried Bash execution and file read/write powers; and raw issue-title text was pasted straight into the prompt. The release token lived in the nightly release workflow, which shared a GitHub Actions cache scope with the low-privilege triage workflow, so cache poisoning could reach across workflows to the token.

The vendor's own failure was the direct cause: during the 2026-02-09 credential rotation it deleted the wrong token, and the exposed token was never revoked. On February 17 an unapproved cline@2.3.0 was published to npm and stayed up for about eight hours, with roughly 4,000 downloads (a StepSecurity estimate, not an official figure).

A low-privilege entrance held a high-privilege key: a triage workflow anyone could trigger sat one shared cache away from the release token, and a rotation that deleted the wrong token went unverified. The injection was only the fuse; the permission structure was the powder.

The case therefore belongs to the Tool layer: a triage bot equipped for its triage task should have no path to execution or release at all.

Least privilege per task: a triage bot gets only the read and labelling powers triage needs.

Separate triggering from executing: an entrance anyone can trigger must not hold powers that land anywhere, and release tokens live outside the bot's runtime.

Never paste untrusted text into prompts: external text such as issue titles does not enter prompts verbatim.

Verify every rotation: after a credential rotation, confirm token by token that the old ones are actually revoked.