When model output becomes code: three agent framework advisories from October

In the first two weeks of October 2026, three popular open-source agent frameworks published fixes for the same kind of flaw: text an attacker could influence reached a model, the model wrote code, and the framework ran that code with far more access than it should have had. Flowise, Langflow and PraisonAI are different products, but the advisories read like variations on one theme. Any team building internal agents that generate and run code should check whether it has made the same design choice.

What was disclosed

Flowise: a blocklist that could be bypassed

The advisory GHSA-w7x8-q2gp-5cgg (CVE-2026-73487), published on 7 October, affects Flowise 3.1.2 and earlier and is fixed in 3.1.3. Its CSV Agent and Airtable Agent nodes asked a model to write Python to analyse data, then checked that code with a regular-expression blocklist before running it in Pyodide. The advisory says the validator "has multiple structural bypasses", which led to prompt injection turning into remote code execution and server-side request forgery. It is rated critical (CVSS 4.0 score 9.0).

Langflow: a generated lambda

CVE-2026-7700, listed on 5 October, affects Langflow 1.3.0 to 1.10.2 and is fixed in 1.10.3. The Smart Transform component puts a flow author's instructions and a preview of its input data into a prompt asking a model to write a Python lambda, then runs it. Because the input data is part of the prompt, whoever controls the data can steer the code that is generated. It is rated high (CVSS 3.1 score 8.8).

PraisonAI: no sandbox at all

The advisory GHSA-2xv2-w8cq-5gxw (CVE-2026-61447), published on 8 October and fixed in praisonaiagents 1.6.78, is the starkest. It says the CodeAgent ran model-generated Python in a subprocess "with the complete parent-process environment", with no validation, no import restrictions and no sandbox. Any secret in the environment, such as API keys or cloud credentials, was available to the generated code. It is rated critical (CVSS 3.1 score 10.0).

Analysis: the shared mistake

Each framework treated model output as if it were code written by the developer. It isn't. A model's output is shaped by everything in its context, and in all three cases that context included data the attacker could influence: a CSV file, an Airtable record, a data preview.

Three lessons follow.

Filtering generated code doesn't work as a security boundary. The Flowise validator tried to recognise dangerous Python with patterns. Python offers too many ways to reach the same capability, and a model asked to be helpful will find them. Blocklists can reduce accidents; they don't stop someone trying.

The environment is part of the attack surface. PraisonAI's generated code inherited every environment variable. Developers routinely run agents with tokens in the environment because that is how SDKs pick them up. Code generated inside that process should get none of them by default.

Data is an instruction channel. Langflow's component was designed to transform data, and the data was what steered it. Any agent that reads files, tickets, web pages or records has the same exposure, whether or not it runs code. When it does run code, the consequence is execution.

What is not new

Prompt injection itself is well known. What these advisories add is evidence that it is now routinely becoming code execution in real frameworks, rated high or critical, with ordinary data as the entry point. The fix in each case is also ordinary: isolate execution, drop privileges, and stop trusting a filter to judge intent.

What it means for engineering and security leaders

Internal agent projects often start in a low-code framework or a quick script, then quietly gain access to production data and credentials. The October advisories are a prompt to find those projects and ask three questions: does any component run model-generated code, what can that code reach, and where does the model's input come from?

The same questions apply to AI coding tools on developers' computers. A coding agent that runs commands is a code-generating system whose input includes repository files, issues and documentation. The difference is that coding tools increasingly ship with OS-level sandboxes and approval flows, while many agent frameworks and internal scripts don't.

Practical takeaways for this week

• Upgrade: Flowise to 3.1.3 or later, Langflow to 1.10.3 or later, and praisonaiagents to 1.6.78 or later.
• Search internal projects for components that execute model output: eval, exec, subprocess calls, notebook kernels and "code interpreter" nodes.
• Run any generated code in an isolated sandbox with no network by default, no access to the host filesystem, and an empty environment. Pass in only what the task needs.
• Treat every data source an agent reads as untrusted input, including your own databases and documents.
• Remove long-lived secrets from the environment of agent processes. Prefer credentials that are scoped, short-lived and held outside the process.
• Log which agent ran which code, with what result, so you can tell afterwards whether a vulnerable path was used.

Where SpanDock fits

On the Enterprise plan, SpanDock guardrails check the prompt and every tool call in Claude Code, Codex and Gemini CLI before it runs, and MCP tool calls through the gateway, and can block, warn, confirm or redact secrets, personal data and your own patterns. That is where they are enforced, so for agent frameworks running on your servers the isolation steps above still apply.