Langflow 1.13.0 Fixes Two Critical Flaws: One Anonymous Request Returns a Superuser Session, and the Next Step Runs Python on Your Server
If you run Langflow, check your version today. IBM's bulletin lists four new flaws in Langflow OSS 1.0.0 through 1.12.8, fixed only in 1.13.0, which was released October 22. The two critical ones, CVE-2026-93680 and CVE-2026-110186, both rated 9.8, chain into unauthenticated code execution on the server. Nothing in the sources we read reports exploitation, and none of the four is in CISA's Known Exploited Vulnerabilities catalog as of October 30. Langflow has a history that argues against waiting.
The four CVEs
The details come from a write-up by Ostorlab that reconstructs the flaws from IBM's bulletin, the CVE records and Langflow's source code. IBM's bulletin is dated October 28 and was updated October 29.
- CVE-2026-93680, 9.8: an authentication bypass. Automatic login is on by default in every affected release, and an anonymous request to the auto_login endpoint returns a superuser session, with access-token, refresh-token and API-key cookies set. Ostorlab says an earlier fix, advisory GHSA-fjgc-vj2f-77hm, shortened the token's lifetime but still issued superuser sessions to anonymous callers.
- CVE-2026-110186, 9.8: code execution through the MCP endpoint. A caller holding that superuser session connects to the MCP endpoint, lists the exposed tools, and creates a flow containing a custom component. Custom components are Python code, and Langflow runs them on the server with the permissions of the Langflow process.
- CVE-2026-110193, 8.8: a low-privileged user can get operating system commands run through the Agentic Assistant by prompting it to produce component code that gets past its code scanning.
- CVE-2026-110192, 6.5: sensitive information exposure through insufficiently protected credentials.
Is it being exploited?
The sources disagree, so we are not choosing. Ostorlab says no public proof of concept exists and no exploitation has been reported. A search summary of two other pages claimed public attack code already exists, and we did not open those pages. Treat the chain as easy to build, because the whole path is described in public and each step uses a feature that is on by default.
The history matters more than the disagreement. By our count CISA's catalog already lists Langflow six times: CVE-2025-3248, CVE-2025-34291, CVE-2026-33017, CVE-2026-55255, CVE-2026-0770 and CVE-2026-9198. We wrote about the fifth in July. In March, The Hacker News reported attacks on CVE-2026-33017 within 20 hours of its disclosure.
What to do
- Upgrade to 1.13.0. Back up the database, the secret key and uploaded files first. If you use automatic login today, set up an account for password sign-in before you upgrade or you may be locked out.
- Do not set LANGFLOW_AUTO_LOGIN to true afterward. That reopens the endpoint, per Ostorlab.
- Check your own instance. Ostorlab says a 403 from the auto_login endpoint means automatic login is off, and a 200 means the bypass is open. Test only an instance you own, because a 200 hands back a working superuser session.
- Until you can upgrade, remove untrusted network access to the instance. That closes the unauthenticated chain but not CVE-2026-110193, and IBM lists no workarounds.
- Look back. IBM published no indicators of compromise. Ostorlab suggests searching access logs for requests to the auto_login endpoint from addresses that are not your own checks, reviewing flows created or modified during the exposure window, especially custom components nobody on your team can account for, and checking for accounts, API keys or client registrations created around the same time.
What we do about it, and what we cannot
We are not a news site, so here is where we stand, as of this writing.
- Our edge has seen almost none of it. Since October 1 our edge scan finds one blocked request to the auto_login path, on October 21 at 20:56 UTC, from one address in a cloud provider's range, the day before the fix shipped. That path has existed in Langflow for a long time, so a single request looks like exposure scanning, not this chain. We saw no canary hits and no origin hits. Over the same window the edge blocked 46 requests to the older Langflow exploit paths, the last on October 21. That covers our own web properties only. Your Langflow server is not behind our edge.
- There are no indicators to block. IBM published none, and a search of our indicator index for CVE-2026-93680 returned no record. If exploitation is reported with infrastructure, we ingest it the same day and add a dated update here.
- We watch the catalog. Our corpus syncs the KEV list daily, and none of these four is listed today.
Free API keys for our blocklist feed are open to anyone, and the day indicators exist, they are the first thing to go in.
Limits
The CVE details, versions and dates come from Ostorlab's write-up of IBM's bulletin. We did not read IBM's bulletin or Langflow's advisories ourselves, and we did not run any exploit step. IBM's bulletin lists four CVEs while another source we saw lists a different affected-version baseline, so confirm the range with IBM before relying on it.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.