DEV Community: VOIR LABS

Northflank is the ninth AI platform breach this month. Make a stolen AI key worth less.

VOIR LABS — Fri, 13 Nov 2026 15:14:22 +0000

Originally published on voirlabs.io by Moosa Jafri.

An AI provider key stored as an environment variable on a hosting platform is only as safe as that platform, and in October nine of them disclosed incidents. The useful response is to plan for the next leak: make a stolen copy of your key able to do very little, and make its misuse loud within the first hour. This article walks through what attackers did with stolen keys, based on Wiz's investigation, and a small gateway design that limits the damage.

Nine platforms, one target: the environment variables

On October 30, Wiz published "Black October for AI Developer Platforms", listing incidents at Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank. Its reading of the public reports: they "highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access." It also says "there is no single vulnerability or dependency linking these attacks".

The platforms' own words point the same way. Railway's October 21 disclosure says an unauthorized party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents", and that it believes this "is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." BleepingComputer reported on October 20 that at Zeabur an attacker used "leaked internal credentials stored in plaintext" and stole "over 3.2 million environment variable records". On October 31 it reported Northflank's warning to customers: "Assume all environment variables have been decrypted. Disable/rotate all keys," followed by "Users have reported unauthorised use of AI API keys supplied to the Northflank platform".

One label. Wiz has not confirmed that one group is behind all nine incidents, and Northflank has not said how attackers got in.

A stolen key goes quiet for days before the flood

Wiz traced two enterprise Amazon Bedrock credentials that had been stolen through vendor breaches. Its timeline is the most useful part of the report, because it shows when a defender could have noticed.

Validation. The first unauthorized activity on both keys came "within 30 minutes of the reported credential access within the vendor breach": a single InvokeModel call from a residential address, part of a sweep that tested stolen keys across organizations.
The quiet period. Afterwards both keys saw "only a trickle of traffic: 14–120 calls a day from the same small Go client", which Wiz reads as a job checking that the keys still worked.
The probe. On the first key, four days after validation, a proxy pool sent "one call per model across vendors": Amazon Nova, DeepSeek, gpt-oss, GLM, Kimi, Grok, GPT-6 Astra and older Claude models.
The flood. Over thirty hours the first key made about 800,000 Bedrock calls, about 90% of them successful. The second made about 1.7 million in thirteen hours, over a million successful. Wiz estimates the two "likely ran up over $100k in usage" at list price, and says the traffic looked like "resold coding-agent traffic."

Two numbers are worth putting side by side. By our arithmetic, 1.7 million calls in thirteen hours is about 36 calls a second; during the quiet period the same key made at most 120 a day. And the probe asked for models across several vendors in one sweep. If an app only ever calls one or two models, a request for any other model is a signal that arrives days before the bill.

The restricted key held for four hours

The second key in Wiz's report was scoped. Its policy allowed Bedrock "only through us.* cross-region inference profiles", and the reseller pool that picked it up asked for global.* profiles. For four hours, thousands of calls failed. Then a checker found the model IDs that worked, and the flood began.

That's the honest lesson on scoping. A narrow policy cost the attacker time and produced thousands of failed calls that someone could have alerted on. It didn't stop the abuse, because the allowed path was still worth money. Scope is a delay and an alarm; a ceiling on volume is what limits the bill.

Keep the provider key in one place you run

Our approach for a team with several apps calling a model: the provider key lives only in a small gateway you operate, and each app gets its own token for that gateway. The app token is what sits in the hosting platform's environment variables. A sketch of how we would write the gateway's admission check, in TypeScript:

type AppPolicy = {
  models: Set<string>;  // the exact model IDs this app uses
  callsPerHour: number; // near normal use, far below the quota
};

const policies = new Map<string, AppPolicy>([
  ["support-bot", { models: new Set(["your-model-id"]), callsPerHour: 600 }],
]);

const usage = new Map<string, { hour: number; calls: number }>();

// Returns null to admit; the gateway then adds the provider key.
export function admit(appId: string, model: string): string | null {
  const policy = policies.get(appId);
  if (!policy) return "unknown app";
  if (!policy.models.has(model)) {
    alert(appId, `asked for ${model}, which it never uses`);
    return "model not allowed";
  }
  const hour = Math.floor(Date.now() / 3_600_000);
  const seen = usage.get(appId);
  const calls = seen?.hour === hour ? seen.calls + 1 : 1;
  usage.set(appId, { hour, calls });
  if (calls > policy.callsPerHour) {
    alert(appId, `${calls} calls this hour`);
    return "over hourly ceiling";
  }
  return null;
}

declare function alert(appId: string, why: string): void;

Notice what a stolen app token is worth here. It reaches one model, so a catalog probe like the one in Wiz's report fails on its first unfamiliar model and pages someone. And at 36 calls a second, a ceiling of 600 calls an hour is reached in under twenty seconds, by our arithmetic, so a flood stops at the ceiling instead of running for thirteen hours. Set the ceiling from your own usage, with headroom for your busiest hour.

Because the gateway is yours, revoking a leaked app token takes one change, and the provider key never needs to rotate across every app at once.

Where this costs you

The gateway is now the secret worth stealing, so it doesn't belong on the same shared platforms. Run it where you already keep production secrets, and give it the cloud's short-lived credentials where your provider supports them, rather than a long-lived key in a variable.

It adds a hop to every model call and one more service to keep up. Ceilings set too tight will block a real traffic spike, which means a support bot going quiet on your busiest day; start with alerts only and turn on blocking once you trust the numbers. And none of this replaces rotation. If your keys sat on any of the nine platforms, rotate them now and check your provider's billing for October.

If you run one app with one key and little traffic, skip the gateway. Give the key the narrowest model scope your provider allows, set a spending alert, and keep it off shared hosting.

What to take from Black October

Treat every AI key in a hosting platform's environment variables as exposed the day that platform discloses a breach, and rotate it that day.
Scope each key to the models it uses. Wiz's restricted key bought four hours and thousands of failed calls.
Alert on the two signals in Wiz's timeline: a request for a model the app never uses, and calls far above the usual hour.
Cap volume per app, because a scoped key can still be drained through its allowed path.

If you want a second opinion on where your AI keys live and what a stolen one could reach, book a conversation.

Sources

Wiz Research, "Black October for AI Developer Platforms", Benjamin Read and Rami McCarthy, October 30, 2026: https://www.wiz.io/blog/black-october-for-ai-developer-platforms
Railway, "Security Disclosure: Wednesday October 21st", Jacob Cooper, October 21, 2026: https://blog.railway.com/p/security-disclosure-wednesday-october-21st
BleepingComputer, "Northflank security breach leads to abuse of customers' AI API keys", Lawrence Abrams, October 31, 2026: https://www.bleepingcomputer.com/news/security/northflank-security-breach-leads-to-abuse-of-customers-ai-api-keys/
BleepingComputer, "Zeabur shutting down after second security breach in two months", Bill Toulas, October 20, 2026: https://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/

A Web3 library shipped malware to npm with valid provenance. Block install scripts you never reviewed.

VOIR LABS — Fri, 13 Nov 2026 15:13:46 +0000

Originally published on voirlabs.io by Asad Naeem.

When npm install script malware turns up, the first suspect is a stolen npm token. This weekend's case points elsewhere: SafeDep found it "points to a compromised bot account or token, not a stolen npm token." A compromised release of @ethersphere/bee-js, the JavaScript client for the Swarm storage network, ran attacker code the moment it was installed, and it was published by the project's own release workflow with valid npm provenance. Every CI job, build server and coding agent that runs an install unattended runs that code with the machine's secrets. This article covers what happened, why the provenance badge did not help, and the check we would add so a new install script cannot run until a person has looked at it.

What happened

StepSecurity found that bee-js 13.3.0, "Published to npm on November 9, 2026, at 00:09:50 UTC, the release downloads and executes attacker-controlled JavaScript during installation." The payloads "target Swarm Desktop wallet files and attempt to install persistent access on Linux, macOS, and Windows."

The change that made it work was small. SafeDep's analysis shows two edits to package.json: the version script moved from prepare to postinstall, and the scripts folder was added to the files shipped in the package. In SafeDep's words: "With postinstall, the script runs on every install."

What it took is the part for wallet builders. The payload reads two files from the Swarm Desktop data folder. StepSecurity explains that "The swarm.key file is an encrypted Ethereum V3 keystore. The configuration can contain the password needed to decrypt it." SafeDep adds that 30 minutes later, the same code went into Swarm Desktop 0.56.2.

npm removed 13.3.0 at about 01:24 UTC, according to SafeDep, so it was live for roughly 75 minutes. During that window, StepSecurity noted, npm "still mapped latest to 13.3.0".

Why provenance did not help

Provenance answers one question: was this package built from this repository by this workflow? Here the answer was yes. StepSecurity: "The npm package therefore carries valid SLSA provenance linking it to the legitimate repository and workflow. The malicious code was already in the source that the workflow built."

The attacker used the project's release bot identity to create a commit, a tag and a GitHub release, and the release started the normal publish workflow. SafeDep found that the workflow "runs tests only for code pushed to a branch, so it ran none here", and that "Anyone who can create a release in this repository can publish code to npm with provenance."

Version ranges did the rest. StepSecurity lists Ethersphere's own tools depending on bee-js through ranges such as ^13.2.0 and ^13.0.0, and notes that "These ranges permit 13.3.0." Any fresh install or lockfile update in that window could pick it up.

Make install scripts opt-in

The attack needed one thing on your side: a package manager that runs a dependency's postinstall without asking. We would turn that off and keep a short list of packages that are allowed to run scripts. With npm, that means ignore-scripts=true in .npmrc, plus a CI check that fails when the lockfile adds a package with an install script nobody has reviewed. Here is a sketch of that check, reading the hasInstallScript flag npm writes into package-lock.json:

// Fail CI when a dependency with an install script appears
// that nobody has reviewed. Run it on every lockfile change.
import { readFileSync } from "node:fs";

type Entry = { version?: string; hasInstallScript?: boolean };
type Lock = { packages: Record<string, Entry> };

// Packages a person has read and allowed to run on install.
const ALLOWED = new Set(["esbuild", "sharp"]);

const raw = readFileSync("package-lock.json", "utf8");
const lock: Lock = JSON.parse(raw);
const flagged: string[] = [];

for (const [path, entry] of Object.entries(lock.packages)) {
  if (!path || !entry.hasInstallScript) continue; // "" is the root
  const name = path.split("node_modules/").pop() ?? path;
  if (!ALLOWED.has(name)) flagged.push(`${name}@${entry.version}`);
}

if (flagged.length > 0) {
  console.error("Install scripts need review:", flagged.join(", "));
  process.exit(1);
}

What to notice: bee-js would have failed this check the day it gained a postinstall, even with valid provenance, because the check looks at what the package does on install and not at who built it. The allowlist is per package name, so a reviewed package that later changes its script still slips through. Pair it with a lockfile diff in review, and keep wallets, keystores and deploy keys off the machines that run installs.

If you maintain a package, the lesson from the other side is to put a person between a release and a publish. A GitHub environment with required reviewers on the publish job means a stolen bot token can still cut a release, but it cannot ship it to npm alone.

Where this costs you

Some packages need their install scripts: native modules and binary downloaders such as image or bundler tools. With scripts off, they break until you add them to the allowlist or run their build step yourself, and each one is a package someone has to read.

The check only sees install scripts. A malicious package that does its damage when your code imports it passes untouched, and so does a compromised version of a package already on the allowlist. It narrows one common path and leaves the others.

Pinning exact versions and installing from a lockfile stops a range from picking up a bad release mid-week, but it moves the risk to the day you update. Updating after a release has been public for a day or two, rather than within the hour, would have stepped around this one, at the cost of slower security fixes.

What to take from this

If anything installed @ethersphere/bee-js 13.3.0 or Swarm Desktop 0.56.2, treat that machine as compromised and move any wallet it held.
Read provenance as proof of where a package was built, not of what is in it.
Turn off dependency install scripts by default and allow them per package after a review.
Fail CI when the lockfile adds an install script nobody has reviewed.
If you publish packages, require a person to approve the publish job.

If your team ships wallets, dApps or Web3 products and wants a second pair of eyes on its build and release pipeline, book a conversation.

Sources

StepSecurity, Ashish Kurmi, "@ethersphere/bee-js 13.3.0 Compromised", November 8, 2026: https://www.stepsecurity.io/blog/ethersphere-bee-js-13-3-0-compromise
SafeDep, "Compromised bee-js and Swarm Desktop Steal Swarm Wallet Keys", November 9, 2026: https://safedep.io/blog/ethersphere-bee-js-npm-compromise

Docker's agent sandbox leaked through its copy command. Check every path that crosses the wall.

VOIR LABS — Fri, 13 Nov 2026 15:13:11 +0000

Originally published on voirlabs.io by Ijlal Ishaq.

A sandbox for an AI agent is only as strong as the least guarded way in or out of it. Docker Sandboxes put a coding agent in its own virtual machine and let it see only the folders you approve, and that part held. The gap was the copy command next to it. By the end of this article you will know why that keeps happening, and what a file channel that respects the boundary looks like in code.

The allowlist held. The copy command did not ask it.

Docker Sandboxes runs agents such as Claude Code, Codex and Gemini CLI inside a microVM with its own kernel, filesystem and network. You grant it specific folders, usually the project workspace, and those folders are shared into the VM. Together they form an allowlist: the only parts of your machine the agent is supposed to reach.

On November 3, Peyton Kennedy of Endor Labs published CVE-2026-103916, a flaw he found in sbx cp, the command that moves files between the sandbox and your machine. The copy runs on your side, with your permissions, and never consults the allowlist. In Kennedy's words, the CLI "resolves symlinks in the paths it is given and acts on the resolution."

The agent controls those links, because the workspace is granted read and write. So it can replace a folder in the workspace with a link to somewhere else on your machine. Inside the VM the link points nowhere, so planting it gains the agent nothing on its own. It takes effect when you run an ordinary copy that passes through that folder. Kennedy shows both directions: a copy out of the sandbox overwrites a file outside the workspace, and a copy in pulls a host file into the sandbox.

The command did have a guard, the -L flag, but it checks only the last part of the path. A symlink can sit in any of four positions, and in the researcher's table "Three of the four positions are open." Endor Labs rates it high, 8.2 on CVSS 3.1.

The fix took two tries

Endor Labs reports that Docker first planned the fix for version 0.48.0 on October 13, and that "after the initial patch was live, the Docker team determined the fix was incomplete." Docker's own release notes for 0.51.0, dated November 3, confirm the final change: "sbx cp blocks symbolic links in mounted directories from escaping onto other host paths." If you run Docker Sandboxes, upgrade to 0.51.0.

This is also the second sbx cp escape this year. An earlier one, CVE-2026-17106, was fixed in 0.38.0, and Kennedy notes that its containment still works. It checked paths inside the archive being copied, not where the copy itself started or landed.

Why the second path gets missed

Kennedy's own summary is the part worth keeping: "the isolation primitive worked, and the failure was a second path to the host that the security model did not account for." He found the same shape earlier this year in another agent sandbox, brig.

The reason is ordinary. A sandbox is designed around its main channel, the shared folder, and that channel gets the allowlist and the tests. Side channels that move files on the operator's behalf, such as copy, export, download and artifact upload, look like the operator's own action, so they inherit the operator's trust. When the agent controls the path, that trust is spent wherever the agent points it.

Anything that lets an agent produce files on a real machine has these side channels: a build step that collects outputs, a tool that saves an attachment, a job that syncs a report to shared storage. Each one needs the boundary checked again, at the moment it touches the disk.

A copy that stays inside the workspace

Here is a sketch of how we would write the host side of a copy out of an agent's workspace in Node. It is ours, not Docker's code.

import { constants, promises as fs } from "node:fs";
import path from "node:path";

// Write bytes to a path inside the workspace, or refuse.
export async function writeInside(
  workspace: string,
  relPath: string,
  data: Uint8Array,
): Promise<string> {
  const root = await fs.realpath(workspace);
  const target = path.resolve(root, relPath);
  // Resolve every directory on the way, not only the file name.
  const dir = await fs.realpath(path.dirname(target));
  if (dir !== root && !dir.startsWith(root + path.sep)) {
    throw new Error(`refused: ${relPath} resolves to ${dir}`);
  }
  const file = path.join(dir, path.basename(target));
  // O_NOFOLLOW: if the file itself is a link, fail.
  const flags = constants.O_WRONLY | constants.O_CREAT |
    constants.O_TRUNC | constants.O_NOFOLLOW;
  const fh = await fs.open(file, flags, 0o644);
  try { await fh.writeFile(data); } finally { await fh.close(); }
  return file; // print it, so a person sees where it landed
}

Notice three things. The check runs on the resolved parent directory, which is exactly the position -L left open. The final open refuses to follow a link in the last position. And the function returns the real path, so the caller can print it; Kennedy points out that a successful sbx cp printed nothing, so a person watching had nothing to notice. A copy in is the same check on the source.

Where the sketch stops

A path check and the write that follows it are two steps. An agent that can rewrite its workspace while the copy runs could swap a folder for a link in between. On Linux, openat2 with RESOLVE_BENEATH makes the kernel enforce the boundary during the open itself, and Go code can use a library such as cyphar/filepath-securejoin, which Kennedy notes was already linked into the sbx binary. Use those where you can. The sketch shows the rule; the kernel enforces it.

If your agent never writes outside a VM and nothing it produces is copied back, none of this applies. The moment its output lands on a machine you use, it does.

What to take from it

Upgrade Docker Sandboxes to 0.51.0, and until you have, resolve a path yourself before you copy to or from a workspace.
List every channel that moves files between your agent and a real machine, not only the shared folder.
Check the boundary on each one after resolving every part of the path, at the moment of the write.
Show the resolved path whenever a copy succeeds.

If you are putting agents in front of real systems and want the file paths checked before they ship, book a conversation.

Sources

Endor Labs, Peyton Kennedy, "Docker Sandboxes vulnerability lets AI agents access sensitive files outside their sandbox (CVE-2026-103916)", November 3, 2026: https://www.endorlabs.com/learn/docker-sandboxes-vulnerability-lets-ai-agents-access-sensitive-files-outside-their-sandbox-cve-2026-103916
Docker, Docker Sandboxes release notes, version 0.51.0 (2026-11-03): https://docs.docker.com/ai/sandboxes/release-notes/