The Clinejection incident is worth studying because it was not a single bug. It was a chain: prompt injection pressure in an AI-enabled workflow, CI/CD trust boundary weaknesses, and token lifecycle failures during response.
If you run coding agents on WordPress or Drupal repositories, this is directly relevant to your release pipeline.
What Happened (With Dates)
Based on the public disclosure and advisory trail:
- On December 21, 2025, Cline added AI issue-triage automation in GitHub Actions.
- On January 1, 2026, the issue was reportedly disclosed privately by the researcher.
- On February 9, 2026, public disclosure landed and Cline merged workflow hardening changes (removing AI triage/review workflows and publish caching).
- On February 17, 2026 at 3:26 AM PT, an unauthorized publish pushed
[email protected]to npm with a modifiedpostinstall. - On February 17, 2026 at 11:23 AM PT,
2.4.0was published; at 11:30 AM PT,2.3.0was deprecated. - GitHub advisory scope: affected version
2.3.0, patched>=2.4.0, and impact limited to the CLI npm package (not the VS Code extension or JetBrains plugin).
Why This Incident Matters
The key lesson is architectural:
- Prompt injection did not need to directly steal secrets from production.
- It only needed to influence a privileged automation path enough to pivot into release infrastructure.
- After that, release-token governance became the decisive control.
This matches OWASP’s 2025 framing of prompt injection: not a “chat safety bug,” but a control-plane risk when models can influence tool execution and downstream systems.
Where Pipelines Usually Break
For WordPress plugin and Drupal module teams, the recurring failure points look familiar:
- Agent workflows and release workflows share trust surfaces (cache, artifacts, or permissions).
- Long-lived publish tokens are still present, even after teams “migrate” partway to OIDC.
- Workflow permissions are broader than necessary.
- Untrusted content (issues, PR text, docs, changelogs) is treated as safe context for high-agency jobs.
- Incident response rotates “a token,” but not the complete credential graph.
Release-Pipeline Hardening Baseline (WordPress/Drupal)
This is the practical baseline I’d apply now.
1) Split Untrusted AI Jobs From Release Jobs
- Keep AI triage/review jobs in a separate workflow set with no release access.
- Never allow shared writable channels from untrusted automation into release (including cache/artifacts) unless strictly necessary and verified.
2) Use Least-Privilege GITHUB_TOKEN Everywhere
- Set workflow/job-level
permissions:explicitly. - Default to read-only; grant write scopes only in the specific release job that needs them.
- Treat third-party actions as privileged code execution.
3) Move Publishing to OIDC Trusted Publishing
- For npm packages (common in WP/Drupal toolchains and CLIs), use trusted publishing and remove long-lived write tokens.
- Enforce token disallow/2FA package settings after cutover.
4) Add Provenance and Publish-Path Verification Gates
- Fail release when provenance is missing or publish actor deviates from expected CI identity.
- Alert on manual publishes where automation is required.
5) Require Human Approval Before Irreversible Actions
- Agent-generated output can propose changes.
- Humans approve release promotion, publish commands, and production deploys.
- No autonomous “issue text to release” path.
6) Treat Agent Inputs as Hostile by Default
- Normalize/sanitize hidden text patterns.
- Restrict which users/comments/files become agent context for privileged tasks.
- Block network egress for jobs that do not need it.
7) Run Incident Rotation as a Graph, Not a Checkbox
- Enumerate every credential with publish or signing authority.
- Revoke all legacy tokens, not only the one believed compromised.
- Re-issue from clean trust roots; verify revocation by test.
A CMS-Team Threat Model That Works
If your repo ships WordPress plugins/themes or Drupal modules:
- Assume any public issue/PR/body text can be malicious prompt material.
- Assume any agent with tool access can be coerced.
- Assume any long-lived token will eventually leak.
Then design your release architecture so that those assumptions still do not produce a publish compromise.
Fast 7-Day Action Plan
- Inventory every workflow that can reach release credentials or publish endpoints.
- Remove/disable shared caching between untrusted automation and release jobs unless proven safe.
- Enforce explicit minimal
permissions:in all workflows. - Migrate npm publishing to OIDC trusted publishing and revoke legacy write tokens.
- Add release gate checks for provenance and expected publisher identity.
- Require manual approval for release/publish jobs.
- Run one tabletop incident drill: “prompt-injected issue to package publish.”
Bottom Line
Clinejection was not just “an AI mistake.” It was a release-engineering warning shot:
- AI-facing workflows are part of your software supply chain.
- Prompt injection is a realistic trigger.
- CI/CD boundary design determines blast radius.
WordPress and Drupal teams that adopt coding agents can keep the productivity gains, but only if release pipelines are hardened like critical infrastructure.
References
- Adnan Khan: Clinejection — Compromising Cline's Production Releases
- GitHub Advisory GHSA-9ppg-jx86-fqw7
- Cline PR #9211 (workflow hardening changes merged Feb 9, 2026)
- GitHub Docs: Controlling permissions for
GITHUB_TOKEN - GitHub Docs: Secure use reference for GitHub Actions
- npm Docs: Trusted publishing with OIDC
- OWASP GenAI: LLM01:2025 Prompt Injection
Originally published at VictorStack AI Blog