1,423 Hack Attempts in Under a Month: The Langflow Lockdown Checklist

On September 19, 2026, honeypot sensors run by the security firm Previdian started recording exploitation attempts against Langflow, the popular open-source platform for building AI workflows. By October 15, the count stood at 1,423 attempts from 27 unique attacker IPs spread across 15 countries. The spike began on October 11 with 333 attempts in a single day, and attempts were still landing as recently as this morning.

The flaw they are exploiting, CVE-2026-105740, scores 9.9 on the CVSS scale. It is an authenticated remote code execution bug affecting every Langflow version before 1.9.0. And the way it works is a lesson for far more than Langflow users.

A quick disclosure before anything else: I have not used Langflow in production, and I was not hit by this. Everything below comes from the Previdian alert, the vendor advisory, and Langflow's own documentation. I do run self-hosted services behind nginx on a small VPS, which is exactly why this story made me stop and reread my own configs. If you run any self-hosted AI tool, this checklist is for you.

How the bug works (and why it is so clean)

Langflow lets users register MCP servers in their settings. One of the transport options is "stdio", which means "run this local command and talk to it". The problem is what Langflow does with the command field. From the vendor advisory:

The user-supplied command field is passed directly to bash -c "exec {command}" with zero validation, no allowlisting, and no sandboxing.

Any authenticated user, including a non-admin, can plant a command. It fires the moment anyone fetches the MCP server list. The attack chain fits in four HTTP requests:

• Log in as a regular, non-admin user.
• POST a crafted payload to /api/v2/mcp/servers/{server_name} with a command field containing, say, a reverse shell. The server stores it with no validation.
• GET /api/v2/mcp/servers?action_count=true to trigger execution.
• Done. You now run arbitrary OS commands with the privileges of the Langflow process.

The environment field makes it worse: attackers can inject variables like LD_PRELOAD or override PATH. And the payload is sticky. It persists in project settings and re-executes every time the server list loads.

One detail from the advisory deserves its own paragraph. Unlike custom component code, which is visible when you review a flow, MCP server configs live in project settings and are invisible during normal flow review. An attacker gets a backdoor that your team literally cannot see while doing their normal work. That is a persistence trick straight out of a malware playbook, hiding inside a low-code AI tool.

What the attackers are actually doing

The honeypot data is the most interesting part, because it shows the full kill chain, and it starts somewhere boring: weak passwords.

Previdian's CEO Ryan Dewhurst described one observed sequence. The attacker first checks the Langflow version, tries /api/v1/auto_login (which returned 403 because it was disabled), then successfully authenticates using a common username and password pair. Only then do they use the resulting bearer token against the vulnerable MCP endpoint.

So the exploit requires authentication, and attackers are getting in with credential basics. The captured payloads show what they are after:

• Secret exfiltration: attempts to extract environment variables and Langflow configuration, including LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD, and transmit them to a hard-coded external server.
• Host escape probes: Docker commands trying to reach the host filesystem and read /etc/passwd.
• Reconnaissance: simple id and whoami probes to confirm execution.

A large share of the activity comes from one IP address, 192.255.229.92, repeatedly attempting environment variable extraction. The targeting is not random spraying. Someone wrote a working chain and is running it against the internet.

The lockdown checklist

Here is the part to save. If you run Langflow, or you are about to, work through this list in order. Most of it applies to any self-hosted tool that can execute code on your box.

1. Upgrade past 1.9.0, today. The fix landed in 1.9.0, and the current release line is 1.13.x, which has also picked up further security backports. If you cannot upgrade immediately, LANGFLOW_AUTO_LOGIN=false is the documented stopgap, but it does not fix this bug, it only shrinks the entry surface. Treat it as a bandage, not a cure.

2. Kill auto-login and default secrets permanently. Even after patching, LANGFLOW_AUTO_LOGIN must be false in production. Auto-login gives every visitor superuser access, which turns this RCE from "needs a stolen password" into "needs a port scan". Set a unique, non-default LANGFLOW_SECRET_KEY, since that key encrypts stored credentials and signs sessions. A minimal docker-compose block looks like this:

services:
  langflow:
    image: langflowai/langflow:latest
    environment:
      - LANGFLOW_AUTO_LOGIN=false
      - LANGFLOW_SECRET_KEY=${LANGFLOW_SECRET_KEY}  # from .env, never committed
    ports:
      - "127.0.0.1:7860:7860"   # loopback only, never 0.0.0.0

3. Never expose the port directly. Bind to loopback and put nginx or your gateway of choice in front, with its own authentication. Langflow's docs say this explicitly: authentication and tenant isolation are your responsibility at the infrastructure level, not the application's. The product itself states it does not enforce isolation between users in a single process. A basic nginx front door with an access-control layer:

location / {
    # auth_request /auth;   # validate a session at your SSO first
    proxy_pass http://127.0.0.1:7860;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
}

If a second factor sits in front of login, the honeypot attackers' playbook, "try common username and password", fails at step one.

4. Audit your logs for the indicator endpoints. Two request paths tell you whether someone has tried this on your instance: /api/v2/mcp/servers/ and /api/v1/auto_login. The second one should 403 on a healthy setup. Grep your access logs:

grep -E "api/v2/mcp/servers|auto_login" /var/log/nginx/access.log

If you find a POST to an MCP server endpoint you did not create, assume compromise, not suspicion. The payload persists, so patching alone does not remove it. You have to delete the planted server config too.

5. Review project settings for MCP servers you did not add. Because the malicious config hides in project settings rather than the flow editor, checking flows is not enough. Open the settings, list every registered MCP server, and verify each command field by hand. Anything you cannot explain, remove.

6. Rotate secrets if there is any doubt. The observed payloads go straight for LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD. If your instance was exposed unpatched, rotate both, along with any API keys your flows store, and invalidate user sessions.

7. Contain the blast radius. Run the container as a non-root user. Do not mount the Docker socket into it. Drop capabilities it does not need. Limit its network access so it cannot reach your internal services, since lateral movement was one of the documented outcomes. If the process gets popped, the attacker should land in a small cage, not on your whole VPS.

8. Give Langflow accounts only to people who need them. The bug requires an authenticated user. Every extra account is attack surface, and the honeypot data shows attackers succeed with common credential pairs. Enforce strong, unique passwords, ideally through your SSO in front of the app, so the app never sees a password at all.

The bigger lesson: MCP configs are code

Step back from Langflow for a second, because the pattern here is bigger than one product.

Every tool that lets a user register an MCP server with a "command" field is handing that user a shell. That is not inherently wrong; running local stdio servers is a legitimate and useful pattern. But it means the command field deserves the same review discipline as source code, and almost no team treats it that way.

Three rules worth adopting for any MCP-capable stack:

• Review server registrations like pull requests. A command field is executable code. Know what is registered, by whom, and why.
• Separate authorization from disclosure. Tools should perform authenticated operations without handing reusable secrets back to the model or the workflow layer. If a workflow can read your secret key, assume it eventually will.
• Never pass a user-supplied string to a shell. bash -c with zero validation, no allowlist, and no sandbox is the root cause here. Anywhere you see that trio in your own stack, you have a version of this CVE waiting.

What I would check first, if I only had five minutes

Priorities, in order: confirm your Langflow version is at or past 1.9.0, confirm LANGFLOW_AUTO_LOGIN=false, grep your logs for /api/v2/mcp/servers, then review registered MCP server configs. Everything else on the checklist can wait an hour. Those four steps close the door the attackers are actively knocking on.

One last number to keep this in perspective: 333 exploitation attempts landed on October 11 alone. Public honeypots caught 1,423 of them. Nobody knows how many unmonitored, internet-facing Langflow instances saw the same traffic and had nobody watching the logs.

---

I write about backend engineering, AI infrastructure, and security every week. Subscribe, it is free, and next week's deep dive goes to subscribers first.

Do you self-host AI workflow tools like Langflow, n8n, or Flowise? What does your lockdown setup look like, and did the honeypot numbers surprise you?

Sources: The Hacker News report on the Previdian honeypot data (October 15, 2026), the Langflow vendor advisory for CVE-2026-105740, and the official Langflow security and authentication documentation.