SURIQ
The most serious compromises we tracked this week had an unsettling detail in common: the object you would have inspected was clean. The repository held no malicious code. The plugin on the public registry was fine. The company's own servers were never touched. The attack rode in through a channel you trust to deliver and run software, not through the software you would think to check.
That is the pattern worth naming this week. The action moved off the application and onto the toolchain that builds, ships, updates, and now actively assists it. A defender pointed at the wrong object will pass every one of these.
Six reports, one shape
| The channel you trusted | What you would have inspected | What it actually delivered |
|---|---|---|
| A paid plugin auto-update | The free plugin on the public registry, which was clean | Backdoored ShapedPlugin Pro updates that stole admin logins and 2FA seeds |
| A third-party vendor script | Polymarket's own servers, which were never breached | Injected front-end code that drained close to 3 million dollars from users |
| An npm dependency | The install step, which you never even ran | Malware that runs the moment you open the folder in your editor, stealing developer and wallet logins |
| Your CI pipeline | The actions/checkout version you carefully pinned | Any free GitHub account pushing code as a maintainer across 300-plus repositories |
| Your AI coding agent | The repository, which held no malicious code | A reverse shell the agent opened on your machine |
| An AI assistant marketplace | The store's own automated scanner | Skills that steal credentials and run crypto scams through the agent |
Read the second column of that table on its own. The free plugin: clean. The npm install step: never run. The backend servers: never breached. The pinned action version: correct. The repository: no malicious code. In every case the thing a normal review would examine was genuinely fine, and the compromise lived one step to the side, in the update, the editor, the vendor script, the pipeline, or the agent.
This is why "we scanned it and it was clean" gave so little comfort this week. Scanning answers one question: is this artifact malicious? A delivery-channel attack makes that the wrong question. The code was never the malicious part. The right question is whether a trusted channel could hand you something you did not write, and a scanner pointed at the cargo never asks it.
A delivery channel is the worst thing to lose
There is a reason attackers keep climbing into these positions instead of hammering the application directly. A delivery channel inherits your trust and then multiplies it. Compromise one and you do not get one victim, you get everyone downstream of it.
The numbers in our own reports show the fan-out plainly. The Cordyceps technique did not target one project; it let anyone with a free account run code as a maintainer across more than 300 repositories at once. The poisoned vendor script on Polymarket did not need to breach a single server to take close to 3 million dollars, because it ran in every visitor's browser. A backdoored plugin update reached every site that did the responsible thing and stayed current. The channel is a force multiplier, and that is exactly what makes owning it more valuable than owning any one target it feeds.
It also defeats the controls people lean on. A signature check passes, because the update was signed by the real vendor. A reputation check passes, because the parent process is a trusted editor or a signed binary. An allowlist passes, because the dependency is a package you chose. None of those controls is broken. They are answering honestly. They were just never designed to catch a trusted channel delivering hostile cargo.
The newest channel is the agent itself
The sharpest version of this is the AI agent, because it is a delivery channel with a developer's privileges and the autonomy to act on its own.
Open the wrong repository in Amazon Q Developer and it ran that repo's configuration file as you, AWS keys attached, before you reviewed a line. Mozilla's red team got Claude Code to open a reverse shell from a repository that contained no malicious code at all, because the instructions lived in content the agent read, not in code a scanner parses. Docker's MCP Gateway let a rigged container image seize root on the host running the AI tools, a flaw rated 8.7. Crawl4AI shipped its server unlocked by default, exposing more than 51,000 deployments to remote code execution.
Strip the AI framing and the underlying flaw is old. Most of these resolve to command injection or remote code execution, the class we logged 152 times this week. What changed is the entry point. It moved from the application's input fields to the developer's tools, and the agent will read a config, run a command, or install a skill on your behalf, which is precisely the helpfulness an attacker borrows.
None of this is unprecedented in kind. The 2020 SolarWinds build-server compromise and the 2018 event-stream npm hijack already proved that owning a delivery step beats attacking a hardened target. The 2026 version simply adds a step those attacks did not have: an autonomous assistant that will take an action for you, which means the channel no longer needs you to make the mistake yourself.
What to do when the toolchain is the target
The defensive move is to stop treating "the artifact is clean" as the end of the review and start defending the channels that deliver it.
Verify, do not only scan. Pin dependencies to hashes rather than version ranges, and require provenance or signing on updates. An auto-update that can change behavior is remote code execution that you pre-authorized, so it deserves the scrutiny you would give any code you run.
Treat marketplace skills and editor extensions as code execution, because that is what they are. Allowlist them, review them, pin them, and never accept a store's own scanner as your control. This week it missed the malicious skills sitting in its catalog.
Sandbox agents and scope their tokens. An AI coding agent should run with the least privilege that lets it work: no standing cloud keys in its environment, restricted network egress, and contained file writes. Assume any repository it opens is hostile input, the same way you treat a user-supplied request.
Lock down CI. Pinning actions/checkout shuts only one of several doors. Default the pipeline token to read-only, and gate any workflow that runs on a fork or an outside pull request.
Watch behavior, not just contents. The clean artifact will not trip a scanner, but the channel's behavior will. Alert on a freshly installed package or a just-opened project making outbound connections, a build step reaching the internet, or an agent spawning a shell.
We triaged 3,945 vulnerabilities this week and judged 34 worth publishing; around 64 of the ones we tracked were flagged as exploited by our reckoning, and the through-line in the worst of them is the same. Inspecting the package was always a stand-in for trusting how it reached you. This week pulled those two apart. Defend the channel, not just the cargo.
Methodology: figures are drawn from the Suriq threat desk's own intelligence and news ledgers over the stated window. "Triaged" counts events we logged a decision on, not raw signal volume; exploitation figures are best-effort and labelled approximate.