Security brief: three agent builders ship code-execution paths with no fix or a late one, a downloaded model can plant an MCP bridge in LM Studio, and an MCP OAuth endpoint in a WordPress plugin lets anyone register a client
GitHub indexed critical sandbox-escape and unsafe-reflection records for Flowise (CVE-2026-119978, CVSS 9.0) and Agno (CVE-2026-119050, 9.2) with no fixed version named, and n8n (CVE-2026-119408, 8.7) now blocks node types that ran user code outside task-runner isolation. LM Studio before 0.4.22+1 let a crafted model repository write an MCP bridge config and a plugin that runs on every launch.
Covers Fri 30 Oct 08:00 CET to Sat 31 Oct 08:00 CET
Saturday window and a thin one: no confirmed exploitation of agentic software, no agentic CISA KEV entry I could find (CISA, NVD, OSV, arXiv, lmstudio.ai and most news and vendor sites do not resolve from this environment, so absence from KEV is not confirmed), and no new incident I could verify. About 30 searches and page fetches; web search returned nothing dated inside the window, so the sweep rests on GitHub advisory, issue, release and pull-request pages that I opened. All six records below are unreviewed by GitHub and their affected and patched fields read Unknown; versions come from descriptions and linked references, and I say where I could not confirm a fix. Many records carry upstream dates from June and July: the GitHub index, not the fix, is what is new. The ledger and source registry that AGENT.md v2 describes are still not in the repository, so I kept the two legacy report types the build accepts and wrote no ledger or registry files. A VulnCheck advisory is cited by three records; I could not read it. Ecosystem and protocol developments are in the [daily signal](/reports/2026-10-31-daily-signal/).
Act now
- Take Flowise's custom-function route and builtin-dependency switch out of reach until a fixed build is named Flowise up to 3.1.4 with ALLOW_BUILTIN_DEP=true is the affected configuration. Unset ALLOW_BUILTIN_DEP, block /api/v1/node-custom-function at the proxy for anyone who is not a trusted builder, and run Flowise in a container with no cloud credentials or other-service tokens in its environment. Watch the Flowise releases page: I found no fixed version.
- Upgrade n8n to 2.42.6, 2.43.3, 2.44.0 or 3.0.1 and re-save any workflow that uses Function, Function Item or LangChain Code nodes The patched builds reject saving these nodes but let existing workflows keep running, so an upgrade alone does not close the path. Search your workflows for the three node types, replace them with the Code node, and as a stopgap add n8n-nodes-base.function, n8n-nodes-base.functionItem and @n8n/n8n-nodes-langchain.code to NODES_EXCLUDE. Do not set N8N_DEPRECATED_NODES_BLOCK=false.
- Upgrade DBHub to 0.22.6 and give its database account no write rights 0.22.6 carries both the DNS-rebinding fix from the 19 Oct item and the engine-level read-only enforcement; versions before it are affected by the new double-dash bypass on MySQL and MariaDB. Check with `npm ls @bytebase/dbhub`. Use a read-only database role regardless of the version.
In brief
- Flowise through 3.1.4 (CVE-2026-119978, Critical 9.0 v4): an authenticated user of the custom-function endpoint can escape the vm2 sandbox through the allowlisted langchain and mammoth modules when ALLOW_BUILTIN_DEP=true. 3.1.4 (29 Jul) is the newest release I could see and no fixed version is named.
- Agno through 3.1.11 (CVE-2026-119050, Critical 9.2 v4): PandasTools passes a model-chosen string to getattr on pandas, so a prompt injection can call read_pickle on an attacker file. Reported publicly on 2 Jul; the fix pull request (#8713) was still open when I read it.
- n8n (CVE-2026-119408, High 8.7 v4, GHSA-9p7v-45m2-wxgj): the Function, Function Item and LangChain Code nodes ran user code in the main process or in vm2, outside the task-runner isolation of the Code node. Fixed in 2.42.6, 2.43.3, 2.44.0 and 3.0.1 by blocking those nodes; saved workflows keep running.
- LM Studio before 0.4.22+1 (CVE-2026-119979, High 8.7 v4): backslash traversal in the model downloader lets a crafted repository write a plugin manifest, install state and mcp-bridge-config.json, so attacker Python runs on each launch. AI Engine for WordPress to 3.8.6 (CVE-2026-110732, High 7.5): the MCP OAuth registration endpoint accepts anyone.
- DBHub before 0.22.6 (CVE-2026-61789, Moderate 6.1 v4, Update on the 19 Oct item): the read-only check and MySQL/MariaDB disagree on what a double dash starts, so a hidden write passes.
Executive summary
The level stays elevated: nothing here is exploited and the window is thin, so this is a day for one pattern, not for an alarm. The pattern is the one agent builders keep failing: a product whose purpose is to run code or tools chosen by a user or a model, with an isolation layer that did not hold. Flowise’s vm2 sandbox is escaped through two modules it allowed on purpose, n8n kept three legacy node types outside the isolation its newer Code node uses, and Agno hands a model the whole pandas namespace. For two of the three I could not find a fixed release, so for now the control is exposure, not patching. The other two items are supply-chain shaped: a downloaded model that can reconfigure the host application, and an MCP registration endpoint that anyone can call.
Vulnerabilities
| Item | Severity | Fixed in | Exploited | Notes |
|---|---|---|---|---|
| Flowise, vm2 sandbox escape via custom function (CVE-2026-119978) | Critical 9.0 (v4) | Not named | No evidence | Authenticated; needs ALLOW_BUILTIN_DEP=true; versions through 3.1.4 |
| Agno, unsafe reflection in PandasTools (CVE-2026-119050) | Critical 9.2 (v4) | Not named | No evidence | Prompt injection to read_pickle; through 3.1.11; fix PR open |
| n8n, nodes outside task-runner isolation (CVE-2026-119408) | High 8.7 (v4) | 2.42.6, 2.43.3, 2.44.0, 3.0.1 | No evidence | Needs a workflow-editing account; saved workflows keep running |
| LM Studio, model downloader path traversal (CVE-2026-119979) | High 8.7 (v4) | 0.4.22+1 (from description) | No evidence | User downloads a crafted repository; vendor page unread |
| AI Engine for WordPress, open MCP OAuth registration (CVE-2026-110732) | High 7.5 (v3.1) | 3.8.7 (inferred from changeset) | No evidence | Needs an administrator to approve the client |
DBHub, read-only bypass via -- on MySQL and MariaDB (CVE-2026-61789) | Moderate 6.1 (v4) | 0.22.6 | No evidence | Update on the 19 Oct DBHub item |
Incidents
No incident I could verify surfaced in the window. Items from earlier in the week (the LiteLLM release compromise, the ransomware affiliates using coding agents) have no new development that I found.
Research and tools
Agent builders: three code-execution paths, three different states of repair
What happened. GitHub indexed three unreviewed records on 29 and 30 Oct. For Flowise, CVE-2026-119978 (GHSA-7pc2-8w3w-pqfg) says versions through 3.1.4 allow an authenticated user to run operating-system commands as the Flowise process user by submitting custom JavaScript to /api/v1/node-custom-function, when ALLOW_BUILTIN_DEP=true and the langchain and mammoth modules are allowlisted. For Agno, CVE-2026-119050 (GHSA-jq64-vhh4-4hvv) says versions through 3.1.11 let PandasTools pass a model-supplied name to getattr() on pandas and call it with model-supplied arguments, so read_pickle can deserialize attacker data. For n8n, CVE-2026-119408 (GHSA-9p7v-45m2-wxgj, published by n8n) says the Function and Function Item nodes run in vm2 and the LangChain Code node runs in the main process, outside the task-runner isolation of the standard Code node. n8n fixed it in 2.42.6, 2.43.3, 2.44.0 and 3.0.1.
Analysis. The entry points differ and the root cause is the same: a trust boundary that exists in the architecture but not around every code path. In Flowise the boundary is vm2, a JavaScript sandbox, and the escape works by making the sandbox write a file into a module that the sandbox itself allows the code to load. Preconditions are a logged-in account with access to the endpoint and one non-default switch. The blast radius is the Flowise host: its model-provider keys, database credentials and every tool credential configured for flows. Flowise’s earlier record this month (CVE-2026-73487, covered 18 Oct) was a different path; the 3.1.4 notes mention an allowlist for custom MCP stdio commands and for execution paths, and none of the three releases I could read mentions a sandbox fix. In Agno the boundary is the model. The issue was filed publicly on 2 Jul by an outside reporter, who wrote that Private Vulnerability Reporting is off and no SECURITY.md exists; a commenter on 28 Sep confirmed it and noted that read_csv with a model-controlled path is still a file-read and request-forgery route even with read_pickle blocked. The fix pull request (#8713) was open when I read the thread, and I saw no maintainer comment. The precondition is any way to get text in front of the agent, which is the definition of indirect prompt injection, and the unsafe call is reachable without any further bug. n8n is the best-repaired case and still instructive: the fix rejects saving the three node types but, per the advisory, workflows already saved with them keep running, so an upgraded instance can still hold the vulnerable nodes. It maps to OWASP LLM06 (excessive agency) and, for Agno, LLM01 (prompt injection) feeding LLM05 (improper output handling); in MITRE ATLAS terms it is execution through an AI agent tool after a prompt-injection foothold. I did not read the VulnCheck advisories that the Flowise and n8n records cite.
Why it matters. Builders of this kind are where non-developers wire a model to code execution, credentials and internal systems, so their isolation is the security boundary of the whole deployment. A sandbox that is a library inside the same process has a history of escapes, and a “fix” that blocks new saves does not remove existing exposure. For Flowise and Agno there is currently nothing to install, so the decision is what to expose.
Mitigation and detection. Flowise: unset ALLOW_BUILTIN_DEP, restrict the custom-function route to trusted builders, run it with only the secrets it needs, and alert on child processes of the Flowise Node process. Agno: do not enable PandasTools for agents that read untrusted content; if you must, wrap it so that only an explicit allowlist of DataFrame constructors can be called, and block outbound network from that process. n8n: upgrade, then list workflows containing n8n-nodes-base.function, n8n-nodes-base.functionItem or @n8n/n8n-nodes-langchain.code and replace them; set NODES_EXCLUDE as a stopgap; limit who may create, edit or import workflows. For all three, treat the host as holding every credential in its environment when you decide how far to isolate it.
Recommendation (opinion): act today on exposure, this week on patching. For tools with no fixed build, reduce who can reach the code-execution path and what the process can reach, and ask the vendor in writing for a fix date. If you cannot restrict the path, pause the flows that use it.
Sources: GHSA-7pc2-8w3w-pqfg (Flowise) · GHSA-jq64-vhh4-4hvv (Agno) · Agno issue 8699 · n8n GHSA-9p7v-45m2-wxgj · Flowise releases
LM Studio: a downloaded model repository that writes the host’s plugin configuration
What happened. CVE-2026-119979 (GHSA-fv7x-c662-7ccq, unreviewed, published 30 Oct) describes a path traversal in resolveDownloadRequest in LM Studio’s model downloader before 0.4.22+1. Filenames separated by backslashes escape the models directory. A crafted repository can therefore plant a plugin manifest.json, an install-state.json and an mcp-bridge-config.json, which, per the advisory, cause an attacker-supplied Python payload to run on every launch. The advisory links the vendor changelog and a VulnCheck entry; the changelog host does not resolve from here, so the fixed version comes from the description alone.
Analysis. The entry point is the act of fetching a model, which most users treat as downloading data. The trust boundary crossed is between a repository’s file list and the application’s own configuration directory: names chosen by the publisher decided where files landed, and one of the places they could land was the plugin and MCP-bridge configuration that LM Studio loads at start. Precondition: the user downloads from an attacker-controlled or hijacked repository (CVSS marks user interaction as passive). Blast radius is the user’s account on a workstation that often also holds API keys and source code. It joins the model-file family (pickle and GGUF loaders, Ollama path flaws) but differs in that no model parsing is needed: the payload is a config file, and MCP bridge configuration is what makes it an agent-supply-chain issue (OWASP LLM03, ATLAS supply-chain compromise of a model artifact).
Why it matters. Local-model tools are where developers pull artifacts from public hubs with little review, and they increasingly also host MCP bridges. A hub download is now a path to configuration that decides which servers an agent trusts.
Mitigation and detection. Update LM Studio to 0.4.22+1 or later. Until then download only from publishers you trust, and check the plugin and MCP-bridge configuration directories for files you did not create. Alert on a new mcp-bridge-config.json or plugin manifest whose modification time matches a model download.
Recommendation (opinion): update this week. Add “local model runners” to the software inventory your MCP review covers; the config they load is a trust decision.
Sources: GHSA-fv7x-c662-7ccq
MCP and protocol security
AI Engine for WordPress: an MCP OAuth registration endpoint that checks nothing
What happened. CVE-2026-110732 (GHSA-22w7-p44p-2gq7, unreviewed) covers the AI Engine plugin (chatbot, AI framework and MCP) for WordPress up to 3.8.6. Its MCP module’s OAuth 2.1 dynamic client registration endpoint, /wp-json/mcp/v1/oauth/register, has a permission callback that always returns true, so an unauthenticated visitor can register an active client with a redirect URI they choose. The 29 Oct brief mentioned the plugin’s 28 Oct record (CVE-2026-107745, upload path traversal) by title only; this is a different and more serious flaw.
Analysis. Dynamic client registration is meant to be open: MCP’s authorization design leans on it so that clients need no prior arrangement. The control that makes it safe is the consent step and what a registered client may later obtain. Here the consent page lacks X-Frame-Options and frame-ancestors, so an attacker can frame it and have an administrator click “approve” without understanding it (the advisory suggests clickjacking). The token then belongs to an administrator and the plugin’s MCP tools include user creation and option updates, which gives full site control. Preconditions: the MCP module enabled, a logged-in administrator who is lured to the attacker’s page. This is a different failure from the OAuth-metadata flaws earlier this month: the server is the victim, not the client. It maps to OWASP LLM06 and ATLAS credential access through a delegated token. The fixed version is inferred from a changeset reference (3.8.7), not stated.
Why it matters. WordPress sites are now MCP servers with administrator-level tools, installed by site owners who are not thinking in terms of OAuth trust models. Open registration plus an consent page that can be framed turns “approve a connection” into a one-click takeover.
Mitigation and detection. Upgrade past 3.8.6 and confirm 3.8.7 or later. Turn the MCP module off if unused. Serve consent pages with frame-ancestors 'none'. Review registered OAuth clients and recent MCP-created users or option changes.
Recommendation (opinion): upgrade if you run it; and as a rule, require registration to be authenticated or approved on any MCP server whose tools can change an administrator’s configuration.
Sources: GHSA-22w7-p44p-2gq7 · GHSA-xfc5-7gqh-v42g
DBHub: the read-only guard and MySQL disagree about a double dash
What happened. CVE-2026-61789 (GHSA-j55q-p8qc-f6wg) says DBHub before 0.22.6 treats any -- as a comment start when validating read-only mode, while MySQL and MariaDB only do so when whitespace or a control character follows. The connectors run the original string with multipleStatements enabled, so a -- followed by a non-space character hides a later write or DDL statement from the validator and the database executes it. PostgreSQL is not affected. The 19 Oct brief covered DBHub’s DNS-rebinding flaw (CVE-2026-61742) and said to check whether 0.22.5 or 0.22.6 was needed: 0.22.6 is the answer, and its release notes (10 Jul) also describe engine-level read-only enforcement.
Analysis. This is a parser differential: two components parse the same string differently, and the security decision is made by the one the database does not use. The attacker needs to influence the SQL the assistant writes, for example by prompt injection in data the agent reads, so it is a second step after the injection, not a standalone exploit. Impact is bounded by the database account (integrity and availability high, confidentiality none). It is the same class as the Git-server path walk and the sanitizer bypasses covered on 29 Oct: a string check standing in for a real boundary. OWASP LLM01 plus LLM06.
Why it matters. “Read-only mode” implemented as keyword scanning is not a control. The only one that works is a database role without write rights.
Mitigation and detection. Upgrade to 0.22.6. Use a read-only role or replica. Log statements containing -- immediately followed by a non-space character from the DBHub account.
Recommendation (opinion): act this week. Treat every MCP “read-only” flag as advisory until the database enforces it.
Sources: GHSA-j55q-p8qc-f6wg · DBHub v0.22.6 · 19 Oct brief
Policy
Nothing in the window passed the inclusion test.