Flowise code injection in the Airtable Agent - CVE-2026-41265
CVE-2026-41265 is a Critical code injection flaw in Flowise, the open-source low-code builder for LLM apps and AI agents. The Airtable_Agent node uses an LLM to generate Python, and a regex-based import filter meant to block dangerous modules can be bypassed with an aliased import such as import os as pandas, giving arbitrary command execution on the server. It affects the flowise and flowise-components packages through 3.0.13 and is fixed in 3.1.0. The advisory carries two weakness classes: CWE-77 command injection and CWE-184 incomplete disallow list. This advisory covers what the bug exposes, why a low-code agent builder is an agentic-endpoint problem, and how Anomity surfaces and governs the agents that run this code.
What happened
Flowise is an open-source low-code builder for LLM apps and AI agents, distributed on npm. Users wire nodes together in a visual editor, and some of those nodes run code. The Airtable_Agent node is one of them: it uses an LLM to generate Python that operates on dataframe objects so an agent can query and transform Airtable data in natural language.
The trust boundary breaks at code generation. In the run method of the Airtable_Agents class, a regex-based filter is meant to block dangerous imports before the generated Python runs. That filter is an incomplete disallow list, which is the CWE-184 half of this advisory. An attacker who can influence the generated code can defeat the pattern with an aliased import such as import os as pandas, so a blocked module is imported under a name the regex does not flag.
The generated code then executes in a non-sandboxed Pyodide environment without proper sanitization. Once a module like os is in scope under any name, that execution context becomes arbitrary command execution and remote code execution on the server, which is the CWE-77 command injection half. Because the node runs the code as part of normal agent operation, the path from a crafted request to code on the host is short. The fix is to upgrade the flowise and flowise-components packages to 3.1.0; a denylist of import strings is not a reliable boundary.
| Detail | Value |
|---|---|
| Identifier | CVE-2026-41265 (GHSA-v38x-c887-992f) |
| Type | Code injection / RCE (CWE-77 command injection, CWE-184 incomplete disallow list) |
| Severity | Critical |
| Component | Airtable_Agent node (run method of Airtable_Agents class) |
| Affected | flowise and flowise-components through 3.0.13 |
| Fixed in | 3.1.0 |
| Root cause | Regex import filter bypassed via aliased import (import os as pandas); non-sandboxed Pyodide execution |
Why this is an agentic-endpoint risk
A low-code agent builder is not a passive tool. Flowise exists so teams can stand up AI agents quickly, and its agent nodes run generated code as a normal part of doing their job. On a managed endpoint, the Flowise process is an AI artifact in its own right, and so are the agents it builds, the CLIs that drive it, and the MCP servers those agents call. When a node like the Airtable_Agent turns an LLM's output into executable Python, code execution stops being a bug in one path and becomes an expected capability of the artifact layer.
That is what makes CVE-2026-41265 an agentic-endpoint problem rather than a single application flaw. The same class of risk shows up wherever an AI framework runs generated or serialized code, including the sibling cases in Langflow shareable playground RCE - CVE-2026-48519 and LangChain unsafe deserialization - CVE-2026-44843. These builders are nodes in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping a code-injection flaw like this one, the same way it is for securing AI coding agents and CLIs.
Network and EDR controls may see a process spawn or an outbound connection, but they cannot tell you which endpoints run an affected Flowise build, which agents use the Airtable_Agent node, or whether any of them were allowed to run generated Python. That gap is the artifact-layer blind spot we track across the supply-chain guide for defenders as well, where a trusted package quietly gains a dangerous capability.
How Anomity surfaces and governs it
Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2026-41265 that means the Flowise process and its version are catalogued alongside the agents and CLIs that drive it, so you can answer "which endpoints run flowise or flowise-components at or below 3.0.13, and what talks to them" from the fleet inventory instead of guessing.
On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that would drive an unapproved code-execution path through a low-code agent node can be denied or logged in line rather than discovered after arbitrary Python has already run on the host. Anomity collects metadata only and redacts secrets on the endpoint, so nothing the agent touches passes through Anomity in the clear.
Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents ran, on which endpoints, and when, against the affected build. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use, which is the timeline and enforcement record described under outcomes. Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them, adding the agentic-endpoint layer those tools cannot see.
What to check across your fleet
- Identify every endpoint and service running Flowise and record the exact version of the flowise and flowise-components packages; treat anything at or below 3.0.13 as affected.
- Upgrade both flowise and flowise-components to 3.1.0 or later, the release that fixes CVE-2026-41265.
- Enumerate which agent flows use the Airtable_Agent node, since that node is the path from generated Python to code execution.
- Restrict who can reach the Flowise builder and require authentication in front of it, so untrusted callers cannot influence generated code.
- Constrain the host so a Flowise agent node cannot reach internal services, cloud metadata endpoints, or secrets it has no business touching if code execution occurs.
- Review process and outbound-connection logs for unexpected child processes or egress originating from the Flowise process.
- Enumerate the AI agents, CLIs, and MCP servers that drive Flowise, using a fleet-wide AI artifact inventory.
- Confirm hook-based allow/deny/log enforcement is active on agents that drive Flowise, so an unapproved code-execution path can be blocked before it runs.
CVE-2026-41265 turns an LLM-generated query into arbitrary code on the host, because a regex denylist is not a boundary and the code runs unsandboxed, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing AI agent frameworks, and the related MCP server security guide for the servers these agents call. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.
Frequently asked questions
What is CVE-2026-41265 in Flowise?
CVE-2026-41265 is a Critical code injection flaw in Flowise, the open-source low-code builder for LLM apps and AI agents. It lives in the Airtable_Agent node, where the run method of the Airtable_Agents class uses an LLM to generate Python that operates on dataframe objects. A regex-based filter is meant to block dangerous imports, but the generated code runs in a non-sandboxed Pyodide environment without proper sanitization. The advisory tracks two weakness classes: CWE-77 command injection and CWE-184 incomplete disallow list. It affects the flowise and flowise-components packages through 3.0.13 and is fixed in 3.1.0.
How is the import filter bypassed?
The Airtable_Agent node tries to block dangerous imports with a regex-based filter, which is an incomplete disallow list (CWE-184). An attacker who can influence the generated Python can use an aliased import such as import os as pandas to slip a blocked module past the pattern. Because the code then executes in a non-sandboxed Pyodide environment without proper sanitization, that aliased import gives arbitrary command execution and remote code execution on the server. Upgrading to Flowise 3.1.0 is the fix; a denylist of import strings is not a reliable boundary on its own.
Which Flowise versions are affected and how do I fix it?
The flowise and flowise-components packages are affected through version 3.0.13, and the flaw is fixed in 3.1.0 (GHSA-v38x-c887-992f). Upgrade both packages to 3.1.0 or later. Until you upgrade, treat any Flowise instance that exposes the Airtable_Agent node as capable of running attacker-influenced Python on the host, and constrain who can reach the builder and what its agent nodes can execute. Inventory every endpoint running Flowise so you know the full blast radius before you patch.
How does Anomity help with a flaw like this?
Anomity treats a low-code agent builder as an AI artifact on the endpoint, so it inventories the Flowise process, its version, and the agents and CLIs around it. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, so a call that would launch an unapproved code-execution path can be denied or logged in line. Every decision lands in a queryable 90-day audit trail, giving responders the timeline they need to scope a code-injection event across the fleet.
