CVE-2026-8447: Langflow: stored XSS in Playground chat UI

MEDIUM
Published September 4, 2026
CISO Take

IBM Langflow's Playground chat interface fails to sanitize user-supplied input before storing and rendering it, allowing an attacker to plant a persistent script payload that executes in the browser of any other user who later views the affected flow or chat history. There's no EPSS score, no CISA KEV listing, no public exploit code, and no Nuclei template for this one, and exploitation requires the victim to actively open the malicious content (UI:R) — so this isn't an actively-exploited, drive-by threat today. The real concern is blast radius rather than likelihood: Langflow's scope-changed rating (S:C) means a successful hit can reach beyond the vulnerable component into session tokens or other privileged actions inside a multi-user Langflow deployment, which is common in internal AI-agent dev teams. Confirm your Langflow version against IBM's advisory and upgrade past 1.11.2 once a fix is available; in the meantime, restrict Playground/flow-sharing access to trusted users, avoid exposing Langflow instances to untrusted external users, and add CSP headers plus output-encoding checks around chat rendering. Treat this as a low-urgency patch-cycle item rather than an emergency change.

Sources:NVDCISA KEVATLASibm.com

What is the risk?

Medium risk (CVSS 6.1). Attack complexity is low and no privileges are required to inject the payload, but successful exploitation depends on a second party opening the compromised Playground/chat view (UI:R), which limits mass exploitability. The scope-changed rating (S:C) is the notable factor: impact isn't confined to the vulnerable Langflow component itself but can extend into the browser session of whoever views the stored payload, which in a shared or internal-team Langflow deployment could mean a teammate or admin session. No EPSS data, no KEV listing, and no known public exploit or scanner coverage — real-world exploitation currently looks unlikely but not impossible given how simple stored XSS is to weaponize once discovered.

How does the attack unfold?

Malicious input injection
Attacker submits a crafted script payload via the Playground chat input or flow configuration, exploiting the lack of input sanitization (CWE-79) in this public-facing application.
AML.T0049
Stored persistence
The unsanitized payload is saved as part of the chat history or flow data, persisting until the content is viewed again.
Victim triggers execution
A second user (teammate or admin) opens the Playground or reviews the flow's chat history, causing the stored script to execute in their browser.
AML.T0011
Session/scope impact
Because the vulnerability has a changed scope (S:C), the executing script can act beyond the Playground itself — potentially stealing session tokens or performing actions against Langflow flows on the victim's behalf.

What systems are affected?

PackageEcosystemVulnerable RangePatched
Langflowpip—No patch
156.2KPushed yesterday18% patched~66d to patchFull package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1
6.1 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 23% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UIRequired
SChanged
CLow
ILow
ANone

What should I do?

1 step
  1. 1) Track IBM's advisory (linked below) for the patched release beyond 1.11.2 and upgrade as soon as it's available. 2) Until patched, restrict Playground and flow-sharing to trusted, authenticated users only — do not expose multi-tenant Langflow instances to untrusted external users. 3) Add a strict Content-Security-Policy on the Langflow web UI to blunt script execution even if a payload lands. 4) Review chat/flow content for stored <script> tags or suspicious event-handler attributes as a detection heuristic. 5) If Langflow is internet-facing, consider placing it behind an authenticated reverse proxy until patched.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF
MEASURE 2.7-AI system security and resilience evaluation
OWASP LLM Top 10
LLM05-Improper Output Handling

Frequently Asked Questions

What is CVE-2026-8447?

IBM Langflow's Playground chat interface fails to sanitize user-supplied input before storing and rendering it, allowing an attacker to plant a persistent script payload that executes in the browser of any other user who later views the affected flow or chat history. There's no EPSS score, no CISA KEV listing, no public exploit code, and no Nuclei template for this one, and exploitation requires the victim to actively open the malicious content (UI:R) — so this isn't an actively-exploited, drive-by threat today. The real concern is blast radius rather than likelihood: Langflow's scope-changed rating (S:C) means a successful hit can reach beyond the vulnerable component into session tokens or other privileged actions inside a multi-user Langflow deployment, which is common in internal AI-agent dev teams. Confirm your Langflow version against IBM's advisory and upgrade past 1.11.2 once a fix is available; in the meantime, restrict Playground/flow-sharing access to trusted users, avoid exposing Langflow instances to untrusted external users, and add CSP headers plus output-encoding checks around chat rendering. Treat this as a low-urgency patch-cycle item rather than an emergency change.

Is CVE-2026-8447 actively exploited?

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

How to fix CVE-2026-8447?

1) Track IBM's advisory (linked below) for the patched release beyond 1.11.2 and upgrade as soon as it's available. 2) Until patched, restrict Playground and flow-sharing to trusted, authenticated users only — do not expose multi-tenant Langflow instances to untrusted external users. 3) Add a strict Content-Security-Policy on the Langflow web UI to blunt script execution even if a payload lands. 4) Review chat/flow content for stored `<script>` tags or suspicious event-handler attributes as a detection heuristic. 5) If Langflow is internet-facing, consider placing it behind an authenticated reverse proxy until patched.

What systems are affected by CVE-2026-8447?

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

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

CVE-2026-8447 has a CVSS v3.1 base score of 6.1 (MEDIUM). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration platforms

MITRE ATLAS Techniques

AML.T0011User Execution
AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.11.2 suffer from a stored cross-site scripting vulnerability in the Playground chat interface.

Exploitation Scenario

An attacker with access to a shared Langflow instance (e.g., a malicious internal user, or an external user in a poorly-isolated multi-tenant setup) crafts a chat message or flow input containing a malicious script payload and submits it through the Playground. The payload is stored unsanitized. When another user — for example, a teammate reviewing the flow's output or an admin auditing chat logs — opens that Playground session, the script executes in their browser context. Given the scope change (S:C), this could allow the attacker to steal the victim's session cookies/tokens or, in Langflow's case, potentially trigger actions against flows or code-executing components the victim has access to.

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation: The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Timeline

Published
September 4, 2026
Last Modified
September 8, 2026
First Seen
September 4, 2026

Related Vulnerabilities