Five Dollars a Task: What AI Attackers Mean for Your Stack

Updated October 28, 2026: published with every fact checked on October 28, 2026. The Updates section at the end logs each change.

What happened?

AI agents ran intrusions with little human help. On October 19, NorForge's Snorre Fagerland published Inside Cairn, on exposed control panels of Cairn, which NorForge describes as an AI-powered hacking system: it coordinates agents to investigate a target, search for weaknesses and try to break in. NorForge judged more than 20 of the panels likely malicious.

The busiest cluster, AIA0001, ran over 1,100 attack projects across 14 dashboards, mostly against e-commerce sites in the US, Japan and Australia, apparently after payment infrastructure. NorForge estimates an average task costs about $5, failed and early-ending tasks included, assumes a success rate around 10% and measured a little under 23 hours from start to goal for the tasks that got there. It says the cost estimate could be off by a clear margin.

Reuters, which reviewed the same activity, reported that the agents tried to break into more than 1,200 sites and got into websites belonging to more than 100 companies. Reuters also reported Fagerland's estimate of roughly $5,000 in tokens, about $50 per successful hack. That's per break-in; NorForge's $5 is per task, failures included.

Then a flaw in a compression library went from fix to CISA's exploited list in six days. Node2Shell, also called HTTP2Shell and Broccoli2Shell, is CVE-2026-111497: an out-of-bounds write in Google's Brotli decoder, versions 1.0.3 through 1.2.0. A crafted Brotli stream can corrupt or leak memory, crash the process or potentially run code, and Google's record scores it 9.2 under CVSS v4.0. Brotli shipped 1.0.10, 1.1.1 and 1.2.1 on October 21 (Brotli), and Node.js fixed its 22, 24 and 26 lines the same day.

The fix itself wasn't new. It went into Brotli's public source code on February 27, nearly eight months before the releases that carry it (Aikido). Node.js credits OpenAI Codex Security with the report.

Then it moved fast. A first public proof of concept on October 22 ran code only against a weakened test build. By October 23, Imperva researchers had run code on an official Node.js 24.22.0 build, and on October 25 ELLIO reported the same on x86-64 (The Hacker News, updated October 28). Microsoft shipped out-of-band .NET updates on October 25 (Microsoft). CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 27, with a November 10 due date for federal agencies.

Where it stands, as of October 28. CISA has confirmed active exploitation (BleepingComputer, October 28). ELLIO's sensors caught scanning for hosts that decode Brotli, then a crafted exploit attempt on October 26 that failed in ELLIO's own tests. None of the sources cited here reports a confirmed compromise at a named organization.

How do the two connect?

Not directly. Nothing in NorForge's report or Reuters' story ties Cairn's agents to Node2Shell, and no source cited here says AI was used to exploit it.

What links them is the clock. Cairn prices an attempt at about $5 and a success at under a day of an agent's time. Node2Shell shows how little time a fix buys: one day to a public proof of concept, two to code running on an official build, six to CISA's list.

Reuters' account of one break-in shows why that matters. After failing to find a weakness in a large company's public application, the agents searched records for related infrastructure, found a public-facing control panel and, after hours of trial and error, reported running commands on its server. The front door held. The side door didn't.

A library flaw like Node2Shell sits behind side doors too: a webhook that fetches a URL a user supplies, a container image, a vendor product that ships its own Node.js. An inventory can miss those. An agent doesn't get tired of checking.

Why will there be more of these?

Finding and using flaws takes less time. The Five Eyes cyber security agencies, CISA and the NSA among them, said in June that AI lowers barriers for attackers and is shrinking the window between vulnerability discovery and exploitation. Their timeline: "not years, it is months" (joint statement, June 22).

Agents are moving from helpers to operators. In September, Google's threat intelligence group said it hadn't yet seen fully autonomous pipelines used against targets in the wild (GTIG, September 8). Six weeks later, Fagerland told Reuters the Cairn data was real-life evidence that commercially available agents could carry complex intrusions from start to finish without human intervention.

Exploitation already starts early. Of the 491 vulnerabilities newly named as exploited in the first half of 2026, attackers were already exploiting 141 when those flaws went public, per the Zero Day Clock, read October 28. Verizon's 2026 DBIR says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords.

Federal deadlines now track automation. CISA's BOD 26-04, issued June 10, sets federal patch deadlines by four questions, one of them whether an adversary can automate every step of the exploit. The shortest deadline is three days. Cairn shows agents automating those steps. For working through the catalog, see Prioritize Vulnerabilities by Required Action, Not CVE Count.

What should your stack be expected to do now?

Each layer sees part of an attack like this, as Figure 3 shows. Plan around what it misses.

The edge sees inbound requests. A proxy or WAF rule can reject request bodies compressed with Brotli, which covers the path Express 5 and body-parser 2.x open by decompressing them. It doesn't see the Brotli responses your services fetch from other servers, and Node.js's fetch() decompresses those automatically. Aikido flags webhooks and other features that call user-supplied URLs.

The flaw lives inside the decoder. The out-of-bounds write happens inside the process, while the decoder works. Only the patch reaches it, and Node.js's advisory offers no workaround.

Host controls see what crosses into the operating system: a new process, a file written or run, a network connection. EDR, application control and kernel-level enforcement all work at this boundary, each asking a different question.

Code that stays in the process looks like the app. An attacker who stays inside the Node.js or .NET process and uses what it already has, its database connections, tokens and memory, makes no change a host control can tell apart from normal work. That holds for every host control, Mimic Networks included.

A record of changes answers "were we hit?" File integrity monitoring, EDR telemetry or change control: whatever records what changed on each server is how you answer that for the days since October 21, with evidence.

No single layer does it all. Having controls isn't enough, the Five Eyes agencies warn; leaders must be confident those controls will perform in a real incident. Here, the patch closes the flaw, the edge narrows one path, host controls limit what an exploit does next and the record shows whether it happened.

What should you do this week?

In this order.

1. Find every copy of Brotli you run, not just Node.js. Node.js 22, 24 and 26 bundle it. Bun's 1.4.4 release lists Brotli among the areas its security fixes cover (Bun). .NET 8 to 11 use it in BrotliStream and in ASP.NET Core and HttpClient decompression, which are off by default. Check CI runners, containers, managed platforms, vendor products and Linux hosts where Node.js uses the system Brotli library.
2. Patch, then restart or rebuild. Node.js 22.23.4, 24.22.1 or 26.12.1. Bun 1.4.4 or newer. .NET 8.0.33, 9.0.22 or 10.0.14, then restart the apps; rebuild self-contained apps and republish NativeAOT apps, because updating the shared runtime doesn't replace a decoder already linked into the executable. Brotli 1.0.10, 1.1.1 or 1.2.1 for anything built against it directly. Rebuild and redeploy container images.
3. Plan the move off end-of-life Node.js. Lines 25, 23, 20 and older get no fix, and Node.js notes that end-of-life versions are always affected when a security release ships. Until they move, cut their exposure. How to Protect End-of-Support Applications on Supported Servers covers the time in between.
4. Treat proxy rules as a stopgap. Rejecting Brotli-compressed request bodies at the reverse proxy narrows the inbound path. It does nothing for responses your services fetch, and only the update removes the flaw. For .NET, Microsoft's interim advice is to stop decompressing attacker-controlled Brotli data until you update.
5. Hunt back to October 21 at least, when the fixes and the advisory went public. On servers that run affected Node.js, Bun or .NET services, look for shells and other child processes those services started, new files in application directories, new scheduled tasks and unexpected outbound connections.
6. Close the side doors Cairn's agents look for. NorForge's busiest cluster told its agents to prioritize unauthenticated endpoints, file uploads, deserialization and authentication bypass. Lock down exposed admin and control panels. Review upload and deserialization endpoints on anything internet-facing. Rotate secrets on any server you can't clear, since NorForge found operators feeding agents credentials harvested elsewhere.
7. Test with vendor-verified checks, not proof-of-concept code. Exploits for this flaw have been tied to one build at a time, so a clean result from someone else's exploit code proves little.

What should you ask any vendor?

Put the same seven questions to every vendor, Mimic included. A good answer is specific, measured and admits a limit.

1. Where does the control sit, and which direction does it see? An inbound rule never sees a Brotli response your service fetches.
2. What does it see when an attack never leaves the process? If the answer is everything, ask how.
3. What does it need before it protects? A rule for this CVE, a learning period or a baseline. Ask how long that takes.
4. Which runtimes, operating systems and distributions does it cover? Check it against where Node.js, Bun and .NET run, containers included.
5. What record does it keep, and how far back? That record answers "were we hit?" for the days since October 21.
6. How is a safeguard tested before it goes live? Ask to see what it would block on your own servers first.
7. How long did protection take after disclosure? Ask for timestamps, from the advisory to a safeguard running on a customer's server.

Where does Mimic Networks fit?

At the operating system boundary, on servers running Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later; servers on Ubuntu, Debian and other distributions fall outside that list. Mimic decides inline, before the change executes. Mimic stops exploitation at the point of execution. Mimic Networks Change Control monitors and tracks every change on a protected server, authorized and unauthorized, so security and GRC teams have a forensic record of what changed.

Mimic Networks' Virtual Patching works in two forms, and both require baselining. Disruption blocks the specific mechanism an analyzed vulnerability depends on, so the exploit doesn't succeed. Containment limits what an exploit can do once it lands, so one safeguard can cover a whole family of exploits. It's part of Mimic's known-good enforcement approach. Before a Virtual Patching safeguard goes live, Mimic replays it against the host's recorded behavior to show what it would block.

Mimic runs alongside EDR. The difference is the question each asks at the kernel: EDR asks whether activity matches an attack it recognizes; Mimic asks whether the change was authorized. Mimic AI Guardrails and Virtual Patching are separate solutions in the Mimic Platform. Both govern threats that agentic AI presents. AI Guardrails governs what AI agents do inside the environment. Virtual Patching closes the exposure that AI-accelerated vulnerability discovery opens before a vendor patch exists.

For a flaw in a language runtime, our PHP2Shell post spells out what containment does and doesn't do. For Node2Shell, the patch is the fix.

Updates

October 28, 2026: Published, with every fact checked on October 28, 2026, including CISA's Known Exploited Vulnerabilities listing on October 27 and The Hacker News' update of October 28.