Short answer: in the space of a fortnight, three popular open-source AI agent frameworks published security advisories with the same shape. Langflow, fast-agent and AgentScope each had a way for someone on the network, with no account, to reach the agent's tools and, in the worst cases, run commands on the server. The common thread is not clever AI trickery. It is convenience defaults: automatic login, servers listening on every network interface, no authentication on the Model Context Protocol (MCP) endpoint, and shell tools switched on in the quickstart. If your teams are building agents on cloud servers, treat every agent server as an internet-facing application holding your keys, because that is what it is.

I think this is the AI era's version of the open storage bucket, and I want to set out why, and what I would check this week.

What was disclosed

Langflow. IBM, which handles vulnerability reports for the low-code agent builder, published a security bulletin on 28 October 2026, updated the next day, covering Langflow OSS 1.0.0 to 1.12.8. Two flaws are rated 9.8 and need no account: CVE-2026-93680, an authentication bypass that IBM describes as an incomplete remediation of an auto-login security control, and CVE-2026-110186, which IBM describes as unauthenticated remote code execution exploitable through MCP tool enumeration. A third (CVE-2026-110193, rated 8.8) lets a low-privileged user make the built-in Agentic Assistant produce code that runs operating system commands, and a fourth (CVE-2026-110192) exposes API credentials. The fix is version 1.13.0, and IBM lists no workaround.

The Hacker News reported on 2 November that automatic login, which signs users in as a superuser without a password prompt, was enabled by default in 1.12.8 (1.13 turns it off), and that a public Metasploit module already cites the authentication bypass: it connects to a Langflow MCP endpoint without credentials and lists the tools on offer. Neither critical flaw was in CISA's Known Exploited Vulnerabilities catalogue as of its 30 October update, but six earlier Langflow flaws are. CSO Online notes that Langflow vulnerabilities have been exploited before to steal AI and developer credentials, most recently in August.

fast-agent. On 9 November, an advisory for the fast-agent framework (CVE-2026-102610) showed that its serve command publishes an agent as an MCP server over HTTP, bound to all network interfaces on port 8000, with no authentication and no warning. With the --shell flag, which appears in the project's own quickstart, the agent has a local shell tool. The reporter sent one plain-language message from an unauthenticated client asking the agent to run a command; the agent did so and returned the output, running as root in the test container. Versions up to 0.7.20 are affected and 0.7.21 is the patched release. GitHub rates it medium (6.4) because of the preconditions.

AgentScope. On 5 November, CVE-2026-123022 was published for AgentScope up to 2.0.11: the MCP Workspace API passes an attacker-supplied command value into a system process call, the attack can be launched remotely, an exploit is public, and at the time of the advisory the fix was still a pull request awaiting acceptance.

My view: these are configuration failures wearing an AI badge

None of these advisories needs a jailbreak or a poisoned document. They need a server that answers anyone who connects. That is why I compare them with the open storage bucket. Buckets were not insecure by design; they became a headline problem because the easy path, for people moving quickly, left data reachable by anyone. Agent frameworks are now at the same stage. Their quickstarts are optimised for the first ten minutes: run one command, open a port, talk to your agent. Nobody wants a login screen during a demo.

The protocol authors saw this coming. The MCP specification's transport section says servers must validate the Origin header, should bind only to localhost (127.0.0.1) rather than all interfaces (0.0.0.0) when running locally, and should implement proper authentication for all connections. The fast-agent advisory is, in effect, a list of those three lines not being followed by default.

The problem is what happens next in a real organisation. A developer runs the quickstart on a cloud virtual machine or a container platform so a colleague can try it. A security group or firewall rule is opened "temporarily". The agent is given a model API key, a database connection and perhaps a cloud credential so it can do something useful. Weeks later the experiment is still running, nobody owns it, and it is reachable from the internet.

Why the blast radius is bigger than a normal web app

An exposed web app usually gives an attacker that app. An exposed agent server gives an attacker everything the agent can reach. The fast-agent advisory puts it plainly: even without the shell tool, an unauthenticated caller gets use of the operator's language model and of any other MCP servers the agent is connected to. Agent servers tend to hold exactly the secrets attackers want: model provider keys (which cost real money when abused), tokens for connected SaaS tools, and cloud credentials. One of the Langflow flaws is specifically about API credentials being exposed.

Severity scores can also mislead. fast-agent's medium rating reflects that the shell flag and the serve command must both be in use. I understand the scoring logic, but those preconditions describe exactly how the project's own quickstart is run. Score the flaw against how your teams actually deploy the tool, not against the most cautious configuration.

Eight checks I would run this week

  1. Find every agent server. Ask engineering, data and innovation teams directly, and look in your cloud accounts for virtual machines, containers and serverless services running agent frameworks or MCP servers. Unsanctioned experiments count; our guide to finding shadow AI covers how to surface them without starting a witch-hunt.
  2. Patch the named tools now. Move Langflow to 1.13.0 (back up the database, secret key and uploaded files first, as IBM advises) and fast-agent to 0.7.21. For AgentScope, check whether the fix has landed for your version; until it has, keep the workspace API off any shared network.
  3. Close inbound access. Review firewall rules and cloud security groups for anything open to the whole internet on ports used by agent tools, such as fast-agent's default 8000. Blocking unauthenticated inbound connections by default is also a basic Cyber Essentials expectation, so an exposed agent server undermines one of the most basic controls that scheme checks.
  4. Bind to localhost and put authentication in front. Agent and MCP servers should listen on 127.0.0.1 unless there is a reason not to. Where remote access is needed, put the server behind private networking or an authenticating proxy, and require authentication on every MCP connection, as the specification recommends.
  5. Switch off development conveniences. Automatic login, default admin accounts and "no auth" modes belong on a laptop, not on a shared server. Make this part of your build checklist, not a clean-up task.
  6. Treat shell and code tools as privileged. If an agent can run commands or write code that executes, run it in a sandboxed container as a non-root user with no access to the host or to credentials it does not need. Do not enable shell tools on any server that accepts remote connections.
  7. Scope and rotate the secrets. Give each agent its own model API key with a spending limit, short-lived and least-privilege cloud credentials, and read-only access wherever possible. If any affected server was reachable from the internet, assume its secrets are compromised: rotate them and review provider usage and cloud logs for activity you cannot explain.
  8. Keep evidence that the fix stayed fixed. Record which agent servers exist, who owns them, which network rules apply and which identities they use, then recheck on a schedule. Configuration has a habit of drifting back, as we cover in fixing cloud misconfigurations and proving they stay fixed.

Where this fits with the rest of AI security

Last week I wrote about hidden prompt injection aimed at AI email assistants, where the attacker has to persuade a model to misuse its permissions. These advisories are the blunter cousin: if the agent's server is open, the attacker does not need to persuade anything. Both lead to the same discipline. Decide what each agent is allowed to reach, enforce that in infrastructure rather than in prompts, and be able to show it. The OWASP Top 10 for Agentic Applications and the NCSC's guidelines for secure AI system development are both good frameworks for turning that discipline into a standard your teams can follow.

For the cloud side, PyraLink™ Prove uses read-only access to AWS, Azure and Google Cloud to collect configuration evidence mapped to ISO 27001, SOC 2 and Cyber Essentials controls, so you can see and show how your environment is set up. You can read more about PyraLink™ Prove here.

What to tell your board

Keep it to three sentences. Several popular AI agent tools shipped with defaults that let anyone on the network use them, and in some cases run commands on the server. We have found every agent server we run, patched or isolated the affected ones, and rotated any keys that could have been exposed. From now on, no agent server goes live without authentication, a named owner and a recorded network rule.

Agent frameworks are moving fast, and that is mostly good news. But speed is exactly when defaults matter most. The organisations that avoid the next headline will be the ones that treated their first agent server like any other production system, not like a demo.

Frequently asked questions

What is an MCP server?

The Model Context Protocol (MCP) is a standard way for AI applications and agents to offer and use tools, such as running a search, reading files or calling an API. An MCP server exposes those tools. If it accepts connections without authentication, anyone who can reach it can call its tools.

Which versions fix the Langflow and fast-agent flaws?

IBM's bulletin names Langflow 1.13.0 as the fix for versions 1.0.0 to 1.12.8. The fast-agent advisory lists 0.7.21 as the first patched version. At the time of its 5 November advisory, the AgentScope fix was still awaiting acceptance.

Are these flaws being exploited?

As of the reporting cited here, the two critical Langflow flaws were not in CISA's Known Exploited Vulnerabilities catalogue, although a public Metasploit module cites the authentication bypass, and earlier Langflow flaws have been exploited. Treat any affected server that was reachable from the internet as potentially compromised.

We only run agents for internal testing. Are we at risk?

Possibly. Test servers on cloud platforms are often reachable from the internet through a temporary firewall rule, and they frequently hold real API keys and credentials. Check the network rules and the secrets, not just the label.

Does binding to localhost make an agent server safe?

It removes remote network exposure, which is the biggest risk in these advisories, but it is not enough on its own. The MCP specification also asks servers to validate the Origin header to prevent DNS rebinding attacks, and to authenticate connections.

Sources