A single rigged document can turn Langflow's file reader into full server takeover

If you run Langflow to build AI apps, and any node in your flows reads files that users can influence, treat this as today's work. A newly published advisory lays out how one crafted document, dropped into a retrieval-augmented generation (RAG) pipeline, can read any file on the server and then escalate to full remote code execution (RCE). The flaw is tracked as CVE-2026-55447 and rated CVSS 9.6.

The patch itself is not new. It shipped in Langflow 1.9.2 on May 1, 2026. What changed on June 19 is that the complete exploit chain went public. Anyone still pinned below 1.9.2 has been exposed for weeks, and the method is now documented for everyone, including attackers.

What an attacker gets from CVE-2026-55447

CVE-2026-55447 lets someone who can get a file into a Langflow file-reading node read any file on the host by absolute path, then turn that read into code execution. The weakness lives in BaseFileComponent, the shared base class behind six nodes: Read File, Video File, the two Docling document parsers, NVIDIA Retriever Extraction, and the Unstructured API component. Any flow built on one of them is in scope.

The mechanics are a classic archive-extraction trap. When one of these nodes ingests a tar archive, the _unpack_bundle function in base_file.py extracts it without checking what kind of members the archive holds. A tar file can carry a symbolic link, a pointer to another path on disk. The extractor preserved that link, and the next processing step followed it, returning the contents of whatever absolute path it aimed at. Ori Lahav, a security researcher at Rubrik, reported the chain alongside a finder credited as vbCrLf.

Why a file read turns into full code execution

The danger is not the file read on its own. It is what becomes reachable once you can read one specific file. The advisory walks the chain end to end:

• Upload an archive whose symlink points at Langflow's secret_key file, the secret used to sign JSON Web Tokens (JWTs).

• Ask the chatbot to return the ingested content, which now includes that secret.

• Use the secret to forge a valid token for any user ID, walking past authentication.

• Create a flow with the built-in Python Interpreter node and run arbitrary code.

That last step is the part worth sitting with. Langflow ships a node whose entire purpose is to execute code. Once authentication is defeated, code execution is a feature, not a bug. A single confidentiality flaw, reading one file, collapses into a full takeover because the application trusts its own filesystem and hands a code-running primitive to any authenticated user. The CVSS vector says the same thing in shorthand: no privileges needed, but the attacker does need a file they control to reach one of those nodes, so this is not a zero-click bug against an idle install. It is a near-certainty against any RAG deployment that ingests documents from people you do not fully trust.

Your retrieval pipeline is an untrusted file-parsing surface

The wider lesson outlives this one CVE. In a RAG system, every document you ingest is attacker-influenced input, the same as a web request body or an uploaded avatar. The moment users can feed files into a flow, your file parsers, your archive handlers, and your text extractors are all part of the attack surface. Symlink-following during archive extraction is a decades-old class of bug, sometimes called a tar-slip, and it keeps reappearing wherever code unpacks an archive into a working directory and then reads from it.

This is the same shape we keep seeing as AI features get bolted onto existing apps: a powerful new input channel meets old, trusting code. We wrote about a related door in Microsoft 365 Copilot, where prompt injection reopened old bugs. The pattern is consistent. The AI layer is rarely the weak point by itself; it is the new, wide pipe that delivers untrusted content straight into machinery that was never hardened for it.

Langflow keeps shipping the same class of bug

This is not Langflow's first critical flaw this year, and the through-line matters more than any single CVE. In a separate recent flaw, any logged-in user could run another user's flow because an endpoint never checked ownership. Different bug, same root posture: Langflow tends to trust its own runtime, its filesystem, its flow execution, and its user model, while exposing all of it to inputs it does not control. When the product whose job is to run user-built automation also ships a code-execution node and stores its signing secret on the same disk it reads from, the blast radius of any file-read bug is enormous by design.

What to do now

• Upgrade to Langflow 1.9.2 or later. Version 1.10.0, released June 9, 2026, is current and the safest target.

• Keep Langflow off the public internet and away from untrusted users. The exploit needs a file the attacker controls to reach a file-reading node, so restricting who can submit documents shrinks the risk sharply.

• Rotate the secret_key if you ran an exposed version. A token forged from a leaked secret survives an upgrade, so patching alone does not evict an attacker who already has the key.

• Remove or restrict the Python Interpreter node in flows that do not need it. It is the final link in the chain and rarely belongs in a production, user-facing deployment.

• Watch for archive uploads containing symlinks and for unexpected reads of the secret file. File integrity monitoring on the Langflow host, the kind Wazuh provides as the detection engine under Suriq, will flag access to that path.

The timing is the uncomfortable part. This was patched almost seven weeks ago and disclosed yesterday. For teams that stayed current, there is nothing to do. For teams that pinned an old version and left a RAG pipeline open to outside documents, the window did not just close. It opened.