CVE-2026-81268: Langflow stale API keys survive user

CISO Take

IBM Langflow OSS (versions 1.0.0 through 1.11.5) fails to expire API keys when a user account is deactivated, letting an already-authenticated but supposedly offboarded user keep executing flows and pulling sensitive information from the platform. It's a low-complexity, network-exploitable flaw (CVSS 8.1, AV:N/AC:L/PR:L/UI:N) requiring only low privileges and no user interaction, which makes it a textbook offboarding-gap issue rather than a novel exploitation technique — no public PoC, no Nuclei template exist, and it isn't in CISA KEV, so this reads as an identity-hygiene risk rather than an active-exploitation emergency. For any org running Langflow as an agent-orchestration layer, a departed employee, contractor, or compromised low-privilege account effectively retains standing access to build and run flows against production data and connected tools until the key is manually revoked. Patch to a fixed release above 1.11.5 as soon as IBM ships one, and in the interim treat API key revocation as a mandatory, verified step in offboarding rather than assuming deactivation alone is sufficient — audit currently active Langflow API keys against your employee/contractor roster now.

Sources: NVD ATLAS

What is the risk?

High-severity, high-confidence risk. Exploitability is straightforward: no user interaction, low attack complexity, and only low privileges are needed (an account that has since been deactivated but whose API key remains valid). The impact is confidentiality-heavy (C:H) with integrity impact (I:H, since flows can be executed) but no direct availability impact (A:N). There's no evidence of active exploitation (not in CISA KEV, no SSVC decision, no EPSS score available, no public exploit or scanner template), so this should be prioritized based on internal exposure — specifically, how many deactivated accounts still have live API keys — rather than external threat signals. The core issue is an identity/session-management gap (CWE-613, insufficient session expiration) rather than a memory-safety or injection bug, which means detection and mitigation lean on access-governance controls more than technical hardening.

How does the attack unfold?

Initial Access

Attacker authenticates to the Langflow API using a previously issued API key belonging to a now-deactivated user account.

AML.T0012

Exploitation

Because the platform does not tie API key validity to account status, the stale key is accepted despite the user being deactivated.

Data Access via Flow Execution

Attacker enumerates and executes existing Langflow flows, invoking connected tools and data sources the deactivated user previously had access to.

AML.T0053

Impact

Sensitive information surfaced by flow execution (RAG results, connector outputs, internal data) is exposed to the unauthorized party.

AML.T0024

Initial Access

Attacker authenticates to the Langflow API using a previously issued API key belonging to a now-deactivated user account.

AML.T0012

Exploitation

Because the platform does not tie API key validity to account status, the stale key is accepted despite the user being deactivated.

Data Access via Flow Execution

Attacker enumerates and executes existing Langflow flows, invoking connected tools and data sources the deactivated user previously had access to.

AML.T0053

Impact

Sensitive information surfaced by flow execution (RAG results, connector outputs, internal data) is exposed to the unauthorized party.

AML.T0024

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
154.7K Pushed 7d ago 17% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 24% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

1 step

1) Upgrade Langflow to the first version released after 1.11.5 once IBM publishes a fix (track https://www.ibm.com/support/pages/node/7286662). 2) Until patched, treat API key revocation as an explicit, separate step from account deactivation in your offboarding runbook — deactivating the user account does not invalidate its keys. 3) Audit all currently active Langflow API keys and cross-reference against active employee/contractor status; revoke any orphaned keys immediately. 4) Where supported, reduce API key lifetime/TTL and rotate keys periodically rather than relying on indefinite validity. 5) For detection, monitor Langflow flow-execution logs for activity tied to API keys belonging to recently deactivated accounts, and alert on any such usage as a high-confidence indicator of this exposure being actively leveraged.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Framework Agent API AML.T0012 - Valid Accounts AML.T0024 - Exfiltration via AI Inference API AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.3 - AI system access control

NIST AI RMF

GOVERN 1.5 - Ongoing monitoring and periodic review of policies and procedures for managing AI risks

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-81268?

IBM Langflow OSS (versions 1.0.0 through 1.11.5) fails to expire API keys when a user account is deactivated, letting an already-authenticated but supposedly offboarded user keep executing flows and pulling sensitive information from the platform. It's a low-complexity, network-exploitable flaw (CVSS 8.1, AV:N/AC:L/PR:L/UI:N) requiring only low privileges and no user interaction, which makes it a textbook offboarding-gap issue rather than a novel exploitation technique — no public PoC, no Nuclei template exist, and it isn't in CISA KEV, so this reads as an identity-hygiene risk rather than an active-exploitation emergency. For any org running Langflow as an agent-orchestration layer, a departed employee, contractor, or compromised low-privilege account effectively retains standing access to build and run flows against production data and connected tools until the key is manually revoked. Patch to a fixed release above 1.11.5 as soon as IBM ships one, and in the interim treat API key revocation as a mandatory, verified step in offboarding rather than assuming deactivation alone is sufficient — audit currently active Langflow API keys against your employee/contractor roster now.

Is CVE-2026-81268 actively exploited?

No confirmed active exploitation of CVE-2026-81268 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-81268?

1) Upgrade Langflow to the first version released after 1.11.5 once IBM publishes a fix (track https://www.ibm.com/support/pages/node/7286662). 2) Until patched, treat API key revocation as an explicit, separate step from account deactivation in your offboarding runbook — deactivating the user account does not invalidate its keys. 3) Audit all currently active Langflow API keys and cross-reference against active employee/contractor status; revoke any orphaned keys immediately. 4) Where supported, reduce API key lifetime/TTL and rotate keys periodically rather than relying on indefinite validity. 5) For detection, monitor Langflow flow-execution logs for activity tied to API keys belonging to recently deactivated accounts, and alert on any such usage as a high-confidence indicator of this exposure being actively leveraged.

What systems are affected by CVE-2026-81268?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, LLM orchestration platforms.

What is the CVSS score for CVE-2026-81268?

CVE-2026-81268 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.31%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesLLM orchestration platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0024 Exfiltration via AI Inference API

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

ISO 42001: A.6.2.3

NIST AI RMF: GOVERN 1.5

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute flows and obtain sensitive information due to insufficient session expiration of API keys after user deactivation.

Exploitation Scenario

A contractor with Langflow access is offboarded and their user account is deactivated in the identity system, but their previously issued Langflow API key is never explicitly revoked because the platform doesn't tie key validity to account status. Weeks later, the former contractor (or an attacker who obtained the leaked key, e.g., from a code repo or laptop) uses the still-valid API key to authenticate directly against the Langflow API, bypassing the deactivated account's normal login path entirely. They enumerate and execute existing flows — which may include RAG pipelines querying internal knowledge bases or agents with tool access to internal systems — and exfiltrate the sensitive outputs, all while appearing to security monitoring as legitimate API-key-authenticated traffic rather than an anomalous login.

Weaknesses (CWE)

CWE-613 Insufficient Session Expiration Primary CWE-613 Insufficient Session Expiration

CWE-613 — Insufficient Session Expiration: According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."