AI security

The tools teams use to build AI agents and chatbots have quietly become production infrastructure, and many of them are sitting on the public internet with no login. Flowise is one of the most common. It is an open-source platform for wiring up large language model agents by dragging boxes around a canvas, and it is popular enough that thousands of instances are reachable from anywhere.

Researchers at Era Security have now shown what an attacker does once they reach one. They found a multi-stage attack framework, which they named Greeter, that uses an exposed Flowise server as a foothold and then goes looking for the cloud account underneath it. The path runs from an unauthenticated AI builder straight to the keys for your Amazon Web Services, Microsoft Azure or Google Cloud environment, so this is worth checking today if you run Flowise anywhere near the internet.

How it works

Flowise lets you build an AI agent as a flowchart. Each saved flowchart is called a chatflow: a set of connected nodes that defines how a prompt is handled, which model answers, and what tools the agent can call. You send input to a chatflow through Flowise's prediction application programming interface (API), the same HTTP endpoint the chat widget uses.

The flaw Greeter relies on is CVE-2024-58351, a critical code injection bug rated around CVSS 9.3 to 9.8 in Flowise versions before 2.1.4. It lives in the overrideConfig option, which the prediction API accepts so that a single request can adjust a chatflow's settings on the fly. Because the override is applied only while that one request runs, an attacker can smuggle code into it and have the host execute commands without ever editing the chatflow you saved. Nothing in the stored flow or the chat history changes, which is why the tampering is hard to spot after the fact.

Once the attacker can run commands on the host, the real prize is usually not the Flowise data. It is the cloud credentials that the virtual machine or container is already holding. Every major cloud provider runs an instance metadata service (IMDS), a small internal web server reachable from the machine itself at the address 169.254.169.254. It exists so that software on the instance can read its own configuration, and it also hands out the temporary access tokens tied to the instance's assigned role. Code running on the host can request those tokens over plain HTTP, with no password, and then act as the instance in the cloud account.

There is a second route to the same place. Many Flowise deployments run in Docker, and if the container can reach the Docker control socket, usually the file /var/run/docker.sock, then command execution inside the container becomes control of the Docker host. From there an attacker can start new containers, mount the host filesystem, and read anything the host can read. Greeter checks for exactly this.

What the attackers are doing

Era named the framework Greeter because it hid its commands behind innocuous chatbot-style "hello" messages sent to the prediction API, which made the traffic look like ordinary chat. Behind each greeting was a payload that ran through the overrideConfig injection described above.

Era watched the activity from July to October using seven Flowise honeypots, decoy servers it deliberately left without authentication across four regions, and reconstructed the behaviour from more than 4,000 commands. On a host it reached, Greeter first profiled the system, then checked whether it could talk to the Docker control socket, collected the process environment variables, and probed the AWS, Azure and Google Cloud metadata services in turn. The environment variables and the metadata responses are where cloud keys, database passwords and service tokens tend to live.

To size the exposure, Era scanned the internet with Shodan and found 4,372 Flowise instances reachable from outside. Of the roughly 3,277 that reported a version, 703 had no authentication at all, meaning anyone could call their prediction API directly. Era described the number of deployments that were both exposed and still vulnerable to this specific flaw as relatively small, a few dozen in its data, rather than all 703.

One caveat matters for how you read this. Era's honeypots returned fake credentials when Greeter asked the metadata service for them, so the researchers never observed a real cloud account being accessed. The framework's intent is clear from what it reached for, but the honeypot data does not prove any production environment was taken over. On a real host, the same sequence would have handed back whatever tokens the instance's role allowed.

What to do

1. Update Flowise. The fix for CVE-2024-58351 shipped in version 2.1.4, and current releases are well past that, so move to the latest supported build rather than only to 2.1.4. If you cannot update at once and you do not use overrideConfig, disable it as a stopgap.
2. Never expose Flowise to the internet without authentication. Put it behind a reverse proxy or a virtual private network (VPN), a private tunnel into your network, and require a login on the prediction API and the editor, not only on the user interface. The 703 open servers Era found were reachable because nothing sat in front of them.
3. Lock down the Docker control socket. Do not mount /var/run/docker.sock into the Flowise container, and do not run the container as root on the host. If a tool genuinely needs Docker access, broker it through a restricted proxy rather than the raw socket.
4. Move cloud instances to IMDSv2 and require the session token. The second version of the metadata service makes a caller fetch a short-lived token with a PUT request before it will answer, which blocks the blind single-request reads that Greeter depends on. On AWS, set the instance metadata options to require the token (HttpTokens set to required) and set the hop limit to 1 so a container cannot reach it. Scope each instance role to the few permissions it actually needs, so a stolen token is worth little.
5. Hunt for the behaviour already in your estate. Look for Flowise processes making outbound connections to 169.254.169.254 or to the cloud metadata hostnames, which no normal chatflow should contact. Review your prediction API access logs for overrideConfig in request bodies and for a run of short "hello" style requests from one source.
6. Rotate anything an exposed host could have read. If a Flowise instance was reachable and unpatched, treat the instance role credentials, the environment variable secrets, and any API keys stored in its chatflows as exposed, and rotate them.

The gap Greeter walks through is the same one we look for in cloud and Kubernetes security reviews and in work on AI-native systems: an internal service that was never meant to face the internet, carrying credentials for everything around it. If you are not sure which of your AI tools are reachable from outside, open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: TechTarget on the Greeter framework, Expert Insights on exposed Flowise servers, NVD entry for CVE-2024-58351, Tenable on CVE-2024-58351.