Brief · Builders

Your agent builder is the front door

By alkizz · Oct 30, 2026

On Oct 29, Wiz published "The Rise of Agentic Attacks", Avigayil Mechtinger's write-up of three intrusions that, per Wiz, look like the work of AI agents rather than people at keyboards. The tradecraft is interesting, but the useful part for builders is simpler: two of the three began at AI tooling. One was an exposed Flowise instance, and the other was an AI-agent backend whose MCP interface let the attacker choose the command it ran. The third came in through a Java enterprise operations gateway, so this isn't a story where every road leads to your agent stack, but two out of three is enough to make the point.

Wiz names no CVE, product version or victim for any of the three, and it hedges its own language with phrases like "appear to handle" and "potentially orchestrate". We'll keep that hedge, and anything below that isn't confirmed is marked as reported or per Wiz.

What Wiz says it saw

Case A: Flowise. The target, per Wiz, was "Exposed Flowise - LLM-workflow / AI-agent builder (Node.js)", and the way in was "Unauthenticated POST /api/v1/node-custom-function + x-request-from: internal auth bypass; injected JS uses Puppeteer to spawn /bin/sh". From there, in Wiz's words, it "Turned the instance into a staging node to mass-exploit dozens of other exposed Flowise instances of the same software", on port 3000. Wiz describes about 24 hours of activity and 99 scripts, nearly all opening with a written plan in Chinese, and a probe list that also tried a 1.x "fetch-links SSRF / arbitrary file read" and a "get-upload-file path traversal / attachments arbitrary write", so this wasn't one bug on repeat. For persistence it used "SIGUSR1 opens the inspector → register a hidden route in the live process via CDP", which is a backdoor that lives in memory.
Case B: a Java gateway, not AI tooling. The target was a "Java enterprise operations gateway", entered via "Java RCE - JVM spawned a shell (java → jspawnhelper → sh)". From there, per Wiz, it ran a base64 C2 beacon loop through "602 unique steps across 12 technique families" in "~4.5h", covering IMDS, Kubernetes service-account tokens, RabbitMQ, Hazelcast, ArgoCD, an InfluxDB-Flux SSRF and the Kubernetes dashboard. No product or CVE is named.
Case C: an AI-agent backend with an MCP interface. The target was an "AI-agent GraphQL backend (MCP interface)", and the way in was "Attacker-controlled MCP mcpCommand/mcpArgs → create_subprocess_exec → shell". Wiz says that "lead to a bulk secret exfiltration, including cloud-credential and Kubernetes token", that the attacker persisted with "/dev/shm/.x/c.py, dialing :19001" and that it "replicated across several pods". It ran about 21 hours with "150+ distinct scripts chasing ~25 target organizations (major crypto exchanges and fintechs)". This was the organization's own backend, not a named public tool, but if "a field that sets the command" sounds familiar, it's the same shape as the Langflow MCP bug and the MCP command injection batch.

The Flowise advisories that best match

Wiz doesn't name a CVE, so this mapping is ours, not Wiz's. Going through the FlowiseAI GitHub advisories and NVD, these are the ones that best match what case A describes:

CVE / GHSA	What	Affected → fixed	Auth, per the advisory
CVE-2026-30820 / GHSA-wvhq-wp8g-c7vq	"Authorization Bypass via Spoofed x-request-from Header", and it names `/api/v1/node-custom-function` as reachable	≤3.0.12 → 3.0.13	Authenticated: "allowing an authenticated tenant session to bypass all /api/v1/** authorization checks"
CVE-2026-46442 / GHSA-9rvc-vf7m-pgm2	"Authenticated Host RCE via POST /api/v1/node-custom-function and NodeVM Sandbox Escape"	≤3.1.1 → 3.1.2	"this is not unauthenticated"; exposed in the default config when `E2B_APIKEY` is unset
CVE-2026-73483 / GHSA-9gvv-qjj3-2p6g	"NodeVM sandbox escape via puppeteer allowlist" through node-custom-function, which matches Wiz's "Puppeteer to spawn /bin/sh"	≤3.1.2 → 3.1.3 (flowise and flowise-components)	Authenticated. 2.0.0–3.0.7 have no gate, 3.0.8–3.1.2 are exposed if `ALLOW_BUILTIN_DEP=true`, and it runs as root in the official Docker image

There's also an older, related one, GHSA-5w3r-f6gm-c25w, a Puppeteer/Playwright sandbox bypass fixed in 3.0.8. GitHub tags it CVE-2025-26319, but NVD describes that CVE as a v2.2.6 file-upload bug the advisory chains with. None of these, and no Flowise entry at all, is in CISA's KEV catalog (version 2026.10.29), and NVD shows no KEV add date for the three CVEs in the table.

The auth question isn't settled

Wiz calls case A "Unauthenticated". All three matching advisories describe flaws that need a login, and the node-custom-function one goes out of its way to say "this is not unauthenticated". Those two accounts don't fit together, and nobody has explained how the attackers got in without credentials, so treat this as unresolved. Wiz did report that the attacker found one target with "CUSTOMIZED WHITELIST_URLS (42 entries vs the standard 20)", which left the "whole management surface" open, but nobody has said that's what happened across case A, and Wiz doesn't give the Flowise versions involved either. The practical upshot doesn't change: if your Flowise is on the internet, don't lean on "but it needs a login".

Patching isn't the whole answer for Flowise

Upgrading to at least 3.1.3 covers all three bugs in the table, and npm's latest is 3.1.4 (Jul 29, 2026), which also fixes several later advisories, so 3.1.4 is the version to be on. The catch is that GitHub shows FlowiseAI/Flowise as "archived by the owner on Aug 13, 2026", read-only, and two advisories (GHSA-rpcc-gw54-mfgx and GHSA-jvx3-mjpw-r4gh) list 3.1.4 and earlier as affected with no patched version. Both need a logged-in user, and the BullMQ one only applies in queue mode with its dashboard turned on, but nobody is shipping fixes to an archived repo. We couldn't confirm whether anyone still maintains Flowise, but an archived repo with open holes isn't a patch-and-forget situation. Upgrade if you're behind, and then take it off the internet or plan a move off it.

A word on Hermes

Wiz also cites Hunt.io's Jul 23 report on Thailand's Ministry of Finance, where attackers ran the Hermes AI agent in "unattended or YOLO mode, bypassing approval prompts". Hermes was the attackers' own tool, running on their own staging server, so it wasn't the way in and this isn't a Hermes vulnerability. Per Hunt.io, "How initial access was obtained was not immediately evident".

The other cases Wiz rounds up check out against their sources, with a couple of nuances. Microsoft "assesses that Storm-0940 was responsible for the recently disclosed ConnectWise supply chain compromise" (Wiz says "attributed"). It reports that Storm-0940 "used ARTEX to attempt to sign-in to more than 2,250 tenants", with "multiple instances where the time from initial targeting to privileged access was less than 3 hours", and adds that "the majority of the targeting wasn't successful", which is the ConnectWise story from our standing-access brief with a new name attached. CrowdStrike reports "four previously unreported threat actors" active May–Aug 2026, and Zscaler puts an ARTEX campaign in South Korea at "approximately 67,000 individuals". JPCERT/CC says attackers "had used AI to scan for known vulnerabilities and carry out attacks via APIs", but the server with internal-network and web-shell artifacts was, per JPCERT, "a separate server not directly related to these attacks", which Wiz blends in.

How to spot an agent attacking you

Wiz lists seven fingerprints, and the short version is that agents are thorough, chatty and tidy in ways people usually aren't:

Machine-paced, sustained work. The cadence varies with how hard each step is, and it keeps going for hours.
Reasoning written into the tooling. Scripts carry written rationale and attack plans, in plain language.
Self-correction. It reads results, figures out why something failed and rewrites its approach, so you see versioned scripts.
Checklist-style breadth. Templated, breadth-first enumeration that covers nearly every technique in the book, as case B's 602 steps show.
Verbosity. It tries many lateral-movement paths at once, loudly.
Probe before payload. A harmless marker goes first, then the payload, with bounded output and cleanup afterwards.
Descriptive throwaway artifacts. Disposable, helpfully named files in /tmp, sometimes carrying the attacker's own identifiers.

Wiz's point about noise matters here: agentic attacks are "noisy", so a burst of activity is a reason to correlate, not something to wave off as "just automation".

The score

I'd call it a 3, patch normally. The tradecraft is real and fast, and Flowise is being sprayed at dozens of exposed instances, per Wiz, but the matching bugs have fixed versions, none is in KEV, and you have to have put an agent builder on the internet to be in case A's blast radius. If you have an exposed Flowise, though, your own copy is more urgent than the score, because "upgrade" isn't a complete fix for an archived project. The checks below are sized for a home lab or a small team.

What to do:

Take Flowise off the internet, or migrate off it.
- Why: Wiz says case A sprayed "dozens" of exposed instances on port 3000, the repo has been archived since Aug 13, 2026, and two advisories have no fix even in 3.1.4.
- How: check whether port 3000 (or wherever you run it) answers from outside, for example with ss -tlnp on the host and a test from another network. Bind it to localhost or put it behind a VPN with auth on, and start planning a replacement rather than waiting for a release that may not come.
If you keep it for now, get to 3.1.4.
- Why: below 3.0.13 you're exposed to the header bypass, below 3.1.2 to the node-custom-function RCE, and 3.1.2 or lower to the Puppeteer escape that matches Wiz's description.
- How: run npm ls flowise or check your Docker image tag, then upgrade to 3.1.4.
Make sure login is actually enforced.
- Why: the auth question in case A is unresolved, and Wiz's attacker found a target whose customized WHITELIST_URLS left the "whole management surface" open.
- How: confirm every management path asks for credentials from a fresh browser, and compare your whitelisted paths against the default list. Anything you added "temporarily" is a good place to start.
Strip the x-request-from header at your proxy.
- Why: CVE-2026-30820 says that header alone decided access, and case A used x-request-from: internal.
- How (our suggestion, not vendor guidance): in your reverse proxy, strip or reject any inbound x-request-from header from external clients before the request reaches Flowise.
Tighten Flowise's sandbox settings and run it as non-root.
- Why: from 3.0.8 on, CVE-2026-73483 needs ALLOW_BUILTIN_DEP=true (older versions have no gate), CVE-2026-46442 applies when custom functions run in NodeVM, and the official Docker image runs as root.
- How: leave ALLOW_BUILTIN_DEP unset or false, know that without E2B_APIKEY your custom functions run in NodeVM, and run the container as a non-root user.
Check that nothing lets a user set an MCP command.
- Why: case C got its shell because an API field accepted mcpCommand/mcpArgs and fed them to create_subprocess_exec.
- How: list every MCP server you run with its command and args, and make sure no API or UI field lets a user set command or args. The Langflow brief has the same lesson from the other side.
Assume the agent host's secrets are the attacker's secrets.
- Why: per Wiz, all three cases went after the cloud metadata service (IMDS), and cases B and C also went after Kubernetes service-account tokens.
- How: treat everything the agent process can read as exposed, including env vars, cloud credential files, SSH keys and SA tokens. Enforce IMDSv2 with a hop limit, but don't count on it alone (case C fetched an IMDSv2 token), and don't mount service-account tokens the workload doesn't need.
If you think you were hit, preserve before you restart.
- Why: case A planted its hidden route in the live Node process, so a restart may wipe the evidence.
- How: capture process state and note any open inspector port first. Then look for /tmp/.cXXXX.sh-style scratch scripts (Wiz's placeholder; they delete themselves, so check logs too), node -c checks, POSTs to /api/v1/node-custom-function, requests carrying x-request-from: internal, outbound scanning to many hosts on :3000, /dev/shm/.x/, base64 -d | /bin/sh beacon wrappers and RabbitMQ global parameters named after C2 hosts (Wiz shows /api/global-parameters/evil@<C2-IP>). After that, rotate everything the host could reach: API keys, the Flowise credential store, cloud credentials, SA tokens and database credentials.
Small teams: pull the cloud and identity logs too.
- Why: cases B and C went after Kubernetes and cloud credentials, and Microsoft's ConnectWise/Storm-0940 guidance covers service-principal sign-ins.
- How: check Kubernetes audit logs for SelfSubjectRulesReview, secrets list and TokenRequest, and CloudTrail for use of node or IRSA credentials. If you use ConnectWise Cloud Backup for Microsoft 365, review M365 service-principal sign-ins from at least Oct 15, extending to Oct 1, with successful and failed sign-ins reviewed separately, keep affected ConnectWise app connections disabled until ConnectWise provides restoration instructions, and on confirmed suspicious activity, revoke unnecessary permissions and rotate credentials, as Microsoft advises. More in the ConnectWise brief.

Sources

← All briefs