GHSA-ccv6-r384-xp75 is a critical-severity (CVSS 9.6) CWE-61 vulnerability in langflow. O3 Security confirms whether GHSA-ccv6-r384-xp75 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Langflow: BaseFileComponent-based nodes arbitrary file read with RCE exploit
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-ccv6-r384-xp75.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-ccv6-r384-xp75 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
langflowReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
All components based on BaseFileComponent are vulnerable to the following vulnerability:
- Docling (
DoclingInlineComponent) - Docling Serve (
DoclingRemoteComponent) - Read File (
FileComponent) - NVIDIA Retriever Extraction (
NvidiaIngestComponent) - Video File (
VideoFileComponent) - Unstructured API (
UnstructuredComponent)
For clarity, from now on I'll only refer to Read File component.
The Read File node processes user-controlled files. Example scenario is a RAG chatbot - a system that allows users of an organization to ask questions about documents saved in the organizations.
By controlling a files that are digested into the RAG, an attacker can direct the node to read any file on the file-system by absolute path.
Using this vulnerability an attacker can acheive RCE:
- Upload a file that directs the node to read Langflow's
secret_keyfile containing the JWT token secret. - This would allow the attacker then to simply task the Chatbot for the JWT secret.
- Using this secret, the attacker then crafts a JWT token for any user-id, bypassing authentication.
- Code execution is then trivial - simply create a new flow with "Python Interpreter" node, fill it with arbitrary Python code and execute it.
Tested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe
Details
The vulnerability is in:
langflow/src/lfx/src/lfx/base/data/base_file.py
Specifically in _unpack_bundle. This function extracts tar files, which can contain a symlink.
This symlink can point to any file in the filesystem. Then, in self.process_files(), the file pointed by the symlink will be parsed and saved into the RAG.
This can be done with unlimited number of symlinks in the same tar which can also be useful in some scenarios.
Suggestd fix - iterate over the files and make sure all are regular files or directories.
PoC
Reproduction:
- Create a flow with Read File (or any other affected components), and connect its output to some storage such as Chroma DB.
- Create a symlink pointing to any file. For the above exploit, point the symlink to langflow's JWT token file.
- Compress this symlink with tar.
- Upload it to the Read File component.
- Check the database, or ask a Chatbot connected to this vector database for the contents of the file.
Concrete PoC:
- Flow with RAG ingestion and a Chatbot around it: Vector Store RAG.json
- Exploit tar: archive.tar.txt (remove .txt, GitHub blocked .tar)
- Create a file
/tmp/trip.docxwith any contents in it - Ingest the file in the flow above, and ask the Chatbot a question about this file.
A demo showing the attack:
https://github.com/user-attachments/assets/af00f700-f13f-4eac-848e-8afd11fb9297
In the demo the attacker steals Langflow secret key used to sign JWTs. The second stage of the attack, not shown in the demo, is using this key to sign a JWT token and executing Python code on the server using the Python code interpreter node.
Impact
Any Langflow user using any of the above mentioned components to ingest user-controlled data is affected. Depending on exact scenario, the user can also be exposed to an RCE risk.
Patches
Fixed in 1.9.2 via PR #12945. BaseFileComponent._unpack_bundle now rejects symlink and hardlink members (and any non-regular entries) during TAR extraction, with additional defensive symlink filtering during directory recursion and after extraction. Upgrade to 1.9.2 or later.
Ori Lahav Security Researcher @ Rubrik Inc.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | langflow | all versions | 1.9.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langflow. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update langflow to 1.9.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-ccv6-r384-xp75 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-ccv6-r384-xp75 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-ccv6-r384-xp75. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-ccv6-r384-xp75 in your dependencies?
O3 detects GHSA-ccv6-r384-xp75 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.