Langflow Has 13 New Security Flaws. Can They Expose Chat History And API Keys?

August 6, 2026

IBM disclosed 13 Langflow OSS flaws affecting versions through 1.10.3. Some can expose credentials, cross user chat history, or execute code.

Yes, under specific conditions. IBM disclosed 13 Langflow OSS vulnerabilities affecting versions 1.0.0 through 1.10.3. One can expose credentials stored in public flows without authentication, one can let authenticated users retrieve another user's chat history in certain multi-user deployments, and several can execute code. IBM recommends upgrading to Langflow 1.11.0 or newer and lists no workaround.

That does not mean every Langflow installation leaked chats or keys. Exposure depends on the version, configuration, enabled features, flow visibility, user access, and whether a vulnerable path was reached. There is also no public evidence yet that attackers exploited these 13 newly disclosed CVEs.

Why These Langflow Vulnerabilities Matter

Langflow is not only a chat interface. It is a visual AI workflow platform that can connect models, files, APIs, databases, tools, memory, and custom Python components. Its GitHub repository had more than 152,000 stars when these bulletins appeared, so a security issue can matter to a large developer and self-hosting audience.

The August 5 disclosures span several trust boundaries at once:

• credentials stored inside flows
• messages associated with chat sessions
• Python generated or supplied through components
• public and authenticated API endpoints
• filesystem paths and directories
• ownership checks between users and flows
• backend privileges inherited by executed code

This is why “Is Langflow patched?” is only the first question. Operators also need to ask which secrets may have been readable, which users could reach the server, and what the Langflow process itself was allowed to access.

What Is Confirmed

IBM published two security bulletins on August 5, 2026.

The first IBM bulletin lists seven code-execution vulnerabilities. The second IBM bulletin lists six path-traversal, credential-disclosure, authorization, cache, and filesystem vulnerabilities.

Both bulletins identify the affected range as Langflow OSS 1.0.0 through 1.10.3. Both recommend upgrading to Langflow OSS 1.11.0 or newer. Both list no workaround.

Langflow's official 1.11.0 release was published July 23 and includes multiple security-hardening changes, including tenant-isolation work, component-code protections, and forwarded fixes from the 1.10 line. Langflow 1.11.2 was the newest GitHub release when this article was published, but IBM's minimum remediated branch is 1.11.0.

The 13 CVEs At A Glance

The table deliberately preserves the conditions IBM published. A public-flow credential bug is not the same as a server-wide database dump, and an authenticated cross-user bug is not the same as anonymous internet access. But each can still be serious in the deployment where its preconditions exist.

Can The Langflow Flaws Expose API Keys?

CVE-2026-9131 can, according to IBM. The bulletin says the public-flow read endpoint failed to call the helper that removes API keys. An unauthenticated request for a flow marked PUBLIC could therefore return password-marked fields in plaintext.

IBM specifically lists:

• model-provider API keys
• webhook tokens
• cloud credentials
• database passwords

The confirmed boundary is narrower than “all Langflow secrets were public.” The vulnerable endpoint concerns credentials embedded in a flow that was marked public. A private flow that was never exposed through that path is not automatically proven compromised.

Still, the remediation cannot stop at a software upgrade if a vulnerable public flow contained live secrets. If a credential may have been returned, operators should treat it as potentially disclosed: rotate it at the provider, revoke the old value, review usage, and replace it in Langflow through the intended secret-management path.

Do not merely delete the public flow and assume the old key is safe. Deletion removes one current route to the value; it does not invalidate copies that may already exist in logs, caches, browser history, monitoring systems, or an attacker's storage.

Can The Langflow Flaws Expose Chat History?

CVE-2026-9130 can expose cross-user chat history, but only in a specific configuration described by IBM. The flaw affects multi-user deployments where LANGFLOW_AUTO_LOGIN=False. IBM says the Memory component filtered messages by session_id without also validating flow_id or user_id ownership.

An authenticated user who caused or found a session-ID collision could retrieve or store messages across another user's boundary through several run and workflow endpoints.

This distinction matters:

• authentication could establish that the requester had an account
• the vulnerable query could still fail to establish that the messages belonged to that account
• the session ID acted as a locator without being a complete authorization decision

That is a classic object-ownership problem. A random or hard-to-guess identifier can reduce accidental collisions, but guessing difficulty is not a replacement for checking the authenticated user's ownership on every read and write.

The bulletin does not say every user's complete history was exposed. It also does not publish a count of affected deployments, accounts, sessions, or messages.

Can Langflow Run Code Before A User Approves It?

CVE-2026-9196 says yes in the affected Agentic Assistant validation path. IBM says the backend executed model-generated Python during component validation before the user approved the component. That code could interact with files, make outbound network requests, or exfiltrate data with the privileges of the Langflow backend process.

This is a subtle but important approval failure. A user interface can show an approval step while the backend has already performed the dangerous part. The security boundary must surround code generation, validation, import, execution, and side effects—not only the final button click.

The consequence depends heavily on the backend's authority. Code inside a locked-down container with no secrets, no sensitive volume mounts, and restricted egress has less reach than code running with cloud credentials, writable application directories, internal-network access, and unrestricted outbound traffic.

Several other CVEs in the bundle concern custom-component code or validation bypasses. Together, they reinforce a durable rule: never assume that “generated,” “validated,” “approved,” and “executed” are the same event.

What Is Still Unclear

The bulletins establish vulnerable versions, vulnerability classes, CVSS base scores, and a fixed branch. They do not answer every operational question.

Whether Any Of The 13 Flaws Were Exploited

No public source reviewed for this article reports exploitation of these 13 newly disclosed CVEs. IBM does not provide indicators of compromise, a first-exploitation date, or an affected-customer count.

Langflow has had older vulnerabilities that received significant security attention. That history may raise operator urgency, but it is not evidence that these new CVEs were used in the same campaigns. Incident claims must identify the exact CVE, version, route, and time period before the two are connected.

How Many Internet-Exposed Instances Remain Vulnerable

The disclosures do not provide a measured population of exposed 1.0.0–1.10.3 servers. A GitHub star count is evidence of project interest, not a count of production installations or vulnerable hosts.

Which Fix Maps To Each CVE

The 1.11.0 release includes multiple security changes, but the public bulletin pages do not map every CVE to a specific commit in a way that lets an operator safely cherry-pick only one patch. IBM's supported remediation is the version boundary: 1.11.0 or newer.

Whether A Particular Deployment Leaked Data

A vulnerable version proves exposure to a code defect, not proof that someone exercised it. Determining compromise requires deployment-specific evidence such as reverse-proxy logs, Langflow audit and application logs, provider-key activity, flow visibility, authentication records, filesystem changes, container events, and outbound network telemetry.

Who Should Act Now?

You should investigate promptly if any of these describe your environment:

• Langflow OSS reports version 1.10.3 or earlier
• the server is reachable from the internet or a broad internal network
• users can create, validate, import, or run custom components
• the Agentic Assistant is enabled
• any flow containing credentials was marked public
• multiple untrusted or partially trusted users share one deployment
• Langflow can reach internal services, cloud metadata, provider APIs, or sensitive files
• the Langflow process holds reusable API keys or cloud credentials

Even a local-only server deserves an update if it opens untrusted flow files, is reachable by other machines, or runs with valuable credentials. “Self-hosted” describes who operates the server; it does not mean the software has no attack surface.

What Langflow Operators Should Do

1. Upgrade Beyond The Affected Range

Move to Langflow 1.11.0 or newer. Because 1.11.2 was current at publication, operators should normally test the newest supported 1.11.x release rather than stopping at the minimum fixed version.

Back up the database and configuration, read the 1.11 breaking changes, test representative flows, and confirm the running process—not only the package lockfile—reports the intended version.

2. Inventory Public Flows And Rotate Exposed Secrets

List every public flow and identify password-marked or secret values used by its components. For any credential that could have been returned by the vulnerable endpoint:

1. revoke or rotate it at the issuing provider
2. inspect provider-side activity and billing
3. update the secret in Langflow
4. remove embedded credentials from public flow definitions
5. re-test the public response to confirm redaction

Rotation matters more than simply renaming a key or hiding the flow.

3. Review Cross-User Message Access

If the deployment is multi-user with LANGFLOW_AUTO_LOGIN=False, inspect session IDs and message-access logs for collisions or one account retrieving sessions it did not own. Focus on the endpoints IBM named: /api/v1/run/*, /api/v1/responses, and /api/v2/workflow/*.

4. Reduce Backend Authority

Assume generated or custom code can become hostile. Run Langflow with the least operating-system, filesystem, cloud, database, and network authority it needs. Restrict outbound connections, isolate execution, avoid broad host mounts, and do not place high-value credentials in the same runtime simply because a component might use them later.

5. Confirm Authentication And Exposure Controls

Langflow's current authentication guidance warns against exposing the service directly to the internet, recommends disabling automatic login, using a non-default secret key, and placing the service behind an authenticated reverse proxy. The same guidance notes that public flows run as the flow owner and consume that owner's resources.

These controls reduce reachable attack paths, but they are not substitutes for upgrading. Several flaws in this bundle involve authenticated users, and one public-flow flaw is explicitly unauthenticated.

6. Hunt Before Deleting Evidence

Preserve relevant logs and snapshots before aggressive cleanup. Review:

• reverse-proxy and API access records
• public-flow reads
• new or unusual users and API keys
• provider dashboards for unexpected calls
• outbound connections from the Langflow runtime
• file and directory changes
• unexplained JWT invalidations
• custom-component creation and validation events
• chat-session IDs accessed by multiple users

If credible compromise evidence appears, follow your incident-response process instead of relying on an upgrade alone.

A Simple FLOW Security Check

Use FLOW to remember the four boundaries that matter after this disclosure:

• F — Fixed version: Is the running server 1.11.0 or newer?
• L — Login and least privilege: Who can reach Langflow, and what can its process reach?
• O — Object ownership: Are flows, chats, files, and caches authorized by user and tenant, not only by an identifier?
• W — Workload execution: Where can generated or custom Python run, and what side effects can occur before approval?

This framework also applies beyond Langflow. Recent Open WebUI security advisories show how version, role, enabled feature, sharing state, and network reach combine to determine real exposure. The SGLang vulnerability bundle shows a similar lesson for AI servers: a model service can become an infrastructure boundary, not merely a text-generation endpoint.

Is A Hosted AI Workspace Safer Than Self-Hosting Langflow?

Not universally. The two approaches move responsibility to different places.

A self-hosted Langflow deployment gives its operator control over hosting, network policy, models, tools, and storage. It also makes that operator responsible for patching, authentication, tenant isolation, credentials, logs, backups, and runtime containment.

A hosted AI workspace removes much of that server-operation burden, but active requests still have to be processed by the service and any necessary providers. Users must evaluate the hosted product's history, training, retention, provider, and tool boundaries instead of assuming “hosted” means private or “local” means safe.

OpenVeil is a privacy-focused hosted AI workspace, not a hosted Langflow instance or a Langflow vulnerability scanner. It keeps chat history in the browser rather than maintaining a server-side chat-history record, and it does not use prompts, uploads, generated media, selected local history, or outputs to train foundation models. Active requests are still processed by OpenVeil and necessary providers.

That makes OpenVeil a relevant option for someone who wants private AI chat, search, files, voice, image, or video tools without operating a Langflow server. It does not prove protection from these or unrelated vulnerabilities, and it does not replace a workflow builder when custom agents and integrations are the actual requirement. Readers can try ten bounded preview actions without a card, then compare the real workflow and data boundaries before choosing.

For a deeper history distinction, see what browser-local chat history means and why no server chat history does not mean no logs.

Frequently Asked Questions

Which Langflow Versions Are Affected?

IBM lists Langflow OSS 1.0.0 through 1.10.3 as affected by all 13 CVEs in the two August 5 bulletins.

Which Version Fixes The Langflow Vulnerabilities?

IBM recommends Langflow OSS 1.11.0 or newer. Langflow 1.11.2 was the newest GitHub release at publication time.

Is There A Workaround If I Cannot Upgrade?

IBM lists no workaround. Network isolation, disabling exposure, and reducing privileges can lower risk while an upgrade is prepared, but they are not vendor-supported substitutes for the fixed version.

Were Langflow API Keys Leaked?

IBM says CVE-2026-9131 could return stored API keys and other credentials from a flow marked public without authentication. The bulletin does not say that every flow or every Langflow deployment leaked credentials.

Was Langflow Chat History Exposed?

IBM says CVE-2026-9130 could let an authenticated user access another user's chat history through session-ID collisions in multi-user deployments with LANGFLOW_AUTO_LOGIN=False. No public affected-user count has been published.

Are The 13 Langflow CVEs Being Exploited?

No public evidence reviewed for this article confirms exploitation of these 13 newly disclosed vulnerabilities. Older Langflow flaws and incidents should not be presented as exploitation of this new bundle without exact evidence.

Does Enabling Authentication Solve The Problem?

No. Authentication is important, but several vulnerabilities are reachable by authenticated users, and the public-flow credential issue is unauthenticated. Upgrade first, then validate authentication, authorization, flow visibility, and runtime containment.

The Bottom Line

Langflow operators running 1.10.3 or earlier should upgrade and investigate, not panic or assume compromise. The strongest confirmed risks include unauthenticated code execution, plaintext credentials from public flows, cross-user chat-history access in a specific multi-user configuration, and generated Python running before approval.

What is not confirmed is equally important: the bulletins do not establish exploitation, a victim count, or a universal leak across all Langflow installations. Version, configuration, reachability, and evidence determine whether a vulnerable server became an incident.

Patch to 1.11.0 or newer, rotate any credential that may have lived in a public flow, review cross-user session access, and reduce the authority of generated code. Then keep the FLOW questions—fixed version, login and least privilege, object ownership, and workload execution—as ongoing operating controls rather than a one-time emergency checklist.