DEV Community: CortexFlow

PHP2Shell: Two Critical PHP RCEs (CVSS 9.2) Leaked a Day Early — Check Your Version and Patch Today

CortexFlow — Thu, 22 Oct 2026 08:30:10 +0000

Two vulnerabilities in PHP itself — not in WordPress, not in a plugin, in the interpreter — give an unauthenticated attacker remote code execution on effectively every PHP release since 5.4. The details leaked on October 20, a day before the planned disclosure, and PHP shipped an emergency out-of-cycle fix on October 21. By the end of this article you will know whether your servers are exposed, exactly which versions fix it, and how to check for signs that someone got there first.

One boundary up front: this is a defender's guide. It explains how the bugs work at the level you need to patch and hunt, links the primary sources, and contains no exploit code and no links to proof-of-concept repositories — including the fake ones, which are worse than useless (see the warning in Step 4).

What happened: a disclosure that leaked a day early

The flaws were found and reported to the PHP security team in August 2026, and were working through a normal coordinated disclosure with a planned reveal on October 22. The timeline then broke:

October 20, 2026: A Hacker News post and screenshots of a private exploit tool named "PHP2Shell" — credited to the researcher Calif — leaked the two CVE IDs and claimed the bugs hit every PHP release since 5.4.0. The post was taken down; the screenshots were already everywhere.
October 20, 19:33 UTC: PHP published an advance notice of an emergency security release and moved publication up a day, to October 21 at 14:00 UTC. watchTowr confirmed the leak was genuine and said it had reproduced both vulnerabilities.
October 21, 14:00 UTC: PHP released the fixes — 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — with the full advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). Both are rated CVSS v4.0 9.2 by the PHP security team.
The story is big enough that Wikimedia took its Phabricator instance offline as a precaution, and the pair already has a Wikipedia article.

The discoverers credited across the reporting — Calif (Calif Research), Wiz, and OpenAI — and the role AI played in building the exploit chain are covered in the AI section below; Check Point's write-up is a good second source for the timeline. First, the bugs themselves.

How the two bugs work, in plain language

Some terms, defined once. RCE (remote code execution) means an attacker runs their own code on your server, with the permissions of the web server process. A SAPI is the layer that connects PHP to a web server — PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP and LiteSpeed are all SAPIs, and all of them are in scope here. A worker is one long-lived PHP process inside those servers: it handles a request, cleans up, and handles the next one, thousands of times. That reuse is the heart of the second bug.

CVE-2026-109618 — corruption through an out-of-memory crash. PHP sets a per-request memory limit. When a request runs out of memory mid-flight, PHP aborts it and runs cleanup. If the memory runs out at one specific moment — while PHP is still setting up the request's internal data structures — that data is only half-initialised, and the cleanup code can be made to treat the half-formed data as if it were valid. An attacker who can force memory exhaustion at the right instant (crafted multipart form submissions are one way to burn memory) corrupts the interpreter's own state, and from there reaches code execution.

CVE-2026-109619 — stale state that outlives its request. Some internal state belongs to a single request and lives in memory the request owns. In this bug, that state can survive after its memory has been freed, and a global pointer still refers to it. When the next request lands on the same worker — remember, workers are reused — it can end up using the leftover state before normal initialisation resets it. This is the classic shape of a use-after-free: a program uses memory after giving it back, so whatever now occupies that memory is treated as something it is not. One confirmed path runs through Session Upload Progress, a default-on feature (session.upload_progress.enabled) that tracks file-upload progress in the session; PHP is explicit that other variants exist.

One PHP worker, drawn as a bench press with the Anatomy figure kit. Request 1 machined its part and left it standing in the memory tray — the orange block. Its tray was then freed and hoisted clear, empty, but the pointer arm never let go of the part. Notice: the press does not care that the part's owner is gone. When request 2 rides in on the carriage, the press works on whatever that pointer still finds — one request's leftover state, consumed by another request on the same worker. That is CVE-2026-109619, and it is also why restarting workers matters forensically: restart the press and the leftover part vanishes with the worker's memory.

Two properties make the pair dangerous together. Neither needs a login, a valid session, or any application bug — Wiz demonstrated unauthenticated RCE against current WordPress, Drupal and Joomla images, and notes that even a "Hello World" script is enough surface. And on mod_php, PHP rates the risk highest: the attack can succeed before any application code runs, so application-level firewalls and plugin security tools may never see a request they can judge.

Who is affected

Every PHP release from 5.4.0 through the versions below is affected by at least one of the two flaws. Fixes exist only for supported branches:

PHP branch	Status	Fixed version (released Oct 21, 2026)
8.5.x	Supported	8.5.12
8.4.x	Supported	8.4.27
8.3.x	Supported	8.3.36
8.2.x	Supported	8.2.35
8.1.x and older	End of life	No official PHP fix — upgrade branches, or apply a vendor/distro backport (the PHP team also published minimal source backports for 7.4, 8.0 and 8.1 for source builders)

SAPIs in scope: PHP-FPM, Apache mod_php (highest risk), php-cgi, FrankenPHP, LiteSpeed — in other words, if the PHP build serves web requests, it counts. CLI-only installs that never serve web traffic are not the concern; the forgotten PHP inside a container, a control panel, or a vendor appliance is.

What to do now

Step 1 - Find every PHP build you run

Servers accumulate PHP: the distro package, a second version for one legacy app, copies inside Docker images, a control panel's private build. Inventory all of them before patching any of them:

which -a php php-fpm php-cgi
ls /usr/bin/php* /usr/sbin/php-fpm* /usr/local/bin/php* 2>/dev/null
php -v
docker ps --format '{{.Image}}' | sort -u

which -a matters because it lists every PHP on the PATH, not just the default; the ls catches versioned binaries like php8.1 that nothing points to any more; and the Docker line reminds you that containers carry their own PHP that host patching never touches. Record the version of each build — that list is your patch checklist.

Step 2 - Patch to the fixed version, then restart the service

Install the fixed release for your branch from php.net or your distribution (distros and LTS vendors received the patches and several have shipped backports — check your vendor before assuming an old branch is stranded). Then the step people miss:

sudo systemctl restart php8.3-fpm        # adjust to your branch and SAPI
# Apache mod_php instead:  sudo systemctl restart apache2
php -v                                    # confirm the fixed version number

Warning: Updating the PHP package on disk does not update the code already running. FPM and Apache workers are long-lived processes holding the old interpreter in memory; until you restart the service (or the workers recycle), you are still vulnerable — "patched" on disk, exploitable in production. Verify with php -v and by confirming the service actually restarted, and remember containers need rebuilt images, not package updates inside a running container.

Step 3 - If you are on PHP 8.1 or older, make the EOL decision today

There is no official fix coming for end-of-life branches. Your real options are: upgrade to 8.2+ (test first — most 8.1 code runs on 8.2/8.3 with few changes), apply your distribution or LTS vendor's backport, or build from source with the PHP team's minimal backports for 7.4/8.0/8.1. "Wait and see" is not on the list: Sansec publicly expected mass scanning within minutes of the fixed release, because a patch is also a map — diffing it shows attackers exactly where the bugs live.

Step 4 - Hunt for compromise, evidence first

Patching closes the door; it does not tell you whether someone already walked through it. Before you restart anything, read this warning — it changes the order of operations:

Warning: If you find pre-exploit indicators on an unpatched host, preserve the forensic state before patching and restarting. CVE-2026-109619 lives in worker memory, and restarting the workers destroys that state. Snapshot the machine or capture logs and process state first, then patch.

Indicators defenders are hunting for (compiled from watchTowr, Check Point and Sansec reporting):

Multipart POSTs carrying a PHP_SESSION_UPLOAD_PROGRESS field, and large or malformed multipart POSTs generally
Repeated Allowed memory size exhausted fatals and request timeouts in PHP logs — the OOM bug leaves these behind
FPM/Apache worker segfaults or bursts of worker crashes and respawns
Unexpected files in the session save path, and new or modified .php files under web roots
Changes to auto_prepend_file / auto_append_file in any php.ini
Web server processes spawning sh, bash, curl, wget, nc or base64; new cron jobs, systemd units, users or authorized_keys entries

Starter commands for the log and file checks:

grep -h "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null | tail -20
grep -hi "Allowed memory size" /var/log/php*.log 2>/dev/null | tail -20
find /var/www -name "*.php" -newermt "2026-10-19" -print 2>/dev/null
grep -rn "auto_prepend_file\|auto_append_file" /etc/php/ --include="*.ini" 2>/dev/null

Treat hits as triage, not verdicts: a .php file modified on October 20 might be your own deploy. What you are looking for is correlation — upload-progress probes plus memory fatals plus a new file is a very different picture than any one of them alone.

Two defender tools help. OpenAI published a PHP2Shell checker on GitHub: two Codex skills — one checks a site by public URL, one runs on the server — that compare the detected PHP version against the fixed thresholds. It does not exploit anything; it is a version screen, and a site that hides its version header will come back "unknown." For hosts that cannot patch immediately, Syhunt's php2shell-protection toolkit collects emergency Apache mitigations (multipart blocking, request-size limits) — a stopgap with real breakage costs, not a fix.

Warning: Do not download or run "php2shell.py" proof-of-concept files circulating on GitHub. Per JFrog's reporting, fake PoC repositories from unknown accounts are distributing malware. You do not need an exploit to check your exposure — the version number is the check.

And on workarounds, be clear-eyed: disabling session.upload_progress.enabled blocks at most one confirmed path of one bug, blocking multipart POSTs breaks every upload form you have and does nothing for the OOM bug, and the PHP core team's position is that patching is the only real mitigation. Cloudflare customers got WAF rules (its CTO said early attack attempts were observed before the patch shipped); everyone else has the checklist above.

The AI angle: discovery and defence, compressed into the same week

The reporting credits the discovery to Calif, Wiz and OpenAI, and both ReliaQuest and watchTowr describe frontier AI models compressing the exploit-development side of the work — turning a memory-corruption chain that would normally take a specialist far longer into roughly one week of work. Hold that number at arm's length (it comes from the firms reporting the incident, not from a published methodology), but the direction is hard to argue with: a pair of bugs this subtle — an OOM that has to land mid-initialisation, a stale pointer that needs a second request on the same worker — was found, chained and weaponised fast enough to force an emergency release for a language that runs a large share of the web.

The same week produced the mirror image: OpenAI's checker is itself two AI skills, built to let any site owner ask "am I exposed?" in plain language. Offence got a tool; defence got a tool. What neither got is more time — the leak removed the one-day buffer the coordinated disclosure had planned, and the patch-to-mass-scanning window is now measured in minutes. The practical conclusion for anyone running infrastructure: your patch pipeline's speed is now a security control in its own right, because the other side's pipeline just got faster.

What we don't know yet

Honesty about the gaps, because they are real. The exploitation reports conflict: Cloudflare's CTO said early attack attempts were observed before the patch and that Cloudflare deployed WAF rules against them, while Huntress and watchTowr initially reported no observed exploitation. Both can be true (different vantage points, different definitions of "attempt"), and the picture will sharpen over the coming days. Version checkers are screening, not proof: they read a version number, which a backported distro package can make misleading in either direction. And the full technical root-cause write-ups were still landing as this article was published — if a detail here conflicts with the PHP advisories, the advisories win.

Key Takeaways

PHP2Shell is two unauthenticated RCEs in PHP itself (CVE-2026-109618 via OOM corruption, CVE-2026-109619 via stale state), CVSS 9.2, affecting PHP 5.4 through 8.5 across FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed.
Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — and restart the service. An updated binary with un-restarted workers is still vulnerable.
PHP 8.1 and older get no official fix. Upgrade branches or apply a vendor backport; do not wait.
Hunt before you restart if you see indicators — multipart upload-progress probes, memory-exhaustion fatals, worker crashes, new .php files — because the stale-state evidence dies with the worker process.
There is no reliable workaround, and the circulating "PoC" files are malware bait. The version number is your test.

Next step: run the Step 1 inventory on every host you own today, compare each version against the table, and schedule the restart in the same sitting — an inventory without a patch window is just a list of targets.

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Fix Anthropic 'Invalid signature in thinking block' 400 Error in n8n AI Agent (GH #41152)

CortexFlow — Wed, 21 Oct 2026 08:30:00 +0000

Your support-ticket agent runs fine all morning, then randomly throws Bad request - please check your parameters on the AI Agent node. No credentials expired, nothing changed in the workflow, and re-running the same prompt sometimes works. Underneath that generic message, Anthropic returned a very specific 400:

400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.3:
Invalid `signature` in `thinking` block. The block is bound to a different conversation."}}

I traced this to a real bug in n8n's AI Agent node (Tools Agent V3), reported as n8n GitHub issue #41152 on 2026-10-15 and verified against the n8n source on master by the reporter. It only fires when Claude returns one thinking block followed by two or more tool_use blocks in the same turn — i.e. parallel tool calls. Turns with a single tool call work fine, which is exactly why it looks intermittent: it depends on the model's choice, not your config. The issue's reporter hit it 5 times in ~24 hours on a production support-ticket agent.

By the end of this article you'll know exactly why it happens, how to confirm it's your bug in under a minute, and the four fixes that actually work — ordered from quickest to most surgical.

Quick definitions before we start: a thinking block is Anthropic's extended-thinking artifact — the model's private chain-of-thought, returned as a structured thinking content block. Every thinking block carries a signature, a cryptographic seal Anthropic places on it that binds the block to the exact conversation prefix it was created under. If you replay the block under different content (for example, with extra tool calls inserted before it), Anthropic rejects the request. The Tools Agent V3 (typeVersion 3.1) is the current n8n AI Agent implementation that rebuilds the chat history between agent turns.

Prerequisites: an n8n instance (verified on 2.42.7 as of October 2026; the mechanics apply to any 2.x running Tools Agent V3), an AI Agent node with an Anthropic Chat Model (Claude Sonnet 5 or Opus 5.x, with thinking enabled explicitly or — important — unset, which means adaptive thinking is on by default), and at least two tools attached to the agent.

The symptom: what the failure actually looks like

The failure has three tell-tale fingerprints:

The workflow: Manual Trigger → AI Agent (Tools Agent) → Anthropic Chat Model (e.g. claude-opus-5-5 or claude-sonnet-5), Thinking Mode either Adaptive or simply unset, with two independent tools attached (two HTTP Request Tools, or one MCP Client Tool exposing several tools).
The trigger prompt: anything that invites two lookups at once — the issue's example was "Look up the user with email X AND search for similar tickets about Y, then summarise." When the model answers with one thinking block plus two tool_use blocks, both tools execute, and the next Anthropic call fails with the 400 above.
The n8n surface: NodeOperationError: Bad request - please check your parameters on the AI Agent node, thrown from ToolsAgent/V3/helpers/executeBatch.ts. Your parameters are fine — this message is a red herring.

How to confirm in one minute: open the failed execution, click the Anthropic Chat Model node, and look at the second run (the one that failed). Inspect the input history. If you see the pattern AI: [thinking][tool_use] appearing twice with the same signature, then the history sent back to Anthropic looked like this:

Human: ...
AI:   [thinking(sig S), tool_use A]
Tool: result A
AI:   [thinking(sig S), tool_use B]      <- same signature S, replayed under a different prefix
Tool: result B

The issue's reporter confirmed exactly this: in every failing run, both actions in subNodeExecutionData.actions[].action.metadata.anthropic carried the identical thinkingSignature. If instead you only see one tool call per turn in your failing runs, this is not your bug — keep reading past the fixes anyway, because the prevention section covers related thinking-replay problems.

Note: this bug is new in the sense that it's the next failure after a previous fix. Merged PR #38302 ("Preserve Anthropic thinking blocks with empty text across tool calls") made empty-text thinking blocks survive the history round-trip. This report is what happens after that fix: the block survives, but it gets duplicated.

The root cause: n8n copies one signature into every parallel tool call

The reporter verified this in the n8n source on master (commit 40094e3, 2026-10-15). Here's the failure chain:

The model returns a single assistant turn shaped like [thinking, tool_use A, tool_use B]. The thinking block's signature is minted for that exact turn.
When the agent rebuilds history after the tools run, createEngineRequests.ts → extractThinkingMetadata() (line 43) copies the same thinkingContent and thinkingSignature into the metadata of every tool action of the batch. Both tool calls end up carrying an identical signature.
buildSteps.ts → buildSteps() (line 345) builds the conversation steps. For Gemini, there is a branch that detects parallel calls sharing a thought signature and merges them into one assistant message via buildSharedGeminiAIMessage() — the code comment above it describes exactly this problem ("Splitting into separate model turns invalidates the signature").
There is no equivalent branch for Anthropic. Each Anthropic tool call goes through buildIndividualAIMessage() → buildAnthropicContentBlocks(), which always returns [thinkingBlock, toolUseBlock] — one thinking block per tool call, each with the same signature.

So n8n replays the thinking block once per tool call, and the second copy sits after tool_use A and result A — content that did not exist when the signature was created. Anthropic's signature validation sees a block replayed under a different prefix and rejects the request. The Gemini path got the merge fix; the Anthropic path simply never did. As of the issue filing date there is no merged upstream fix — the workarounds below are the accepted solutions from the issue thread itself.

The fixes

Decision table first, then steps:

Fix	Effort	Thinking kept?	Best when
1. Thinking Mode: Disabled	1 click	No	You don't need chain-of-thought quality on this agent
2. Sequential tool calls	Prompt edit	Yes	One agent does independent lookups; you can tolerate sequential latency
3. Swap the chat model	2 clicks	Depends	You're not married to Anthropic for this workflow
4. Anthropic beta `drop_block`	Advanced	Partially	You call the API directly or can pass custom headers

Fix 1 - Set Thinking Mode to Disabled on the Anthropic Chat Model node

This is the fastest fix and the first workaround listed in the issue.

Open the Anthropic Chat Model sub-node on your AI Agent.
Find the Thinking Mode option and set it to Disabled.
Save and re-run the workflow with the same "two lookups at once" prompt.

Why this works: with thinking disabled there is no thinking block and therefore no signature to duplicate — the replay path can't break what doesn't exist. It also fixes the related default: since n8n 2.37.0 (via @langchain/anthropic 1.5.6), Claude Sonnet 5 and Opus 5 think adaptively even when Thinking Mode is unset, so "I never enabled thinking" does not protect you. Merged fix #37954 ("Send disabled thinking to the provider") makes the Disabled setting actually reach the API — make sure your n8n includes it (any n8n updated after that fix landed, including the 2.42.x line, is fine).

Warning: this is not available on models that cannot disable thinking. If your model enforces thinking, skip to Fix 2.

Verify: send the same prompt that triggered parallel tool calls. The agent should complete with no 400, and the execution input for the chat model node should show turns without any thinking blocks.

Fix 2 - Keep the model to one tool call per turn

Also from the issue: "Prompt it so that it only calls one tool per turn: works."

Rephrase the system prompt to force sequential tool use, e.g.:

You are a support assistant. When you need multiple pieces of information, request them strictly one at a time: call a tool, wait for its result, and only then decide whether to call another tool. Never call two tools in the same response.

Why this works: the duplication only happens when one turn contains two or more tool_use blocks. With one tool call per turn, the thinking signature is replayed exactly once under the correct prefix — the same reason single-tool turns already work today.

The trade-off is latency: two sequential tool calls take roughly twice as long as two parallel ones, and you're relying on the model to obey the instruction (in practice, explicit "one at a time" instructions are followed reliably on frontier models — but it's still a prompt, not a guarantee).

Fix 3 - Use a different chat model node for this agent

The issue lists this as a workaround, and there is an interesting technical reason to prefer one specific alternative: Gemini. n8n's history builder already has buildSharedGeminiAIMessage(), which merges parallel tool calls sharing a thought signature into a single assistant message — the exact handling the Anthropic path is missing. So Gemini agents don't hit this bug at all. OpenAI chat models work too, since they don't use signed thinking blocks in this flow.

When to use this: if the agent's job doesn't specifically need Claude's strengths, swapping the sub-node is a two-click change with zero prompt or quality trade-offs on the thinking side.

Fix 4 - (Advanced) Tell Anthropic to drop mismatched blocks

The error message itself names this escape hatch: set thinking.block_binding.prefix_mismatch_behavior to "drop_block", which requires the thinking-binding-controls-2026-08-01 value in the anthropic-beta header. When Anthropic sees the duplicated signature replayed under a wrong prefix, it drops the block instead of rejecting the request.

This is an API-level control — useful if you're calling the Anthropic API directly from an HTTP Request node or a Code node, not something you click into the Anthropic Chat Model node's options. If you do use it, verify: the request succeeds, but check the model's behavior — a dropped thinking block means the turn proceeds without the chain-of-thought it was built on, which can subtly change reasoning quality on that turn.

What NOT to do

Don't chase "please check your parameters." The NodeOperationError: Bad request - please check your parameters message points at your node config; the actual problem is the history n8n reconstructs. Editing credentials, remapping fields, or re-creating the agent node won't help.
Don't disable execution-data saving or tune execution settings. Nothing about this failure involves the execution store — it's the conversation history payload sent to the Anthropic API.
Don't assume it won't recur because your last three runs worked. The failure is model-choice-dependent: it only fires when Claude happens to emit parallel tool calls. A prompt that worked yesterday fails tomorrow on a different day with a different phrasing.

Prevent it next time

Treat parallel-tool-call agents on Claude as a known risk class. Any AI Agent with an Anthropic Chat Model and 2+ independent tools can hit this until the upstream fix lands. Pick Fix 1, 2, or 3 as your default posture for new agents now, not after the first production failure.
Watch GH #41152 for the official fix. The expected behavior per the issue: parallel Anthropic tool calls from one thinking turn should be replayed as a single assistant message [thinking, tool_use A, tool_use B], mirroring what buildSharedGeminiAIMessage() already does for Gemini. When an n8n release closes this issue, upgrade and re-enable thinking.
Know the neighboring bugs. The same replay path in buildSteps.ts is implicated in two related open reports: #40360 (thinking replay sends earlier tool calls back as input: {}) and the older #37730 regression where Thinking Mode: Disabled stopped disabling thinking. If you see a different Anthropic 400 on this node, check those before assuming it's #41152.

Key Takeaways

The 400 fires only on parallel tool calls. One thinking block + two tool_use blocks in a single turn is the trigger; single-tool turns never fail — that's why it looks intermittent.
n8n duplicates the thinking signature across every parallel tool call, but only Gemini's replay path merges them. The Anthropic path in buildSteps.ts has no equivalent, so the second copy is replayed under a different conversation prefix and Anthropic rejects it.
Fastest fix: Thinking Mode: Disabled on the Anthropic Chat Model node (effective since fix #37954); also prompt for one tool call per turn, or swap to Gemini/OpenAI.
"Bad request - please check your parameters" is a red herring — confirm the real cause by checking the failed execution's chat-model input for [thinking][tool_use] repeated with the same signature.
This is a known upstream bug (GH #41152) with no merged fix yet — treat Claude agents with multiple independent tools as a risk class and design around it until the release notes say otherwise.

Next: open your highest-traffic AI Agent that uses an Anthropic model with 2+ tools, reproduce the "two lookups at once" prompt in a manual execution, and check the chat-model input. If you see the duplicated signature, apply Fix 1 or 2 today — the five-failures-in-24-hours pattern from the issue is exactly how this starts in production.

FAQ

Why does the same workflow fail sometimes and succeed other times?

The failure depends on the model's choice in each run, not your workflow. Claude emits a thinking block followed by one tool_use on some turns and two or more on others. Only the parallel-tool-call turns trigger the duplicate-signature rejection. Same prompt, different day, different tool-call pattern — that's the intermittence.

If I never enabled thinking, how am I affected?

Since n8n 2.37.0 (via @langchain/anthropic 1.5.6), Claude Sonnet 5 and Opus 5 think adaptively by default when Thinking Mode is unset — no explicit opt-in required. Check your Anthropic Chat Model node: if Thinking Mode is unset on one of these models, thinking is on.

Will disabling thinking hurt my agent's quality?

It depends on the task. For lookup-and-summarise agents (fetch two records, summarise), disabling thinking typically costs little — the model still has full tool outputs to work with. For multi-step reasoning agents, expect some degradation. That's what Fix 2 (sequential tool calls, thinking kept) is for.

Is Gemini affected by the same bug?

No — n8n's buildSteps.ts already merges parallel calls sharing a thought signature into one assistant message for Gemini (buildSharedGeminiAIMessage()). The issue explicitly notes the comment above that code describes exactly this signature problem. The Anthropic branch just never got the same handling.

Where is this tracked upstream?

n8n-io/n8n issue #41152, filed 2026-10-15, verified against master source at commit 40094e3, reproduced on 2.42.7. Related: open #40360 on the same replay path, merged #38302 which made thinking blocks survive the round-trip in the first place.

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Google Workspace Will Block AI Agents Without This OAuth Flag on Nov 11: The n8n Builder's Checklist

CortexFlow — Mon, 19 Oct 2026 08:29:59 +0000

Google is about to draw a hard line between humans and agents inside Workspace. If your n8n AI agent touches Gmail, Drive, or Calendar through a Google OAuth client, you have until November 11, 2026 to flip one checkbox in the Google Cloud console. Miss it, and on November 12 the setting locks permanently on your existing client — leaving you to rebuild the whole OAuth credential from scratch.

This is not a rumor. Google is introducing a new "agentic" classification flag for OAuth clients — a checkbox labeled "Use this client for an AI-powered agent" inside Google Auth Platform > Clients. Starting November 11, 2026, Google's Workspace MCP servers will actively reject any OAuth client that isn't marked as agentic, returning an error that says the client is not marked as an AI agent. The timing matters: Google is rolling out Workspace MCP servers that expose Gmail, Drive, Calendar, and other productivity tools as live Model Context Protocol servers, and only agentic-tagged credentials will be allowed to connect to them.

By the end of this post, you will know exactly which of your OAuth clients need the flag, the two dates that matter, and a four-step checklist to get compliant before the lock-in.

Why Google is doing this

An OAuth client is the credential bundle (client ID + secret) that identifies your app to Google's sign-in system. Until now, a credential used by a cron-jobbed n8n workflow looked identical to one used by a human clicking through a web app. That made it impossible for Workspace admins to write security policies that apply only to agent traffic — rate limits, data-loss controls, access reviews — without also hitting human users.

The agentic flag splits the traffic at the identity layer. Marking a client as agentic doesn't grant extra scopes or bypass user consent; it labels the traffic so admins can apply dedicated agent controls to it. The rollout comes with a new best practice from Google: if your solution has both human-interactive features (standard Google REST APIs) and AI agent workflows, maintain separate OAuth Client IDs for each.

The dates that matter

Date	What happens
Oct 12, 2026	The "Use this client for an AI-powered agent" checkbox became available in the Google Cloud console (Google Auth Platform > Clients) for new and existing clients.
Nov 11, 2026	Workspace MCP servers start rejecting requests from OAuth clients that lack the agentic tag.
Nov 12, 2026	The `is_agentic` setting becomes permanent on existing clients. If you didn't flip it in time, you cannot toggle it on that client — you must create a brand-new OAuth Client ID and update every configuration that references the old one.

That last date is the trap. This isn't a setting you can enable lazily the first time something breaks on November 12. After the cutoff, a missed flag means a new client ID, new consent screens, and re-wiring every n8n credential and MCP config that used the old one.

The 4-step n8n builder's checklist

Step 1 — Inventory your Google OAuth clients. Open Google Cloud console and list every OAuth Client ID under Auth Platform > Clients. Flag each one: is this credential used by an AI agent (an n8n AI Agent node, a workflow that acts on your behalf, an MCP client config) or by human-driven workflows? Builders commonly run both through a single client — that is exactly the pattern Google now wants split.

Step 2 — Enable the agentic flag on agent clients. For each client that powers agent traffic, open it and tick "Use this client for an AI-powered agent". This is available today; do it now rather than in the November scramble. You should see the checkbox persist on the client detail page after saving.

Step 3 — Split human and agent traffic into separate clients. Google's updated guidance is explicit: one OAuth Client ID for human-interactive features, one for agent workflows. In n8n this means creating a second Google OAuth2 credential and assigning it only to the nodes/agents that act autonomously. If you're unsure which workflows qualify, treat anything that reads or writes Workspace data without a human clicking "run" each time as agent traffic.

Step 4 — Watch your MCP configs. If you connect n8n to Workspace MCP servers (see our guide to connecting an MCP server to n8n), the OAuth credentials behind those connections are the ones the November 11 enforcement targets. Re-auth flows and client JSON files (like mcp_config.json entries in coding-agent setups) must reference an agentic-tagged client.

What this does and doesn't affect

To be precise about scope: the enforcement applies to Google Workspace MCP servers — the new protocol surface, not the decades-old REST APIs behind n8n's standard Google nodes. If your workflows only use n8n's built-in Google Drive/Gmail nodes with plain REST calls, this deadline doesn't touch them. But the industry is moving: Google, Microsoft, and everyone else are converging on MCP as the agent protocol, and this is Google declaring that MCP access will be gated at the identity layer. If you plan to give agents live Workspace access via MCP — which is where agent builders are headed — this flag is your ticket.

Two honest caveats. First, the granular rollout details come from secondary coverage (ASTIG's Oct 2026 report and Apps Script Pulse's Oct 14 analysis, which references Google's updated Manage OAuth Clients documentation). I have not read Google's own announcement page directly, so verify the checkbox wording in your own console before you act. Second, if you authenticate Google entirely through n8n's hosted OAuth service rather than your own Cloud project client, this may not apply to you at all — the flag lives on your OAuth client IDs.

Key Takeaways

Google Workspace MCP servers reject non-agentic OAuth clients starting November 11, 2026.
The is_agentic flag locks permanently on November 12 — miss it and you're creating a new client ID from scratch.
Keep separate OAuth Client IDs for human vs. agent traffic; the flag grants no extra permissions, it just labels traffic for admin controls.
Audit your n8n Google OAuth2 credentials and MCP configs now, not in November.

Next step: Open your Google Cloud console's Auth Platform > Clients page today, find the client behind your most important n8n agent workflow, and tick "Use this client for an AI-powered agent". While you're there, read our MCP + n8n troubleshooting guide for the OAuth re-auth patterns that pair with this change.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Archon's Agent Control API Has No Login and Listens on Every Interface: The CVE-2026-111322 Lockdown Guide

CortexFlow — Sun, 18 Oct 2026 08:29:55 +0000

On October 15, 2026, VulnCheck published CVE-2026-111322 against Archon, the open-source workflow engine behind Claude Code, Codex, and Pi. The finding is brutally simple: in a default install, Archon's /api/* control API has no authentication, and the server binds to 0.0.0.0 — every network interface.

That matters because this API is not a status page. It starts workflow runs, injects messages into agent conversations, and approves or rejects the actions your AI coding agent paused on for human review. Anyone on your network can do all of that with no credential. By the end of this guide you will have a locked-down Archon install — in about 10 minutes, with zero code changes.

What Archon Is, in One Line

Archon (23,700+ stars on GitHub) is an open-source engine that drives AI coding agents through YAML-defined development workflows. You run archon serve, and a web console lets you watch the agent work, talk to it, and approve the actions it pauses on. That console talks to the HTTP control API at the center of this CVE.

The Finding, Precisely

Security researcher hieuPenguinnn pinned the root cause to three facts in the Archon OS server package (reviewed at release tag v0.11.1, published 2026-09-25):

The server binds to all interfaces by default. packages/server/src/index.ts sets the bind host to process.env.HOST || '0.0.0.0', and the shipped .env.example confirms the default port is 3090. A default install is network-reachable on port 3090.
The API gate is disabled by default. The /api/* middleware only enforces authentication when isApiGateEnabled() is true — which requires both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET. A default install uses SQLite and sets neither, so every request passes through with no identity check.
The mutating routes are the agent control plane. Behind that disabled gate: start workflow runs (POST /api/workflows/{name}/run), inject conversation messages, approve/reject paused agent actions, and connect/disconnect provider keys.

The one-line version: anyone who can reach port 3090 on your machine can drive your AI coding agent. The CVE carries CWE-306 (missing authentication for critical function) plus CWE-862, CVSS 9.8 (v3.1) / 9.3 (v4.0). Affected: versions 0.2.13 through 0.11.1. As of October 16, 2026, the latest release is still v0.11.1 — there is no vendor patch and no published advisory.

One honest caveat from the researcher's own writeup: he did not establish direct remote code execution on the host from source review alone — the provider-key list route returns metadata only, and the damage a driven run can do depends on the workflows and agent configured. VulnCheck scores it 9.8 because the agent plane is reachable and these agents run commands. Treat it as critical either way.

The agent runs on your machine with your permissions. Its control plane should not be network-open.

Prerequisites

SSH or terminal access to the machine running archon serve
Your Archon .env file (or however you set its environment variables)
About 10 minutes

Example terminology: <your-host> is the machine running Archon. Port 3090 is the default from the shipped .env.example — replace it if you changed it.

Step 1 - Check Whether You Are Affected

Check your Archon version first. If it falls between 0.2.13 and 0.11.1 inclusive, you are running affected code:

# inside your Archon checkout or container
git describe --tags 2>/dev/null || grep -m1 '"version"' package.json

Then check your config. You are exposed when all three are true: no HOST set to 127.0.0.1, no Postgres DATABASE_URL, and no BETTER_AUTH_SECRET:

grep -E '^(HOST|PORT|DATABASE_URL|BETTER_AUTH_SECRET)' .env

Missing lines mean defaults apply: HOST=0.0.0.0, SQLite, no auth. That is the vulnerable posture — and it is the shipped default. (Note: this is a different defect from CVE-2025-69443, which concerned Archon's archived Python backend.)

Step 2 - Check What the API Is Actually Bound To

Do not trust the config file alone — check the listening socket:

ss -tlnp | grep 3090

You should see one line. If it reads 0.0.0.0:3090, the control API is reachable from your entire network. If it reads 127.0.0.1:3090, the network reach is already gone and you can skip to Step 5.

Warning: localhost in a URL does not mean the server is loopback-only. Plenty of setups proxy through a tunnel while the underlying server still sits on 0.0.0.0. The ss output is the ground truth.

Step 3 - Bind the Server to Loopback

This is the single highest-leverage fix. The shipped .env.example documents it explicitly:

# HOST=0.0.0.0 # Bind address (default: 0.0.0.0). Set to 127.0.0.1 to restrict to localhost only.
# PORT=3090 # Default: 3090.

Set it in your .env (create the file if you do not have one):

HOST=127.0.0.1

Restart the server, then re-run Step 2. You should now see 127.0.0.1:3090 — other hosts on your network can no longer reach the API at all, even though the auth gate is still disabled. The researcher confirms this removes the network reach entirely.

Step 4 - Block the Port at the Firewall

Bind config is one layer; the firewall is the second. Deny inbound traffic to 3090 from anywhere except the local machine:

# Ubuntu/Debian with ufw
sudo ufw deny 3090

ufw deny 3090 blocks inbound connections to that port from all interfaces. Loopback traffic from your own machine still reaches 127.0.0.1:3090, so the web console keeps working locally. If you run Archon in Docker with published ports, remove the -p 3090:3090 mapping and use --network host or container-to-container networking instead — a published port re-opens the door the bind config just closed.

Step 5 - If You Need Network Access, Enable Web Auth

Only do this step if you genuinely need to reach Archon from other machines. The supported way to arm the auth gate is to set both a Postgres database URL and a secret:

DATABASE_URL=postgresql://<user>:<password>@<host>:5432/archon
BETTER_AUTH_SECRET=<generate-a-long-random-string>

Generate the secret with openssl rand -hex 32 — never reuse one from another service. With both set, isApiGateEnabled() returns true and the middleware enforces a 401 on non-allowlisted /api/* routes. If that migration is too heavy right now, keep Step 3 and 4 and put a reverse proxy with basic auth in front of Archon instead. Never expose port 3090 directly to the internet or an untrusted network.

Step 6 - Verify Everything Works

Three checks, in order:

# 1. Loopback still answers
curl -s http://127.0.0.1:3090/api/health

# 2. Nothing listens on the external interface
ss -tlnp | grep 3090   # expect 127.0.0.1:3090 only

# 3. The web console loads locally
# open http://127.0.0.1:3090 in your browser

If check 1 succeeds and check 2 shows only the loopback line, the lockdown holds: the agent control plane is reachable from your machine and nowhere else.

The fix is three lines of config and one firewall rule — not a patch, because none exists yet.

FAQ

Am I safe if I only use Archon on my laptop?

Probably — if nothing else on your network can reach it. "Probably" is not a control, though: run Step 2 and confirm 127.0.0.1:3090. Coffee-shop Wi-Fi and office LANs are exactly the networks where an open 0.0.0.0 bind hurts.

Is this the same as the old Archon Python CVE?

No. CVE-2025-69443 concerned the archived Python backend. CVE-2026-111322 is in the TypeScript Archon OS server line — a separate defect in a separate codebase.

Has Archon patched it?

Not yet. As of October 16, 2026 there is no public advisory for this defect and the latest release (v0.11.1, from September 25) is still affected. Watch the coleam00/Archon releases page for a version that changes the default bind host or adds auth — keep the lockdown until then.

Does this affect n8n too?

No — this is Archon-specific. But the pattern is worth auditing everywhere: any agent tool you run (archon serve, local LLM servers, MCP servers) that binds 0.0.0.0 by default is the same class of mistake. Grep your running services with ss -tlnp and question every 0.0.0.0.

Limits and What I Did Not Test

I did not spin up Archon and execute requests against a live instance here — the findings above come from VulnCheck's advisory (October 15, 2026) and the researcher's pinned source review at v0.11.1, both of which agree on the three root-cause facts. The mitigation steps are config-level and low-risk, but back up your .env before editing. And this lockdown fixes the network reach — it does nothing about prompt injection, malicious plugins, or supply-chain attacks on the agent itself, which are separate problems with their own fixes.

Key Takeaways

CVE-2026-111322 is a missing-authentication flaw (CVSS 9.8) in Archon 0.2.13–0.11.1: the /api/* control API has no login and binds to 0.0.0.0:3090 by default.
The shipped default is the vulnerable posture — the auth gate only arms with both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET, which a default SQLite install never sets.
Set HOST=127.0.0.1 and firewall port 3090 — two changes that remove the network reach entirely, verified with ss -tlnp.
No vendor patch exists as of October 16, 2026 — keep the lockdown until a release notes an auth fix.
Audit your other agent tools for the same pattern — any local server binding 0.0.0.0 by default is this bug waiting for a CVE number.

Next step: if you run AI coding agents, read our Plugin4Shell breakdown — a separate zero-click flaw where a pinned plugin commit turned out to be a lie. And if you self-host n8n, our exposed-instances hardening checklist covers the same bind-and-expose pattern for automation infrastructure.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Ni8mare: The CVSS 10.0 n8n Flaw That Turns a Webhook Into a Full Server Takeover

CortexFlow — Sat, 17 Oct 2026 08:29:59 +0000

A vulnerability with the worst possible severity score is sitting in older n8n installs, and it needs no login to exploit. Ni8mare (CVE-2026-21858) lets a remote, unauthenticated attacker send one specially crafted request to an n8n webhook and walk away with any file on the server — API keys, database contents, credentials, everything. Cyera's public write-up of the flaw has been circulating again this week, and the exposure numbers are ugly: the Shadowserver Foundation found nearly 60,000 internet-connected n8n instances still running vulnerable versions.

By the end of this article you'll know exactly how Ni8mare works (in plain language), whether your instance is exposed, and how to patch it in about 15 minutes — plus what to check in case someone got there first.

What Ni8mare actually is

A webhook is an HTTP endpoint n8n exposes so outside services can trigger your workflows — a form submission, a file upload, a payment event. A CVE is the industry-wide catalog ID for a specific bug; CVSS 10.0 is the maximum severity rating, meaning the bug is remotely exploitable, needs no authentication, and can fully compromise the host.

Ni8mare lives in how n8n parses incoming webhook data. n8n picks its parser based on the Content-Type header of the request:

multipart/form-data → a special file-upload parser (the Formidable library), which stores uploaded files in temporary locations and populates req.body.files. The temp-file indirection exists specifically to block path-traversal tricks.
Anything else (e.g. application/json) → the regular body parser, which populates req.body.

The bug: n8n's file-handling code reads from req.body.files without verifying the request actually went through the upload parser. So an attacker sends a request to a form/file-upload webhook with Content-Type: application/json and a hand-built files object — and n8n treats it as a legitimate parsed upload, including the attacker-supplied filepath field.

How one webhook request becomes full server control

Attacker finds a webhook that expects file uploads. Any workflow with a Form node or file-upload webhook on an internet-reachable n8n instance qualifies. The webhook URL doesn't need to be secret — n8n webhook paths are often guessable or leaked in client-side code.
They send a request with the wrong Content-Type. Instead of multipart/form-data, the request declares application/json and includes a fake files payload — with the filepath field pointed at any file on the server, like /proc/self/environ, .env, or the SQLite database.
n8n copies the "uploaded" file. Since the upload parser never ran, the attacker-controlled filepath is used verbatim. Per Cyera's write-up, "instead of copying an uploaded file, we can copy any local file from the system" — and any node downstream of the form receives the local file's content.
File read becomes full compromise. Reading database.sqlite or environment files yields the N8N_ENCRYPTION_KEY and every stored credential. Cyera notes the same primitive allows forging session cookies (authentication bypass), injecting files into workflows, and ultimately arbitrary code execution — full server takeover.

No account. No workflow access. One HTTP request to a public webhook.

Why the blast radius is massive

n8n isn't a blog engine — it's the automation control plane. The workflows on a compromised instance typically hold OAuth tokens for Google Workspace and Salesforce, OpenAI API keys, database connection strings, and payment processor credentials. One server takeover hands an attacker every integration the business wired up.

The numbers, all as reported this month:

100M+ Docker pulls of n8n; Cyera estimates ~100,000 servers potentially exposed.
Nearly 60,000 internet-connected instances still vulnerable, per the Shadowserver Foundation's scan data (reported by TechRadar in September 2026).
76% of exposed n8n instances run versions with known critical CVEs, per Censys's October 2026 State of the Internet report — we covered that count in our exposed-n8n hardening checklist.

Ni8mare was reported to n8n's security team on November 9 and patched nine days later in n8n 1.121.0. So the fix has existed for almost a year — the exposed instances are simply instances nobody updated. There are no official workarounds; patching is the only remediation.

Are you exposed?

Your setup	Status
n8n Cloud	Safe — n8n patched Cloud instances automatically
Self-hosted n8n 1.121.0 or later (any 1.x above it, or the 2.x line)	Safe
Self-hosted n8n below 1.121.0	Vulnerable — patch now
Self-hosted below 1.121.0 and internet-exposed	Vulnerable and reachable — treat as urgent, assume probing

Note: the 2.x release line postdates this fix, so if you already run 2.x you're on the patched code path. But versions and advisories rot fast — if you're unsure, the check in Step 1 takes ten seconds.

Prerequisites: SSH or console access to the machine running n8n, your N8N_ENCRYPTION_KEY value saved somewhere safe, and about 15 minutes.

Step 1 - Check your n8n version

In the n8n editor, open Settings → About — it shows the exact build. Or from the host:

docker exec <n8n-container-name> n8n --version

Replace <n8n-container-name> with your container's name (often n8n). You should see something like 1.121.0, 1.123.83, or 2.x.x. Anything below 1.121.0 is in the vulnerable range — and honestly, if you're still on the 1.12x line at all, you should move to the current stable anyway (the October 2026 advisory batch alone patched 14 more advisories, covered in our October security update post).

Step 2 - Back up before you touch anything

Upgrading is low-risk, but a backup makes it zero-risk. Export your workflows from the editor (⋮ menu → Export), and copy your database — the default SQLite file, or a pg_dump if you run Postgres.

The critical one: confirm your N8N_ENCRYPTION_KEY value is saved somewhere off the server. Without the exact same key, a restored instance cannot decrypt any stored credential, and every credential becomes unusable. I treat this as step zero of every upgrade.

Warning: if your instance was internet-exposed on a vulnerable version, back up first, but also plan to rotate secrets after patching (Step 4) — a backup preserves your data, it doesn't undo a compromise that already happened.

Step 3 - Upgrade to the patched version

For the common Docker Compose install:

# 1. Pull the patched image
docker compose pull n8n

# 2. Recreate the container with the new image
docker compose up -d

# 3. Watch the logs for a clean startup
docker compose logs -f n8n

Why these commands: pull fetches the fixed image, up -d recreates the container on it, and the logs confirm the database migrations ran without errors. You should see n8n ready on 0.0.0.0, port 5678 with no migration failures.

Pin to a fixed version tag rather than latest in your docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:1.123.83

Anything at or above 1.121.0 closes Ni8mare; pinning the current stable (1.123.83 on the 1.x line, or the 2.x line) also picks up every advisory since. If you installed via npm:

# Stop the running process first (systemd/pm2/however you run it)
npm install -g n8n@1.123.83
# then start it again

Verify in Settings → About that the running version is at or above 1.121.0.

Step 4 - Check whether someone got there first

If your instance was both vulnerable and internet-reachable, patching closes the hole but doesn't erase a break-in. Work through these:

Scan your own exposure. Check whether your instance's IP appears in Shadowserver or Censys scan data for vulnerable n8n versions. If it was fingerprinted, assume it was probed.
Review webhook access logs. Look for requests to your webhook endpoints with unusual Content-Type headers (application/json hitting form/file-upload paths) or requests that don't match any legitimate integration. One anomalous hit to a file-upload webhook is the signature.
Rotate your secrets. If there is any chance of compromise, rotate the N8N_ENCRYPTION_KEY, every API key and OAuth credential stored in n8n, and any database passwords the instance could reach. A file-read bug means the attacker may hold a copy of everything — changing the locks after patching is the only way to be sure.
Audit user sessions. Check for unfamiliar owner/admin accounts or unexpected workflow changes — the file-read primitive can escalate to session forgery.

If you want this as a repeatable routine, our free n8n security advisory triage template walks through the same pattern — inventory your version, check it against the advisory list, and run the post-patch verification — as an actual workflow you can import.

What this article doesn't cover (honest limits)

I did not test the exploit against a live instance — reproducing a CVSS 10.0 unauthenticated RCE would be reckless, and Cyera's write-up contains the technical detail if you need it for a compliance report. I also can't confirm whether Ni8mare was exploited in the wild before or after the patch; neither n8n nor Cyera has published exploitation data. The exposure counts come from third-party internet scans (Shadowserver via TechRadar, Censys), which measure vulnerable instances, not compromised ones. Patch first, investigate logs second.

FAQ

Am I affected if I only use n8n Cloud?

No. n8n Cloud instances were patched automatically. This is a self-hosted problem.

I run 2.x — do I need to do anything?

The Ni8mare fix predates the 2.x line, so 2.x installs already contain it. But use this as the prompt to check you're on a current 2.x — the October 2026 advisory batch patched 14 more advisories on top.

Is there a workaround if I can't upgrade right now?

No official workaround exists for Ni8mare. The closest mitigation is removing internet exposure: put n8n behind a VPN or firewall so webhook endpoints aren't publicly reachable. That shrinks who can knock, but patching is the actual fix.

Where are the full advisory details?

On the n8n GitHub Security Advisories page and Cyera's research write-up (linked from the Infosecurity Magazine coverage). The original report to n8n's security team was November 9; the fix shipped nine days later in 1.121.0.

Key Takeaways

Ni8mare (CVE-2026-21858) is a CVSS 10.0 unauthenticated RCE in n8n — one crafted webhook request can read any file on the server, forging sessions and escalating to full takeover.
The fix is n8n 1.121.0 or later — nearly 60,000 internet-connected instances are still unpatched, which is why this still matters a year later.
There is no workaround — patch, or at minimum pull the instance off the public internet.
If you were exposed, rotate everything — a file-read bug means stored secrets may already be copied; changing keys after patching is the real remediation.

Next: run the 4-step check above, then grab the n8n security advisory triage template to make version checks a repeatable routine instead of a panic.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Your LLM Gateway Holds Every API Key. LiteLLM Let Any User Steal Them: CVE-2026-35029 Patch Guide

CortexFlow — Fri, 16 Oct 2026 08:29:55 +0000

LiteLLM is the open-source LLM gateway that roughly 100,000 developers download every month to route their apps through OpenAI, Anthropic, Google, and every other model provider. Check Point's AI agent security team found two vulnerabilities in it that collapse its entire security model: a missing authorization check that lets any user become an admin and run code (CVE-2026-35029), and a server-side request forgery flaw that exposes every provider API key stored in the gateway (CVE-2026-59823). Both are fixed in LiteLLM 1.83.9. If you run LiteLLM — especially in front of your n8n AI agents — this post gives you the four-step check, patch, rotate, and audit procedure.

What the two CVEs actually do

An LLM gateway sits between your application and the model providers. Instead of each workflow calling OpenAI's API directly, everything routes through the gateway, which forwards requests to the right backend. LiteLLM is exactly that: a proxy that centralizes credentials, logging, and usage tracking. That centralization is the point — and it's exactly what makes these flaws dangerous.

CVE-2026-35029 is a missing authorization check. Authorization is the part of security that answers "is this user allowed to do this?" LiteLLM's runtime configuration endpoint was missing that check, so any authenticated user — even one with the lowest privilege role — could modify the gateway's runtime configuration. Per Check Point's findings, that turns into full system takeover: file access, credential theft, and remote code execution via malicious Python modules loaded from cloud storage. Mateo Rojas-Carulla, Check Point's head of research for AI agent security, put it bluntly: anyone holding an account on a vulnerable deployment could take over the gateway.

CVE-2026-59823 is a server-side request forgery (SSRF) flaw. SSRF is when an attacker tricks your server into making a network request of their choosing. Here, it lets an attacker redirect the gateway's outbound requests — which means the requests that carry your OpenAI, Anthropic, and Google API keys — toward an attacker-controlled destination. The keys that were supposed to be the most centralized, protected secret in your AI stack get handed over.

Check Point disclosed both through the coordinated disclosure process, and LiteLLM shipped the fixes in version 1.83.9 — anything older than 1.83.9 is affected.

Why agent builders should care

If you self-host n8n, there's a good chance LiteLLM sits in your stack: it's the natural way to give all your AI Agent nodes one OpenAI-compatible endpoint, with fallbacks, load balancing, and a single bill. The danger here is the blast radius math. A compromised LLM gateway isn't one leaked key — it's every key: OpenAI, Anthropic, Gemini, and whatever else you've configured. And unlike a leaked key that an attacker quietly uses, a gateway takeover is a standing foothold: the attacker can execute code on the host, read files, and pivot further.

Christopher Jess, senior R&D manager at Black Duck, noted the pattern is painfully familiar: a missing permission check let low-privileged users reach administrative functions, with code execution as the consequence. As AI adoption accelerates, he warned, security fundamentals are being treated as secondary — and a gateway that centralizes all your AI access is a particularly valuable target.

The one-line takeaway: the box holding all your model API keys let any of its users pick the lock and walk out with the whole ring.

Prerequisites

Shell access to wherever LiteLLM runs (Docker host, VPS, or the machine with pip install litellm)
Your LiteLLM version number (Step 1 shows you how)
Admin access to your LiteLLM UI and your AI provider dashboards (to rotate keys)
Permission to restart the gateway container or process

Step 1 - Check your LiteLLM version

The vulnerabilities affect every LiteLLM version older than 1.83.9. Find your running version first.

If you run LiteLLM in Docker, exec into the container:

docker exec <your-litellm-container> pip show litellm 2>/dev/null | grep -E "Name|Version"

Or check from the host if you installed with pip:

pip show litellm | grep -E "Name|Version"

You should see a Version: line like Version: 1.83.9. Anything below 1.83.9 is vulnerable — proceed to Step 2 immediately. If you're on 1.83.9 or later, the fixes are in; skip to Step 4 and still do the audit, because the flaws were live in your version history if you ever ran an older build.

Step 2 - Upgrade to LiteLLM 1.83.9 or later

Pull and restart with the fixed release. For Docker Compose installs:

cd /path/to/your/litellm-compose
docker compose pull
docker compose up -d
docker exec <your-litellm-container> pip show litellm | grep Version

The pip show output must read 1.83.9 or higher. For pip installs, upgrade in place:

pip install --upgrade "litellm>=1.83.9"

Restart the LiteLLM process afterward — the fix is in the application code, so a running old process stays vulnerable until restarted.

Warning: upgrading doesn't erase what already happened. If your gateway was reachable by accounts you don't fully trust, treat key rotation in Step 3 as mandatory, not optional.

Step 3 - Rotate every provider API key stored in the gateway

CVE-2026-59823 exposes the API keys LiteLLM stores. Rotating means generating a brand-new key at the provider and replacing the old one everywhere the gateway reads it, so any stolen copy stops working.

In each provider dashboard (OpenAI, Anthropic, Google AI, and any others configured), generate a new API key.
Update the environment variables or config file LiteLLM reads — typically OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, and friends in your .env or Docker Compose file.
Revoke the old keys at the provider so they can't be used if they were exfiltrated.
Restart the gateway so it picks up the new values.

Verify the old keys are dead by checking your provider dashboards: the revoked keys should show as inactive or deleted, and your LiteLLM health endpoint should still respond normally with the new keys in place.

Step 4 - Audit accounts and verify permissions are actually enforced

Check Point's explicit recommendation applies here: since any account could have exploited these flaws, review who has gateway access and remove accounts that no longer need it. In the LiteLLM UI, list users and their roles, and prune anything stale — former teammates, test accounts, shared credentials.

Then do the permission check that would have caught this bug: log in as a low-privilege user and try to reach an admin-only endpoint (the runtime config modification path is the one to test). If a low-privilege account can change anything admin-scoped, your role enforcement still has a gap — the fix closed these two CVEs, but the discipline of verifying permissions in practice is what keeps the next missing check from hurting you.

Finally, add the gateway to your security routine: include LiteLLM in your regular vulnerability scans and penetration tests alongside your web apps and cloud infra. Gateways are high-value targets precisely because they centralize secrets.

Hard cases and limits

This guide covers the reported, patched CVEs only. It does not audit your LiteLLM deployment for other misconfigurations — open admin UI to the internet, default credentials, overly broad key scopes. If your gateway was internet-facing, assume broader exposure and review access logs for unusual config changes around the disclosure window (Check Point's detailed post went out October 13, 2026). There is no published workaround that avoids the upgrade; patching is the only fix.

I also haven't verified LiteLLM's exact endpoint paths for the vulnerable calls — use the official advisory and your version's behavior as the source of truth, not this post, for the specific API routes in your environment.

FAQ

Am I affected if I only use LiteLLM's Python SDK, not the proxy server?

The disclosed flaws target the LiteLLM proxy/gateway server, which serves multiple users and stores provider keys. A local SDK-only setup that never exposes a server to other users is not the attack scenario described — but if you run the proxy at all, check your version.

Do these flaws affect n8n's built-in AI nodes directly?

No. They affect LiteLLM itself. But if your n8n workflows point at a self-hosted LiteLLM endpoint, every model call your agents make flows through the vulnerable component — which is why this is an n8n-builder problem too.

Was there active exploitation before the patch?

Neither Check Point's report nor the coverage I've seen confirms in-the-wild exploitation. That said, the details were published October 13, 2026, and exploitability is trivial for any account holder — the safe assumption is that exposed instances are being probed now.

Key Takeaways

LiteLLM before 1.83.9 is vulnerable to two serious flaws: CVE-2026-35029 (missing authz → any user to admin + RCE) and CVE-2026-59823 (SSRF → every provider API key exposed).
Upgrade to 1.83.9 or later immediately, then restart the gateway — the running process stays vulnerable until it restarts.
Rotate every provider API key the gateway stored; revoking the old ones at the provider is what actually kills a stolen key.
Prune gateway accounts and test permissions as a low-privilege user — the gap between configured and enforced permissions is where this class of bug lives.
Treat AI gateways as high-value targets in your security routine: they hold the keys to everything your agents do.

Next: if your LiteLLM is internet-facing, review its access logs for config changes made by unexpected accounts around mid-October. And while you're in the gateway's settings, check that the admin UI isn't reachable from the public internet at all — that's a separate exposure these CVEs didn't need, but it's the next one attackers will try.

Sources: Infosecurity Magazine (reporting Check Point's disclosure, Oct 15, 2026).

Images: Pexels (free license).

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Censys Counted 114,000 Exposed n8n Instances: Your Self-Hosted Hardening Checklist

CortexFlow — Thu, 15 Oct 2026 08:29:56 +0000

Censys published its fifth annual State of the Internet Report yesterday (October 14, 2026), and the headline number for our corner of the internet is uncomfortable: n8n is the single most widely exposed AI product on the public internet — 113,926 hosts and counting.

Exposed AI infrastructure grew 63% in nine months (from October 2025 to July 2026), reaching nearly 268,000 systems, according to the Censys Advanced Research Collective's analysis of the Censys Internet Map. These are not just chatbots — they are the behind-the-scenes tools connecting AI to data, applications, and user accounts. And the worst stat: among n8n hosts with parseable versions, 76% were running a version within the affected range of at least one recent critical vulnerability.

If you self-host n8n, this post is for you. By the end, you will have run through a six-step checklist that takes your instance from "probably on the list" to "hardened" — most of it in under an hour.

What the report actually says

The numbers that matter for n8n builders:

n8n: ~114,000 exposed hosts, the most exposed AI product measured. Second place is OpenClaw (~54,000), the personal AI agent assistant.
Where they live: the US (62,687), China (42,511), and Germany (31,222) account for just over half of all exposed AI infrastructure.
Patch posture is the killer: 76% of n8n instances with a detectable version were vulnerable to at least one recent critical flaw. Exposure is bad; unpatched exposure is the whole ballgame.
Bonus finding that breaks a common habit: 68% of exposed HTTP(S) services and 34% of SSH services sat on non-standard ports. Running n8n on port 5679 instead of 5678 does not hide you from internet-wide scanners — it just annoys your team.

Censys also found roughly 134,000 internet-exposed hosts running industrial control systems (ICS), with about 70% on consumer and mobile networks — a reminder that "exposed by accident" is the default failure mode of the modern internet, not a rare event.

Source: Censys 2026 State of the Internet Report (released October 14, 2026), with n8n-specific figures summarized in this independent breakdown.

Censys continuously scans the entire internet — if your n8n answers on a public IP, it is almost certainly in their data.

Prerequisites

SSH access to the machine running your n8n instance.
Your n8n is self-hosted (Docker, npm, or a VPS install). n8n Cloud users: most of this is handled for you — skip to Step 4 for the version check.
A domain name pointing at your server (needed for the TLS step). No domain yet? Do Step 5's VPN approach instead and get the domain later.

Terminology: <your-domain> = your server's public domain (e.g. n8n.example.com). <your-port> = the port n8n listens on (default 5678).

Step 1 - Check whether you are exposed

Before changing anything, confirm your current exposure. Two free checks:

Censys itself: go to search.censys.io, create a free account, and search for your server's public IP or domain. If your n8n login page shows up, scanners have you.
From your own terminal, see what your server answers on the open internet:

# Run from a machine OUTSIDE your network (not from the server itself)
curl -s -o /dev/null -w "%{http_code}\n" http://<your-domain>:<your-port>/

A 200 with an n8n login page means anyone on the internet can reach your editor. A connection timeout means you are already firewalled — skip ahead to Step 4 for the patch check.

Warning: if Step 1 showed your editor is reachable AND you have no login configured (Step 2), treat this as urgent — anyone can open your workflows, read your credentials store entries, and execute workflows against your connected accounts.

Step 2 - Turn on authentication (or verify yours works)

n8n self-hosted instances should never serve the editor without a login. If you can open your editor in an incognito window without being asked for credentials, fix this now.

For a Docker Compose install, add to your docker-compose.yml (or .env file):

environment:
  - N8N_BASIC_AUTH_ACTIVE=true
  - N8N_BASIC_AUTH_USER=<your-username>
  - N8N_BASIC_AUTH_PASSWORD=<a-long-random-password>
  - N8N_BLOCK_ENV_ACCESS_IN_NODE=true

Why each key matters:

N8N_BASIC_AUTH_ACTIVE / N8N_BASIC_AUTH_USER / N8N_BASIC_AUTH_PASSWORD — forces a username/password prompt on the editor. This is the single highest-value change on this list.
N8N_BLOCK_ENV_ACCESS_IN_NODE=true — stops Code and Execute nodes from reading your process environment variables (where API keys and secrets often live). Enabled by default in recent n8n versions; set it explicitly so an upgrade never silently relaxes it.

Recreate the container (docker compose up -d), then open the editor in an incognito window. You should see a login prompt. If you don't, the variables didn't take — check for typos and that you edited the right compose file.

Step 3 - Put a reverse proxy with TLS in front

Exposed HTTP on port 5678 means login credentials travel in cleartext. Caddy is the fastest way to fix this — it fetches a free Let's Encrypt certificate automatically:

n8n.<your-domain> {
    reverse_proxy localhost:<your-port>
}

That's the whole file for the common case. Point your DNS at the server, run caddy run, and https://n8n.<your-domain> gets a valid certificate within a minute. Then close port <your-port> to the internet in your firewall — the proxy is the only thing that should talk to n8n directly:

sudo ufw deny <your-port>
sudo ufw allow 80,443/tcp

You should see: port scan of your server shows only 80/443 open, and https:// loads n8n with a valid certificate.

Step 4 - Patch n8n now (the 76% step)

This is the step the report is really about. Three out of four exposed n8n instances were running versions with known critical vulnerabilities — and the n8n October 2026 security update alone patched 14 advisories. Check your version in the n8n UI (bottom-left, Settings) and compare against the latest release:

# Docker Compose install: pull and restart with the latest stable image
docker compose pull n8n
docker compose up -d n8n
docker exec <n8n-container-name> n8n --version

You should see a version matching the current release line (2.43.x as of October 15, 2026 — verify against n8n's releases page). Then re-check Censys or the UI: your version should no longer fall in any advisory's affected range.

Unpatched instances get found by automation, not by humans picking targets. Patching removes you from the easy list.

Note: if you still run n8n via npm or npx, this is your deadline pressure too — n8n 3.0 drops npm/npx installs entirely. Migrate to Docker first, then patch.

Step 5 - Shrink the attack surface: firewall + editor access

Even patched and logged-in, an editor facing the whole internet is a standing invitation to password-spraying bots. Pick one:

Option A — IP allowlist (simplest). In your reverse proxy, only allow your office/home IPs on the editor paths, while leaving /webhook/* paths open for integrations:

# nginx example: editor locked down, webhooks public
location / {
    allow 203.0.113.0/24;   # your office IP range
    deny all;
    proxy_pass http://localhost:<your-port>;
}
location /webhook/ {
    proxy_pass http://localhost:<your-port>;
}

Option B — VPN only (strongest). Put the editor behind Tailscale or WireGuard and expose only webhook URLs publicly. Nothing on the internet can even start a login attempt.

Remember the report's non-standard-port finding: changing the port is not a defense. Scanners enumerate all 65,535 ports. Authentication, TLS, patching, and network restriction are defenses; obscurity is decoration.

Step 6 - Verify everything and schedule the next check

Run this final pass and set a calendar reminder:

Incognito window: editor requires login — confirmed.
curl from outside: only 443 answers; direct port is refused — confirmed.
n8n version matches the current release line — confirmed.
Search your domain on Censys again in 48 hours — your instance should show the updated version, or nothing at all if you went VPN-only.

Then make it recurring: subscribe to n8n's security advisories and re-run this checklist quarterly. The Censys trend line is one direction — exposure grew 63% in nine months — so "set and forget" is how instances end up in next year's report.

FAQ

Is my n8n really at risk if I only use it for personal automations?

Yes — arguably more. Personal instances tend to run older versions with weaker passwords, and they hold the same credentials (Gmail, Stripe, GitHub) an attacker wants. The 76%-unpatched figure includes exactly these installs.

Does n8n Cloud have this problem?

No. Cloud instances sit behind n8n's own hardened infrastructure with forced authentication. This checklist is for self-hosted instances — Docker, npm, or bare VPS installs.

I use a non-standard port. Am I safe?

No. Censys's report explicitly found most exposed services on non-standard ports — 68% of HTTP(S) and 34% of SSH. Scanners do not care about your port number.

How often should I update n8n?

At minimum, within days of any security advisory. n8n ships advisories through its docs and the October 2026 batch had 14 of them. A quarterly calendar reminder is the floor; same-week patching for security releases is the goal.

Key Takeaways

Censys's October 14 report names n8n the most exposed AI product on the internet — ~114,000 hosts, with 76% of version-detectable instances running vulnerable versions.
The fix is four layers, not one: forced authentication, TLS via reverse proxy, current patched version, and network restriction (firewall/VPN/IP allowlist).
Non-standard ports are not security — the report proves scanners find them routinely.
Patching is the highest-leverage step — exposure plus a known CVE is what turns a scan result into a breach.

Next: run Step 1 right now — it takes two minutes and tells you which half of this checklist is urgent for you. Then read our n8n October 2026 security update to see exactly which 14 advisories your patch covers.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Ruflo: The Open-Source Meta-Harness Running 100-Agent Coding Swarms

CortexFlow — Wed, 14 Oct 2026 08:30:03 +0000

What if you gave an AI agent a mission instead of a task — and it came back with researched code, passing tests, a security review, and a record of what everything cost? On October 13, 2026, Cognitum One released the latest version of Ruflo, the open-source "meta-harness" that turns one coding assistant (Claude Code, OpenAI Codex, or any MCP client) into a coordinated swarm of 100+ specialized agents. It is MIT-licensed, has over 74,000 GitHub stars, and recorded 12.5 million npm downloads in the last year.

The interesting part is not the star count. It is the premise Ruflo is built on: an agent is a model plus a harness. The model reasons and writes; the harness supplies the tools, memory, workflows, sandboxes, and controls that let it do real work. That idea has direct consequences for how you build agents in n8n — and here is the full loop Ruflo's new release describes, what builders should steal, and where the approach breaks down.

What's New in This Ruflo Release

The announcement (via ACCESS Newswire, published October 13, 2026) centers on two capabilities plus a bundle of supporting infrastructure:

Ruflo Mods: one mission, end to end. A Mod turns a single mission statement into a complete agent workflow — research, build, test, validate, secure, benchmark, and learn from the result. Mods route prompts and enforce policy directly inside Claude Code, so the mission logic travels with the agent rather than living in a doc nobody reads.

One control plane, with human approval. The Ruflo Console is a visual cockpit beside Claude Code that keeps missions, workflows, agent activity, logs, token usage, and cost in view. Administrators choose read, write, manage, or full control for Claude — and whether it acts automatically or asks first. The default is read access with approval, and a "Take back control" switch pauses Claude's console tools at any time.

Cross-machine agent federation. Independent Ruflo installations on different computers, organizations, or cloud regions can discover each other, delegate sub-tasks, and share workloads. Remote agents start untrusted and prove identity through mTLS and Ed25519 challenge-response (no shared secrets). Behavioral trust scoring upgrades reliable peers over time and downgrades misbehaving ones immediately.

Built-in PII data gating. A configurable 14-type detection pipeline scans outbound federation messages for email addresses, API keys, Social Security numbers, and similar data before anything leaves the local machine. Administrators set per-trust-level policies to block, redact, hash, or pass each type; HIPAA, SOC 2, and GDPR modes produce structured, searchable audit records.

SONA self-learning memory. Agents improve without retraining the underlying model. SONA, working with ReasoningBank and trajectory learning, captures successful execution patterns as local embeddings in HNSW-indexed AgentDB memory, so agents can reuse what worked in later tasks.

314 native MCP tools. Ruflo's Model Context Protocol surface spans 314 tools covering CI checks, local security scans, cloud deployment hooks, and observability pipelines — plus 26 CLI commands and 35 plugins. MCP is the open standard that lets one AI client talk to many external tool servers, and Ruflo sits on both sides of it.

Adaptive backpressure. A new messaging layer regulates delivery speed between swarm nodes, preventing timeouts and agent crashes during long, high-volume software engineering jobs.

MetaHarness and ruflo eject. MetaHarness grades an agent setup's readiness from 1 to 100, scans tool configurations for security risks, and snapshots projects to catch regressions between runs. ruflo eject packages a configured swarm into a standalone agent toolkit with its own name and command-line package.

Getting started: in Claude Code, run /plugin marketplace add ruvnet/ruflo, install ruflo-console@ruflo and ruflo-mods@ruflo, then /reload-plugins. For Codex and other MCP clients, run npx ruflo@latest init in a project, then connect the client to the Ruflo MCP server. Cognitum One recommends starting with one bounded task — such as a read-only project review — and adding agents, memory, and federation only as each earns its place.

Why the "Model + Harness" Premise Matters

Most agent failures I see are harness failures, not model failures. The model knew how to write the API call; the failure was that nobody capped its spend, nobody saved what it learned, nobody gated what data it could exfiltrate, and nobody could audit what it did. Ruflo's premise reframes the builder's job: you are not picking a smarter model, you are building a better harness — memory, routing, approvals, observability, policy enforcement.

That framing is worth importing wholesale. If your agent cannot answer "what did it run, what did it cost, and what data crossed the boundary," you do not have an agent system. You have a chat window with ambitions.

What n8n Builders Should Steal

Ruflo is a coding-agent harness, but five of its ideas map cleanly onto automation agents built in n8n:

1. Treat the harness as the product. In n8n terms: the AI Agent node is the model; everything around it — the tools you attach, the memory backend, the error workflow, the execution logging — is the harness. When an agent misbehaves, debug the harness first. This is the same lesson as our n8n AI Agent memory guide: most "forgetful agent" bugs live in the memory backend choice, not the model.

2. Mission-style definitions beat task lists. Ruflo Mods encode the whole mission loop (research → build → test → validate → secure → learn) once. In n8n, the equivalent is a well-scoped system prompt plus sub-workflows: define the loop once, reuse it everywhere. If you find yourself re-explaining the same review process in five workflows, you have a Mod-shaped hole.

3. Default to approval, upgrade to autonomy. Ruflo defaults to read access with approval — the agent asks before it acts. n8n already has the machinery: per-tool human-in-the-loop approvals via chat, Slack, Telegram, or email. The Ruflo pattern to copy is the default posture: start every new agent asking for permission, and grant autonomy only where the blast radius is understood.

4. Route by cost, not by habit. Ruflo's intelligent model routing sends simple tasks to cheaper, faster models and reserves top-tier models for complex reasoning. In n8n, you can do this today: a classifier node or a small local model triages incoming work, and only the hard cases reach your expensive frontier model. Sending every decision to your biggest LLM is the fastest way to burn budget.

5. Memory that learns across runs. SONA captures successful execution patterns as local embeddings so agents reuse what worked. n8n's closest equivalents are Chat Memory Manager and database-backed memory with long-lived session IDs — the point being that memory should accumulate across runs, not reset with each execution.

Honest Limits and Where This Breaks

A 100-agent swarm is not free in any sense of the word. Every agent burns tokens, and coordination overhead grows faster than the swarm — queen-led topologies help, but more agents means more messages, more tool calls, and more places for a wrong assumption to propagate. Ruflo's adaptive backpressure exists precisely because long swarm runs time out and crash without it.

Federation across machines is the riskiest feature here. mTLS and Ed25519 challenge-response are the right primitives, and PII gating is a genuinely thoughtful control — but "behavioral trust scoring" is doing a lot of work in one sentence. In production, treat every federated peer as adversarial until proven otherwise, and run PII gating in block mode until you have read every redaction decision it made on real traffic.

Also worth noting: 74,000 stars is a community signal, not a production guarantee.

Ruflo is MIT-licensed and available at github.com/ruvnet/ruflo, but enterprise features (commercial licensing, support, deployment inside Cognitum One's ruOS) sit behind the company. Evaluate it the way you would any open-source infrastructure: read the MetaHarness readiness report on your own setup before trusting it with production credentials.

FAQ

What is Ruflo?

Ruflo is an open-source AI agent meta-harness and multi-agent orchestration platform from Cognitum One (MIT license). It turns one coding assistant — Claude Code, OpenAI Codex, or any MCP client — into a coordinated swarm of specialized agents (planner, coder, tester, reviewer, security, docs) with shared memory, model routing, and human approval controls.

Is Ruflo free?

The core is MIT-licensed open source (github.com/ruvnet/ruflo). Model provider costs still apply — you pay Claude/OpenAI/your provider for the tokens the swarm burns, which with 100 agents can add up fast. Commercial licensing, enterprise support, and managed deployment (ruOS) are paid.

How does Ruflo relate to n8n?

Ruflo orchestrates coding agents; n8n orchestrates workflow automation agents. They solve the same class of problem at different layers — and n8n's first-class Agents (sub-agents, skills, human-in-the-loop approvals) are where the meta-harness ideas apply directly. One is not a replacement for the other.

What should I try first?

Cognitum One's own advice: start with one bounded, read-only task like a project review. Watch the Console's cost and activity views. Add memory, then more agents, then federation — each only after the previous layer earns its place.

Key Takeaways

Ruflo (announced Oct 13, 2026) is an open-source meta-harness that turns one coding assistant into a governed swarm of 100+ agents via Claude Code, Codex, or any MCP client.
Its core premise — an agent is a model plus a harness — reframes agent building around memory, routing, approvals, observability, and policy instead of model choice.
New capabilities worth attention: Ruflo Mods (mission → full workflow), a control plane defaulting to approval, cross-machine federation with PII gating, SONA self-learning memory, and 314 MCP tools.
For n8n builders: default to approval, route models by cost, make memory accumulate across runs, and encode missions once instead of repeating them per workflow.
Honest limit: swarms multiply token cost and coordination risk; treat federation as adversarial by default and verify PII gating on real traffic before trusting it.

Conclusion

The most useful idea in this release is not any single feature — it is the checklist the meta-harness premise gives you: what did it run, what did it cost, what data crossed the boundary, and what did it learn for next time. If your n8n agents can answer those four questions, your harness is already better than most. For the full announcements referenced in this piece, the original press release is linked above; for n8n-specific agent hardening, read our guide on AI agent memory next.

Images: Unsplash / Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Shai-Hulud Just Infected an AI Agent Platform's npm Package — What Self-Hosted n8n Builders Must Do Now

CortexFlow — Fri, 09 Oct 2026 08:30:03 +0000

On October 8, 2026, the npm package tensorlake — the TypeScript SDK for Tensorlake's AI agent infrastructure — was compromised by a new Shai-Hulud worm variant. Version 0.5.144 shipped a preinstall hook that stole npm tokens, GitHub tokens, AWS keys, SSH keys, .env files, crypto wallets, and browser passwords from every machine that installed it. The version was pulled within minutes, but the malware persists on infected hosts.

If you self-host n8n, this is your threat model: you live on npm. Every community node you install, every Docker rebuild that runs npm install, every npx in your CI pipeline runs install scripts. This article walks through exactly how this attack worked — and the concrete checklist that keeps your secrets out of the next one.

The attack chain: verified commits to poisoned publish in 20 hours

According to Aikido's analysis, the infection didn't start with a typo-squatted package. It started inside the legitimate tensorlake GitHub repository. On October 7, the threat actor made verified commits under the identity of a maintainer — the malware was introduced in commit 41b38f0 via direct file upload, and the actor then bumped the version to trigger a publish. The repository was compromised for roughly 20 hours before version 0.5.144 went live on npm.

Your dependency can be poisoned at the source, not just by a lookalike name. The registry did everything "right" — the package was real, the version was real, the publisher identity was stolen at the repo level.

Timeline, per Socket (who flagged the malicious release 11 minutes after it published, at 01:23:10 UTC on October 8):

01:12:07 UTC, Oct 8 — tensorlake@0.5.144 published to npm.
01:23:10 UTC — Socket's scanner flags it; researchers confirm a ChainDrop/Shai-Hulud payload.
Shortly after — version 0.5.144 is removed from the registry. Clean versions remain, but damage is already done on any host that ran npm install in between.

With ~12,000 weekly downloads and 1k+ GitHub stars, the package's reach is far from trivial — even a minutes-long window can hit CI pipelines that install the latest version on every run.

A compromised package doesn't attack your server — it attacks the developer machine that installs it.

What the malware actually does: preinstall is the whole game

The poisoned release carried an npm preinstall hook — a script that runs automatically the moment you install the package, before your code ever touches it. Here's the chain:

preinstall launches package/lib/setup.mjs, an obfuscated loader.
The loader installs the Bun runtime and uses it to execute package/lib/Math_Symbol.js — the main credential-stealing, self-propagating worm.
The stealer harvests credentials from local files, CI environments, Kubernetes configs, and Vault sources, then drops the HackBrowserData binary to extract browser-stored credentials too.
It exfiltrates everything, establishes persistence on the host, and opens a channel for remotely supplied code execution — with C2 coordinated through an Ethereum contract and GitHub as a fallback.

The stolen-data list reads like an inventory of a working developer's life: npm tokens, GitHub tokens, AWS credentials and secrets, HashiCorp Vault data, Kubernetes credentials, SSH keys, .env files, crypto wallets, browser passwords, Anthropic Claude config files, and messaging app data. This variant also targets 14 cryptocurrency browser extensions specifically — Aikido notes this suggests an operator more focused on quickly monetizing infected developer endpoints than on further supply-chain propagation.

The nasty part Socket warns about: persistence can survive removing the dependency. And per The Register's reporting, this variant monitors certain stolen GitHub tokens — if one is revoked, the malware can trigger deletion of the infected user's home directory under specific conditions. That means the cleanup order matters: disable the malicious token monitor before you revoke credentials, or the attacker burns the machine out of spite.

Why n8n self-hosters are squarely in the blast radius

Most self-hosted n8n setups depend on npm in at least one of these ways:

npm-installed n8n itself (npm install -g n8n) — every update executes install scripts as your user.
Community nodes — installed via npm from the editor; n8n 3.0 is already disabling unverified community nodes because this vector is that serious.
Custom Docker builds — RUN npm install during image build runs preinstall hooks inside your build environment, which often holds registry credentials.
CI pipelines — a nightly npm install pulling latest is exactly the shape of install that caught the malicious Tensorlake window.

The deeper problem: a workflow automation server is a secrets concentration point. Your n8n host holds API keys for OpenAI, Stripe, your database, your CRM — the exact kind of material this worm was built to harvest. An infected build machine doesn't just compromise one account; it compromises the keys that run your business.

A self-hosted automation server is a secrets concentration point — exactly what this worm hunts.

The checklist: what to do today

This is a how-to embedded in the news, because the next Shai-Hulud wave will use the same shape.

1. Check whether you installed 0.5.144

Search your lockfiles and install history:

grep -r "tensorlake" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
npm ls tensorlake 2>/dev/null

If the answer is yes: do not just uninstall. Uninstalling removes the package but not the persistence. Socket's guidance: rebuild the affected system from a trusted source before restoring access to secrets, and rotate every credential the machine could see — then revoke. And per researcher warnings, neutralize the token monitor before revoking affected tokens.

2. Stop running npm install scripts by default

Most install scripts are conveniences, not necessities. Disable them:

npm config set ignore-scripts true

Why it works: preinstall/preinstall hooks — the exact mechanism this worm used — simply never execute. If a package genuinely needs its build step (rare for apps), allow it explicitly per-package. In Docker builds, this one line removes the install-time attack surface from every image you build.

3. Pin versions and audit the diff

Floating ranges (^0.5.144) in a CI pipeline that runs nightly is how a 20-hour malicious window becomes your incident. Pin exact versions, commit the lockfile, and make dependency updates a deliberate, reviewable PR — not an automatic pull. n8n's own 3.0 guidance on unverified community nodes points the same direction: treat every installed package as a trust decision.

4. Isolate where you install

Run npm install in throwaway CI runners or containers with no long-lived credentials mounted — never on the machine that holds your production secrets. If your n8n host and your build machine are the same box, that is the single biggest structural fix available to you.

5. Scan before you trust

Socket flagged this release in 11 minutes. Tools like Socket's scanner or Aikido's Safe Chain intercept npm/npx installs and check packages against malware intel before they run. One of them on your CI is cheap insurance against the next wave — the August keyv/flat-cache compromise used the same ChainDrop family, and the pattern is clearly not done.

Where this pattern is heading

Shai-Hulud has evolved from generic npm typosquatting into a purpose-built AI-infrastructure hunter. The Tensorlake compromise is the first public case of the worm jumping to an AI agent platform — and the operator's pivot toward crypto wallets and browser stores suggests these campaigns are being run as profitable criminal operations, not one-off stunts.

For agent builders, the takeaway is structural: your automation stack's security is the union of every dependency's security. The AI Agent node you configured perfectly means nothing if the install script that delivered your community node ran setup.mjs first. Secrets hygiene, install isolation, and script-disabled installs are the cheapest defenses you have — adopt them before you need them.

Key Takeaways

tensorlake@0.5.144 was poisoned on Oct 8, 2026 — preinstall hook → obfuscated loader → Bun-executed worm stealing npm/GitHub/AWS/Vault/SSH/crypto credentials and browser passwords.
The repo itself was compromised — verified commits under a stolen maintainer identity, 20 hours before publish. Lockfile pinning plus malware scanning beat trust in upstream.
Persistence survives uninstall — rebuild from a trusted source, rotate everything, and neutralize the token monitor before revoking tokens.
Kill the install-script vector now — npm config set ignore-scripts true, pin exact versions, and never npm install on the machine that holds your production secrets.
n8n self-hosters are high-value targets — community nodes, npm installs, and CI builds are exactly the surfaces this worm family hunts.

Next: run the grep in step 1 across your projects today — and if any lockfile shows 0.5.144, treat it as an active incident, not a cleanup task.

FAQ

Was I affected if I never installed the tensorlake package?

No. The malicious code only ran on machines that installed tensorlake@0.5.144 during the window before it was removed from npm. If you never had it in a lockfile or install log, you're not affected by this specific incident — but the hardening steps above protect you from the next one.

Why is preinstall so dangerous compared to a normal compromised package?

A normal compromised package only runs when you execute its code. A preinstall hook runs automatically during npm install, with your user's permissions, on the machine doing the install — which often holds CI secrets, AWS keys, and SSH credentials. You get infected without ever importing the library.

Does using Docker protect me from this class of attack?

Partially. Docker isolates the running workflow from the host, but RUN npm install in your Dockerfile still executes preinstall hooks during the build — and build environments often carry registry credentials. The fix is npm config set ignore-scripts true in your Dockerfiles plus multi-stage builds that don't leak build-time secrets.

How fast was this caught?

Socket flagged tensorlake@0.5.144 at 01:23:10 UTC on October 8, 2026 — roughly 11 minutes after publication. The version was then removed from the npm registry. Speed of detection doesn't help hosts that installed during the window, which is why scanning must happen before install.

Images: Pexels

[Sources: Socket, Aikido, The Hacker News, The Register]

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

n8n 2.43.0 Is a Guardrails Release: No More Publishing Broken Workflows

CortexFlow — Thu, 08 Oct 2026 08:29:54 +0000

n8n shipped 2.43.0 on October 6, 2026, and the changelog reads like a production-hardening checklist rather than a feature launch. The marquee fix is a simple one: n8n now blocks you from publishing a workflow that has unconnected required node inputs (commit 5e28ff8, tracked as #37265). Around it, the release applies policy checks to CLI commands, extends MCP availability rules to error workflows, deduplicates agent message deliveries, and fixes agent session handling on SQLite. The pattern is unmistakable — n8n is spending this release cycle on making agents fail less often, not do more things.

In this post: what each of the important 2.43.0 changes actually does for you, why the publishing guardrail is the headline, and the upgrade path if you're self-hosting.

The headline: n8n stops you from publishing broken workflows

The most impactful single change is core: Block publishing workflows with unconnected required node inputs. Before 2.43.0, you could publish (activate) a workflow where a required input of a node was left dangling — say you dragged in an Agent node, connected the model, but never wired the chat trigger. The workflow would then run in production and fail silently, or worse, fire half-built automations against real APIs.

Now the editor refuses to publish until required inputs are connected. This matters more than it looks:

For agent workflows, "required inputs" includes the tool connections, memory, and model sub-nodes that the Agent node depends on. Agents are exactly the workflows most likely to be published half-wired because they have the most connections.
For teams, it kills a whole class of "it worked in testing" incidents where a dev published a draft during iteration and forgot.
For automated publishing (CI/CD pipelines that activate workflows via the API or CLI), this pairs with the new CLI policy checks below — the same guardrail logic is being applied everywhere publishing happens.

The honest limitation: this only catches structurally unconnected required inputs. It will not catch a connected-but-misconfigured node, a wrong credential, or a prompt that hallucinates. Structural guardrails shrink the failure surface; they don't eliminate testing.

Policy checks now apply to the CLI too

Two related changes extend n8n's guardrail logic beyond the editor UI:

core: Apply policy checks to CLI import and execute commands (#39714) — organizations that define policies (restrictions on node usage, credentials, etc.) now get those same policies enforced when workflows are imported or executed through the n8n CLI. Before this, a policy that blocked a risky node in the editor could be bypassed by importing the same workflow from the command line. That's a real hole, and it's now closed.
core: Apply MCP availability rules to error workflow settings (#39885) — MCP, or Model Context Protocol, is the standard way AI tools expose themselves to models. n8n checks which MCP features are available to an instance; this change makes those same availability rules apply to error workflows (the workflows that run when another workflow fails). Your failure handlers get the same tooling guarantees as your main workflows.

Together with the publishing block, these three changes form a coherent theme: guardrails that previously only existed in the editor now follow the workflow everywhere — CLI, error paths, and publishing.

Agent sessions get more reliable

The Agent node received several reliability fixes that matter if you run agents in production:

core: Deduplicate agent message deliveries (#39794) — agent messages were being delivered more than once in some paths. If your agent talks to Slack or a webhook, duplicate deliveries meant duplicate replies. That's the kind of bug that erodes user trust in an agent fast.
core: Correct Agent session pagination on SQLite (#39802) — if you self-host n8n with SQLite (the default for small Docker/npm installs), agent session history pagination was wrong, meaning sessions could show missing or duplicated messages. Fixed.
core: Connect Slack Agent channels through managed setup in MCP (#39776) — wiring Slack channels to the Slack Agent node now goes through n8n's managed MCP setup, which is the path n8n wants you on for agent-to-channel integrations.
Agent Node: Remove outdated tutorial tip callout (#35505) and core: Apply removed fields when the Agent Builder patches agent config (#40122) — the AI-assisted agent builder now handles deprecated fields correctly when patching agent configs, and a stale tutorial tip is gone.

Also relevant: ai-builder: Treat a blank folder path as no folder in the build tool (#40116) — a small paper-cut fix for the AI workflow builder.

Azure OpenAI Responses-only deployments now work

Azure OpenAI Chat Model Node: Support Responses-only deployments (#39403) — Azure OpenAI lets enterprises create deployments that only expose the Responses API (OpenAI's newer unified API surface) rather than the legacy Chat Completions API. n8n's Azure OpenAI node previously couldn't talk to these. If your organization standardized on Responses API deployments — common in Azure-centric enterprises — your n8n agents can now use them directly instead of routing through a generic HTTP node.

What I didn't verify: the release-notes aggregators also list expanded support for Databricks, Google Calendar, and Supabase nodes in this release. The official changelog excerpt I reviewed in detail didn't surface the individual commits for those, so treat that list as plausible-but-unconfirmed until you read the full notes yourself.

Shutdown and multi-instance behavior gets safer

Two changes target the least glamorous part of production: shutting down cleanly.

core: Cap pending task request timeouts to the shutdown deadline (#40136) — when n8n shuts down, pending task-runner requests could hang past the deadline. Timeouts are now capped so shutdown actually completes. This matters for containerized deploys (Docker, Kubernetes) where the orchestrator kills you after the grace period whether you're done or not.
core: Keep floating entitlements attached when a multi-main instance shuts down (#39713) — in multi-main setups (n8n's high-availability mode), license entitlements could detach during shutdown, causing entitlement checks to fail on restart. Fixed.

Plus editor quality-of-life: pasted nodes now center in the canvas viewport (#39995), the From AI button aligns with parameter inputs (#40152), and the workflow SDK group layout for AI subtrees and sticky notes improved (#39981).

API changes for programmatic teams

Three API-side fixes are worth knowing if you manage n8n programmatically:

API: Let global members grant variable scopes to API keys (#40064) — continuing the permission tightening started in 2.41.7, global members can now grant variable scopes to API keys, giving finer control over what API credentials can touch.
API: Emit valid schemas for untyped values in the Public API spec (#39884) — the generated API spec no longer emits invalid schemas for untyped values, which fixes broken codegen for some API clients.
core: Generate missing workflow IDs in the import:workflow command (#40011) — importing workflows via CLI no longer chokes on missing IDs.

Should you upgrade?

If you're on the 2.4x line, 2.43.0 is a no-regrets upgrade: it's a bug-fix release with no breaking changes, and the publishing guardrail alone is worth it. If you're self-hosting, the upgrade is the same drill as always:

# Docker (recommended path)
docker pull n8nio/n8n:2.43.0
# then recreate your container against your existing data volume

# npm
npm install -g n8n@2.43.0

Two precautions, as always: back up your n8n data first (database + ~/.n8n encryption key if you use npm), and if you're several versions behind, skim the breaking-change notes — the October 2026 security update covered the CVE-driven releases that may have forced intermediate jumps. Running our n8n security advisory triage template against this release is a quick way to decide priority across your fleet.

What I didn't test: I did not run the upgrade myself — the changes above are from the published changelog, not from my own instance. The guardrails are described from the release notes, so if your publishing flow goes through a custom script, test the new block in staging before it surprises your CI.

FAQ

Does n8n 2.43.0 contain security fixes?

The published 2.43.0 changelog I reviewed lists no CVEs or security advisories — it's a bug-fix and hardening release. If you haven't applied the October security patches yet (see the October 2026 security update), do that first; 2.43.0 includes all prior 2.x patches by virtue of being the latest point release.

Will the publishing block break my CI/CD pipeline?

It will only block publishing if your workflows have unconnected required inputs — which is precisely the case that produces broken production runs. If your pipeline publishes workflows generated by the AI builder, run one publish in staging first to confirm everything is wired. This is a feature, not a regression, but it can surface latent wiring bugs in workflows that previously published silently.

Is 2.43.0 related to the 2.42.x line?

Yes — 2.43.0 is the next release after the 2.42.x beta line we covered when 2.41.4 and the 2.42 beta shipped. The 2.42 series has stabilized into 2.43.0, so if you were tracking beta for the AI Assistant and Agent work, this is your off-ramp onto a stable-ish line.

Key Takeaways

n8n 2.43.0 is a guardrails release, not a feature release: the headline change blocks publishing workflows with unconnected required node inputs.
Policy checks now apply to CLI import/execute and MCP availability rules reach error workflows — guardrails follow your workflows everywhere, not just the editor.
Agent reliability fixes: deduplicated message deliveries, corrected SQLite session pagination, and Slack Agent via managed MCP setup.
Azure OpenAI Responses-only deployments are now supported in the Azure OpenAI node — relevant for Azure-standardized enterprises.
Upgrade is low-risk if you're already on 2.x; back up first, and use the security advisory triage template to prioritize across a fleet.

The bigger story: n8n is quietly rebuilding itself around production agents, one guardrail at a time. How n8n's AI Assistant and Agents fit together is the right context piece if you want to see where this hardening trend points next.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

Langflow's MCP Server Setup Let Any User Run OS Commands on the Host: CVE-2026-105697 Patch Guide

CortexFlow — Wed, 07 Oct 2026 08:30:00 +0000

On October 5, 2026, a CVSS 9.9 critical vulnerability was disclosed in Langflow, the open-source platform many builders use to prototype AI agents and workflows: CVE-2026-105697, an OS command injection (CWE-78) in its MCP server handling. Before Langflow 1.10.3, the MCP stdio transport would launch whatever command a user typed into the MCP server configuration — no allowlist, wrapped in bash -c. A public proof-of-concept is already available. If you self-host Langflow, upgrade to 1.10.3 (or langflow-base 0.10.3 / lfx 1.10.3) now — and disable the dev-only auto-login setting if it's still on. This post explains exactly what broke, whether you're exposed, and how to patch.

What CVE-2026-105697 is

Langflow lets users connect MCP (Model Context Protocol) servers to flows — either through the UI (Settings → MCP Servers → Add MCP Server, which hits POST/PATCH /api/v2/mcp/servers/{server_name}) or through the MCP Tools component inside a flow. With a stdio transport, "connecting" to an MCP server means the platform launches a local process.

The problem: before version 1.10.3, Langflow took the command and args fields from the MCP server configuration and executed them directly — with no allowlist of permitted commands, and wrapped in bash -c "exec {command} ...". So a "server" whose command was touch /tmp/pwned, rm -rf /something, or a reverse shell wasn't validated or rejected — it ran on the Langflow host as the Langflow process user the moment Langflow tried to connect to the server (listing servers, loading tools, or running the flow). Even if the UI later reported that the stdio server failed to start, the command had already executed.

The worst part: unauthenticated on default instances

Most critical RCEs at least require an account. This one often doesn't.

Langflow ships with LANGFLOW_AUTO_LOGIN=true by default — documented as a development-only setting. With it enabled, a single request to GET /api/v1/auto_login hands out a token without credentials. So on any Langflow instance exposed to the internet with the default configuration, this vulnerability was reachable without an account at all.

With auto-login disabled (as it should be in production), the flaw is still exploitable by any authenticated non-admin user — anyone who can reach the MCP server settings or build a flow with the MCP Tools component. In shared or team environments, that's a wide privilege boundary: a low-privilege user gets OS-level command execution on the host.

Which versions are affected

Package	Vulnerable	Patch to
Langflow	< 1.10.3	1.10.3
langflow-base	< 0.10.3	0.10.3
lfx	< 1.10.3	1.10.3

Disclosed October 5, 2026 (record modified October 6). Per the CVE metadata: public PoC available, not yet in the CISA Known Exploited Vulnerabilities catalog (no confirmed in-the-wild exploitation as of publication), EPSS 0.40% — but with a PoC public and a 9.9 score, treat the window between disclosure and patching as your real risk.

Warning: check LANGFLOW_AUTO_LOGIN first, not your version number. If your instance is internet-exposed and auto-login was on, assume it was reachable unauthenticated and review your logs and host for signs of compromise before you trust the patch alone.

Are you exposed? A 60-second check

Is your Langflow reachable from the internet? Check your reverse proxy, security groups, or curl it from outside your network.
Is LANGFLOW_AUTO_LOGIN=true? Check your environment or Docker compose. If yes, this setting should never have been on outside local dev.
Which version are you on? pip show langflow or check the Docker image tag. Anything below 1.10.3 / 0.10.3 is vulnerable.
Who has accounts? With auto-login off, every non-admin account was a potential entry point — review your user list.

How to patch

Prerequisites: back up your Langflow data (flows, credentials, the database or ~/.langflow directory) before upgrading.

Step 1 — Upgrade to the fixed version

If you installed via pip:

pip install --upgrade "langflow>=1.10.3"

If you're using the langflow-base package:

pip install --upgrade "langflow-base>=0.10.3"

If you run the official Docker image:

docker pull langflowai/langflow:latest
# then recreate your container (your data volume holds flows + db)

Step 2 — Turn off auto-login in anything that isn't local dev

export LANGFLOW_AUTO_LOGIN=false

or in your Docker compose / env file:

LANGFLOW_AUTO_LOGIN=false

Step 3 — Don't expose Langflow directly

Put Langflow behind a reverse proxy with authentication (or a VPN / private network), and restrict which hosts can reach it. Langflow holds API keys and credentials in its flows — it should never be a public URL with default settings.

Step 4 — Look for compromise if you were exposed

If your instance was internet-reachable with auto-login on and running a vulnerable version: review flow and MCP server configurations for entries you didn't create, check the host for unexpected processes or files, rotate every credential and API key stored in Langflow, and consider rebuilding the host from a clean image.

The bigger lesson: MCP server configs are privileged

This is the part every agent builder should internalize, even if you've never touched Langflow. An MCP stdio server definition is arbitrary code execution by design — it launches a process on the host. That means the configuration surface for MCP servers should be treated with the same seriousness as SSH access or sudo: allowlists for commands, least-privilege users, and no unauthenticated access, ever.

The same caution applies to the MCP nodes in your own stack. If you're wiring MCP into n8n, our MCP + n8n troubleshooting guide covers the transport pitfalls — and the general principle stands: anything that launches a process on your behalf must never accept unvalidated input from a lower-privilege user. This is also the second high-severity AI-infrastructure CVE in a week affecting agent builders, after GitLab's AI Gateway sandbox escape — the attack surface is moving from models to the glue around them.

FAQ

What is CVE-2026-105697?

A critical (CVSS 9.9) OS command injection in Langflow, disclosed October 5, 2026. Before Langflow 1.10.3, the MCP stdio transport executed whatever command a user put in an MCP server configuration — no allowlist, wrapped in bash -c — running it on the Langflow host. Fixed in Langflow 1.10.3, langflow-base 0.10.3, and lfx 1.10.3.

Do I need an account to exploit it?

On instances with the default LANGFLOW_AUTO_LOGIN=true exposed to the internet: no — GET /api/v1/auto_login issues a token without credentials. With auto-login disabled, any authenticated non-admin user could exploit it.

Is there a public exploit?

Yes — proof-of-concept references and code are publicly available. It is not in the CISA KEV catalog yet, meaning no confirmed in-the-wild exploitation has been recorded. Patch anyway; the PoC closes the gap between theory and practice.

I'm an n8n user — should I care?

Yes, for the pattern, not the package. n8n has its own MCP integrations, and the same class of bug — unvalidated command/argument handling in a tool-execution path — keeps appearing across agent infrastructure (see n8n's own October CVEs). Audit any workflow platform where a low-privilege user can define something that launches a process.

Conclusion

CVE-2026-105697 is a textbook reminder that the most dangerous code in an AI agent stack is often not the model — it's the launcher. A configuration field that accepts a command and runs it is a shell, and Langflow treated it like a settings form. Upgrade to Langflow 1.10.3, kill auto-login outside local dev, and stop exposing workflow platforms to the open internet. Then audit the rest of your agent glue for the same shape of flaw — because this class of bug is having a very busy October.

Images: Pexels

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/

n8n Published Two CVEs in One Day: Expression Sandbox Escape (CVE-2026-86076) and Argument Injection (CVE-2026-44790)

CortexFlow — Tue, 06 Oct 2026 08:29:55 +0000

On October 5, 2026, n8n disclosed two security advisories in a single day — both able to hand an attacker full control of the server your workflows and agents run on. The first, CVE-2026-86076 (CVSS 8.7), is an expression sandbox escape: a crafted workflow expression can break out of n8n's expression compiler and execute arbitrary code in the n8n process. The second, CVE-2026-44790 (CVSS 9.4), is an argument-injection flaw. Neither is known to be exploited yet, but both are published, so the fix versions are your move: upgrade to n8n 1.123.76, 2.37.7, or 2.38.2 depending on your release line. This post explains what broke, whether you're exposed, and the exact steps to patch.

CVE-2026-86076: the expression sandbox escape

n8n lets workflow builders write expressions — little snippets like ={{ $json.name }} inside node parameters that get evaluated when the workflow runs. Expressions are supposed to run inside a sandbox, a restricted environment where they can transform data but can't touch the server, spawn processes, or call the JavaScript Function constructor.

CVE-2026-86076 broke that boundary. Per n8n's advisory (GHSA-hw8v-xxg5-vvvx), the expression compiler's sanitizer — the code that keeps expressions safe — was resolved through a dynamically-scoped this. An attacker could define a class field named __sanitize that rebound the sanitizer to a malicious value and reached the Function constructor. Once you have Function, you have arbitrary JavaScript execution. Game over.

The blast radius depends on where the expression runs:

On the backend: any expression author could run code inside the n8n process — the same process that holds your credentials, your workflow definitions, and your execution history.
In the editor preview: a member's crafted expression could execute JavaScript in the browser session of whoever opened the workflow — meaning a malicious teammate (or a compromised account) could attack other editors just by getting them to open a workflow.

The patch rejects reserved class-member names like __sanitize, closing the rebinding path.

Which n8n versions are affected

Your line	Vulnerable	Patch to
n8n 2.38.x	>= 2.38.0, < 2.38.2	2.38.2
n8n 2.0 – 2.37.x	>= 2.0.0, < 2.37.7	2.37.7
n8n 1.x (LTS-era)	< 1.123.76	1.123.76

First published October 5, 2026; first seen in the wild as an advisory record on September 8, 2026. Per the advisory metadata: not known to be exploited, needs hands-on effort to exploit — but gives an attacker full control when it works.

Warning: this hits hardest on shared or multi-user n8n instances — anyone who can create or edit a workflow is an "expression author." If you hand workflow-edit rights to clients, contractors, or junior team members, treat this as urgent rather than routine.

CVE-2026-44790: argument injection, CVSS 9.4

The same-day second advisory, CVE-2026-44790 (GHSA-57g9-58c2-xjg3), is classified CWE-88: improper neutralization of argument delimiters — an argument-injection flaw. The published details are thinner than for CVE-2026-86076, but the metadata is unambiguous: CVSS 9.4, critical, published October 5, 2026, gives an attacker full control, needs hands-on effort, not known to be exploited. Track it through the GitHub advisory and the NVD record, and patch on the same upgrade window as CVE-2026-86076 — the advisory metadata notes vendor patches were already being shipped through the fixed lines above.

How to patch your self-hosted n8n

Prerequisites: SSH or terminal access to the host running n8n, and a recent backup. n8n's data (workflows, credentials, executions) lives in its SQLite file or Postgres database plus the N8N_ENCRYPTION_KEY — back up both before upgrading, because a failed upgrade without the key means locked credentials.

Example terminology: <your-n8n-host> is your server. Replace it in every command.

Step 1 - Back up before you touch anything

Why: credential blobs are encrypted with N8N_ENCRYPTION_KEY; if the upgrade fails midway and you lose the data volume, the key alone won't restore your workflows.

# If n8n runs in Docker with a named volume:
docker stop n8n
docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/n8n-backup-$(date +%F).tar.gz /data
docker start n8n

You should see docker start n8n report the container is running. Keep the tarball somewhere off-host. If you use Postgres externally, take your usual pg_dump instead.

Note: if you have never exported N8N_ENCRYPTION_KEY to a safe place, do it now — printenv it from the running container and store it in your secrets manager. A volume backup without the key is a paperweight.

Step 2 - Upgrade to the fixed version

Why: the patch is only in 1.123.76, 2.37.7, and 2.38.2 (or later). Match your line from the table above — don't jump lines casually, especially from 1.x to 2.x, which has breaking changes.

Docker (most self-hosted setups):

docker pull n8nio/n8n:2.38.2
docker stop n8n && docker rm n8n
docker run -d --name n8n \
  --env-file /path/to/your/n8n.env \
  -v n8n_data:/home/node/.n8n \
  -p 5678:5678 \
  n8nio/n8n:2.38.2

Replace the image tag with 1.123.76 or 2.37.7 if that's your line, and keep your own --env-file, volumes, and port mapping — the lines above are the shape, not your exact config.

npm installs:

npm update -g n8n
# then pin-check: n8n --version

You should see the fixed version number in the output — for example 2.38.2.

Step 3 - Verify the fix is live

Why: a container can restart on the old image if the pull failed or the tag was cached.

docker exec n8n n8n --version

You should see 2.38.2 (or 2.37.7 / 1.123.76). Then open the n8n UI: Settings → About (bottom-left) should show the same version.

Step 4 - Audit who could have written expressions

Why: the vulnerability window was open from first-seen (September 8, 2026) to your patch. If untrusted users had workflow-create or workflow-edit rights during that window, check whether they planted anything.

Review Users / members in the instance: anyone with edit rights you don't fully trust should have them reviewed.
Scan recently modified workflows for unfamiliar expressions in node parameters, especially anything referencing __sanitize, constructor, or Function.
If anything looks wrong, treat it as a compromise: rotate credentials stored in n8n, check connected services for unexpected activity, and review execution logs for the affected period.

If you can't upgrade today

n8n's advisory lists short-term mitigations — they reduce exposure but do not fix the flaw:

Restrict instance access to fully trusted users only.
Stop granting workflow-create or workflow-edit permissions to untrusted users.
Audit existing workflows for unexpected expressions in node parameters.
Set the environment variable N8N_EXPRESSION_ENGINE=vm to switch the expression engine.

Do these only as a bridge to the upgrade, not instead of it.

Free template: n8n Security Advisory Triage — a ready-to-import n8n workflow that watches for new n8n security advisories and alerts you the moment one drops, so the next CVE doesn't catch you by surprise.

Key Takeaways

CVE-2026-86076 (CVSS 8.7): a class field named __sanitize rebinds n8n's expression sanitizer and reaches the Function constructor — full code execution in the n8n process, or in another editor's browser session via workflow preview.
CVE-2026-44790 (CVSS 9.4): an argument-injection flaw disclosed the same day — thinner public detail, higher severity; patch in the same window.
Fix versions: 1.123.76, 2.37.7, 2.38.2 — match your release line; back up data + N8N_ENCRYPTION_KEY first.
Multi-user instances are the high-risk case — anyone with workflow-edit rights is an expression author.
The pattern repeats: agent and automation control planes concentrate credentials and tool access, so classic bug classes (sandbox escapes, argument injection) keep landing there. My earlier pieces on the n8n October security update and the GitLab AI Gateway flaw are the same story from different angles.

Next: check which of your n8n members hold workflow-edit rights right now, and whether any of them shouldn't. The patch closes the hole; the permission audit closes the habit.

Images: Unsplash

Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/