What happened

• In Langflow before 1.9.0, any authenticated user can add an MCP server with 'Stdio' transport. Its command field is passed to bash -c "exec {command}" without validation [S1][S2].
• The command runs when the MCP server list is fetched. The malicious config persists and runs again every time the list loads [S1].
• Previdian honeypots logged 1,423+ exploit attempts from 27+ IPs since 2026-09-19, with a ramp from 2026-10-11 [S1].
• The observed sequence is: a version check, then /api/v1/auto_login, then login with common credentials, then a POST to the MCP server config endpoint using the bearer token [S1][S2].
• Payloads included id/whoami probes, reverse shells and Docker commands reading the host /etc/passwd. Others extracted LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD and sent them to 146.70.211[.]112:18764 [S2].

Timeline

Detect

MCP server creation or modification on Langflow · Web access / reverse proxy logs

index=* "/api/v2/mcp/servers" (http_method=POST OR method=POST OR "POST /api/v2/mcp/servers") | stats count min(_time) as first_seen max(_time) as last_seen values(status) as status values(uri_path) as uri_path by src_ip

FROM logs-* | WHERE url.path LIKE "*/api/v2/mcp/servers*" AND http.request.method == "POST" | STATS count = COUNT(*), first_seen = MIN(@timestamp), last_seen = MAX(@timestamp), status = VALUES(http.response.status_code), uri_path = VALUES(url.path) BY source.ip

A hit means: Someone added or changed an MCP server config, which is the exploit step [S1][S2]. Treat any POST from an unexpected source, or any POST outside a planned change, as suspected exploitation.

Auto-login probe followed by login from same source · Web access logs / Langflow auth logs

index=* ("/api/v1/auto_login" OR "/api/v1/login" OR "/api/v2/mcp/servers") | stats dc(uri_path) as distinct_paths values(uri_path) as paths values(status) as status count by src_ip | where distinct_paths>=2

FROM logs-* | WHERE url.path LIKE "*/api/v1/auto_login*" OR url.path LIKE "*/api/v1/login*" OR url.path LIKE "*/api/v2/mcp/servers*" | STATS distinct_paths = COUNT_DISTINCT(url.path), paths = VALUES(url.path), status = VALUES(http.response.status_code), count = COUNT(*) BY source.ip | WHERE distinct_paths >= 2

A hit means: One source walked the observed attacker sequence of auto-login, then login, then the MCP endpoint [S1]. Repeated 401s before a success suggests credential guessing.

Shell spawned through the MCP Stdio exec wrapper · EDR / Linux process execution events

index=* (process="*exec *Command failed*" OR process="*/dev/tcp/*" OR process="*LANGFLOW_SECRET_KEY*" OR process="*LANGFLOW_SUPERUSER_PASSWORD*") | stats count min(_time) as first_seen values(process) as process values(parent_process) as parent_process by dest, user

FROM logs-* | WHERE process.command_line LIKE "*exec *Command failed*" OR process.command_line LIKE "*/dev/tcp/*" OR process.command_line LIKE "*LANGFLOW_SECRET_KEY*" OR process.command_line LIKE "*LANGFLOW_SUPERUSER_PASSWORD*" | STATS count = COUNT(*), first_seen = MIN(@timestamp), process = VALUES(process.command_line), parent_process = VALUES(process.parent.command_line) BY host.name, user.name

A hit means: A command ran through Langflow's bash -c "exec ... || echo 'Command failed...'" wrapper, or a reverse shell or secret extraction ran [S2]. The wrapper string alone can be legitimate MCP use, so check what command it carried.

Traffic to reported attacker infrastructure · Firewall / proxy / network flow logs

index=* (dest_ip="146.70.211.112" OR src_ip="146.70.211.112" OR dest_ip="192.255.229.92" OR src_ip="192.255.229.92" OR dest_port=18764) | stats count min(_time) as first_seen values(dest_port) as dest_port by src_ip, dest_ip

A hit means: Contact with an IP listed in this campaign's IoCs. 146.70.211.112:18764 received stolen environment variables [S2]. The role of 192.255.229.92 is not stated.

Verify

• Pull the MCP server configs in each Langflow project and look for Stdio entries whose command or args contain bash, /dev/tcp, curl, env, docker or cat /etc/passwd [S1][S2].
• Match the POST to /api/v2/mcp/servers against the account that made it and confirm that person meant to add the server.
• Benign look-alike: developers legitimately add Stdio MCP servers (for example npx- or uvx-launched tools). These produce the same POST and the same exec wrapper.
• Benign look-alike: GET /api/v2/mcp/servers?action_count=true is normal UI traffic. It is also the request that triggers execution, so it does not separate attacker from user on its own.
• Benign look-alike: internet scanners hitting /api/v1/auto_login without any later successful login.

Scope

Affected

• Langflow versions before 1.9.0 [S2]

Only if

• The attacker can authenticate: any authenticated user can exploit it, and attackers used auto-login or common credentials [S1][S2]
• The Langflow API is reachable by the attacker [S1]

Not affected if

• Running Langflow 1.9.0 or later [S2]

Fixed in: 1.9.0 [S2]

Enumerate

• All Langflow instances, including dev, data-science and container deployments, with their versions and internet exposure
• Instances with auto-login enabled or default or weak superuser credentials
• All user accounts on each instance, and all logins since 2026-09-19
• All MCP server configs across projects, with their created-by and created-time data
• Hosts and containers running Langflow, and whether those containers have Docker socket or host filesystem access
• Secrets present in the Langflow environment, such as LANGFLOW_SECRET_KEY, the superuser password and any API keys in flows

Contain

• Remove internet exposure or put the Langflow API behind VPN or SSO now.
• Disable auto-login and enforce strong passwords [S1].
• Before changing anything, export the MCP server configs, web access logs and host process and network logs.
• Block 146.70.211.112 and 192.255.229.92, and block egress to port 18764 [S2].
• Upgrade to 1.9.0 [S2].
• Rotate LANGFLOW_SECRET_KEY, the superuser password and other secrets in the environment. Rotation cannot be undone: existing sessions and anything tied to the old key will break, so plan for it.
• Isolate any host showing reverse-shell or Docker host-access activity. Its integrity cannot be restored by patching alone.

Eradicate

• Delete malicious Stdio MCP server configs. They persist and re-execute every time the server list loads [S1].
• Kill reverse shells and remove any attacker tooling found on the host.
• Where Docker commands reached the host filesystem [S2], treat the host as compromised and rebuild it rather than clean it.
• Disable or reset accounts created or used by the attacker, and fix the weak-credential and auto-login root cause [S1].

Recover

• Confirm version 1.9.0 or later, auto-login disabled, and no unknown MCP server entries before restoring access.
• Restore from a known-good image if any shell execution was confirmed.
• Watch for continued POSTs to /api/v2/mcp/servers, logins from new sources, and use of the rotated secrets elsewhere.
• Watch for outbound connections from Langflow hosts to unexpected destinations.

Re-enter the loop when

• The vendor updates GHSA-7w94-79vh-5mr2, for example with new affected versions or a bypass of 1.9.0.
• New IoCs are published, or the role of 192.255.229.92 is clarified.
• Evidence appears of unauthenticated exploitation, or of exploitation against real deployments rather than honeypots.
• Details emerge for the other CVEs listed alongside this one.
• A hunt hit shows stolen secrets used outside Langflow.

Debrief

• Record Langflow inventory gaps, how auto-login and weak credentials were allowed, and the time from disclosure to patch.
• Record whether web logs captured the method, path, source IP and status for the MCP endpoint.
• Gap: the advisory publication date and the CVE publication date are not given.
• Gap: there is no data on real-world compromises; all counts come from honeypots.
• Gap: the attempt counts conflict (1,423+ in [S1] vs 1,800+ in [S3]).

Detection coverage — checked automatically

Checked automatically 2026-11-11 04:11Z from public sources: 12 published, 30 nothing found, 0 not machine-checkable, 3 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

Where each CVE comes from: CVE-2026-55255 — Langflow authenticated RCE (CVE-2026-105740) actively exploited via MCP Stdio transport; CVE-2026-105697 — Langflow authenticated RCE (CVE-2026-105740) actively exploited via MCP Stdio transport; CVE-2026-105740 — Langflow authenticated RCE (CVE-2026-105740) actively exploited via MCP Stdio transport. A product row answers "is the software from that story reachable from the internet", not "is this card about that software".

vuln:CVE-2026-105740

vuln:CVE-2026-105697

vuln:CVE-2026-55255

product:"Langflow"

host.services: (software.product = "Langflow")

product:"MCP"

host.services: (software.product = "MCP")

http.title:"Langflow"

http.html:"Langflow"

Internet-wide count, trend

Shodan's count of matching services on the whole internet, one point a day; the scope (your ranges) is never part of it. A count moves with Shodan's crawl as much as with patching, so read the direction, not the digit.

NVD has not published CPE configurations for these CVEs yet, so only the CVE query is exact; the product queries use the name the campaign gives (Langflow, MCP) and are replaced by NVD's spelling at the daily re-check once it names the software.

Also tried under the name the card uses, nothing matched on Shodan: http.component:"Langflow", http.component:"MCP".

Banner spellings: a model read 2 from the NVD names and this card's text (former and marketing names, console titles); 2 matched something on Shodan and are shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-11-11 04:11Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• The 2026-10-19 story [S3] is dated after the 2026-10-15 brief date, although the thread is said to be oldest first. Confirm the dates.
• [S3] is a single roundup whose cited source reportedly prints no Langflow details. Its 1,800+ figure and its claim that exploitation predated the CVE by more than two weeks are unverified.
• The behaviors block attributes the honeypot-style exploitation details (IPs, payloads) to the GitHub advisory [S2]. Confirm which source actually states them.
• The role of 192.255.229.92 is not described in the sources.
• CVE-2026-105697, CVE-2026-55255, CVE-2026-9198, CVE-2026-0768 and CVE-2026-69255 are listed without any description. Their relation to this issue is unknown.
• Is the Langflow Desktop or cloud offering affected? The sources are silent.

Sources

• [S1] https://thehackernews.com/2026/10/langflows-critical-authenticated-rce.html · The Hacker News
• [S2] https://github.com/langflow-ai/langflow/security/advisories/GHSA-7w94-79vh-5mr2 · GitHub (langflow-ai)
• [S3] https://www.securityweek.com/in-other-news-ics-sniper-attack-hacking-xworm-malware-operators-250k-chrome-exploit/ · SecurityWeek

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically; a dismissed draft unpublishes it.