A critical path traversal vulnerability in Langflow, tracked as CVE-2026-5027, is being actively exploited in the wild. If your organisation runs Langflow to build AI agent pipelines, and you haven't patched to version 1.9.0 yet, you are exposed right now. Security teams at enterprises, financial institutions, and government bodies across EMEA need to treat this as urgent, not a scheduled maintenance item. The flaw scored 8.8 on the CVSS scale, it requires no credentials to trigger on a default installation, and it hands an attacker full remote code execution on the underlying server. That's the short version. The longer version explains exactly why this one is particularly damaging and what you need to do before the window closes further.
Langflow is an open-source visual framework for building AI agent workflows, the kind of tool that lets teams wire up large language models, retrieval-augmented generation pipelines, and multi-agent orchestration without writing everything from scratch. Its appeal is real, and its adoption across enterprise AI teams has grown quickly. That popularity is precisely what makes a vulnerability of this severity so consequential. According to The Hacker News, CVE-2026-5027 is a path traversal vulnerability rooted in the way Langflow's file upload mechanism handles user-supplied input. It does not require sophisticated tooling to exploit. A carefully constructed HTTP request is enough.
The vulnerable endpoint is POST /api/v2/files. When a multipart form-data request is submitted to that endpoint, Langflow accepts a filename parameter and uses it directly, without sanitisation , to determine where on the server's filesystem the uploaded file should be written. An attacker can embed path traversal sequences such as ../ in that parameter to escape whatever intended upload directory exists and write a file to an arbitrary location on the server. As Orca Security explains in its detailed technical write-up, the attacker can upload a file containing malicious code and place it precisely at a path where the server will subsequently execute it. That chain , file write to arbitrary path, then execution , is what elevates this from a simple traversal to full remote code execution.
The mechanics matter because they determine how simple a working exploit actually is. There's no need to corrupt memory, no need to bypass address space layout randomisation, no need to chain multiple memory corruption bugs together. If you can reach the endpoint and write a web shell or a Python file to a location Langflow will load, the server is yours. Orca Security confirmed that the flaw enables full remote code execution against the underlying server , not just file disclosure, not just partial access. Full execution.
Here is where the severity jumps. Langflow ships with unauthenticated auto-login enabled by default. That single design decision transforms a path traversal requiring a valid session into one that requires nothing whatsoever. As The Hacker News reported, a single request to obtain a valid session token is all that's needed before chaining into the arbitrary file write. On a default Langflow installation, an attacker who can reach the network port can obtain that token and proceed to exploitation in one fluid sequence, with no stolen credentials, no phishing, no insider access required.
It's worth pausing on what "unauthenticated auto-login enabled by default" actually means operationally. Langflow is designed to be collaborative , teams working on AI workflow design often want a shared, accessible environment. The auto-login feature exists to reduce friction in that context. But when it is left on in a production or internet-facing instance, it removes the entire credential layer from the attack chain. Disabling auto-login does not patch the path traversal flaw in the POST /api/v2/files endpoint; the underlying vulnerability still exists. But it does force an attacker to first obtain valid credentials, which meaningfully raises the bar. The only complete fix is patching to version 1.9.0.
How a vendor and its maintainers respond to reported vulnerabilities tells you something important about the security posture of a project. In this case, the timeline for CVE-2026-5027 is a cautionary story about what happens when responsible disclosure goes unanswered , and about the exploitation window that opens as a result.
Tenable's researchers discovered the vulnerability and initiated responsible disclosure. According to Tenable's own account, they contacted the Langflow maintainers not once but three times, between January and February 2026. Three separate attempts across two months. The maintainers did not respond to any of them. This is not an unusual situation in the open-source ecosystem, where projects can be under-resourced, maintainers can be unavailable, and security disclosure channels are not always well-staffed. But it has consequences. A vulnerability sitting in a researcher's disclosure queue, unacknowledged, is a vulnerability that is not being fixed , and every day without a patch is a day the risk accumulates in production environments that have no idea the flaw exists.
Understanding the full cyber threat intelligence cycle , from discovery through to active exploitation , matters here, because the gap between responsible disclosure and public knowledge is exactly when sophisticated threat actors have the greatest asymmetric advantage. Tenable knew about this flaw. The maintainers had been told. The rest of the world had not.
With three unanswered contact attempts behind them, Tenable publicly disclosed CVE-2026-5027 on 27 March 2026. The project maintainer subsequently confirmed that the vulnerability had been addressed in Langflow version 1.9.0. That confirmation, however, came after public disclosure , not before it. The sequence is important: public knowledge of the flaw arrived before a significant portion of the installed base could be quietly patched in the background. Once a vulnerability is publicly named, described, and catalogued, the timeline for weaponisation compresses sharply. Proof-of-concept code circulates. Scanning tools get updated. Exploitation frameworks incorporate the technique.
VulnCheck confirmed active exploitation in the wild, with honeypot infrastructure detecting attackers dropping test files onto vulnerable Langflow instances. That behaviour , writing a benign file first to confirm that the write primitive works before proceeding to a payload , is a characteristic tradecraft pattern. It tells you these are not random scanners; these are operators who understand the vulnerability and are conducting deliberate reconnaissance before committing to a full exploitation chain. SecurityWeek confirmed that the flaw is being actively targeted in the wild for remote code execution. The exploitation window is not theoretical. It is open now.
Remote code execution on a Langflow server is not the end of the story. It is the beginning. The question of what an attacker can reach from that initial foothold is what determines the actual blast radius of a successful compromise, and on a typical enterprise Langflow deployment, that radius is large.
Langflow instances used in production AI pipelines tend to sit at the centre of a web of integrations. They hold API keys for commercial language model providers. They have credentials for vector databases storing your organisation's proprietary data , customer records, internal documents, product information. They connect to internal APIs that other services trust. In a multi-agent orchestration setup, a Langflow instance may have the authority to trigger actions across multiple systems. An attacker with code execution on that server doesn't just own the Langflow process; they are positioned to pivot into every system that Langflow is authorised to reach.
The credential stores alone make this attractive. LLM API keys, particularly those with high usage limits, are a commodity on dark web markets. A threat actor who obtains them from a compromised Langflow server can monetise them immediately , running their own inference workloads at your expense, selling access, or using the LLM endpoint as part of a larger offensive operation. Vector databases containing RAG corpus data represent a different category of risk: exfiltration of that data can expose intellectual property, confidential customer information, or regulated personal data depending on what the pipeline was built to process.
VulnCheck's honeypot observations of test-file drops suggest that at least some of the actors targeting this vulnerability are methodical. They're confirming write capability before escalating, which implies an intent to establish persistence rather than simply run a one-shot command. Persistence on a Langflow server , a backdoored Python file, a modified workflow component, a scheduled task , could survive a superficial incident response that focuses only on the application layer without auditing the underlying filesystem and process environment.
This is also the kind of access that feeds lateral movement. Once an attacker has an interactive shell on the server, they can read environment variables, probe the local network, interrogate cloud metadata services if the instance runs in AWS, Azure, or GCP, and attempt credential theft from memory. The Langflow server is a pivot point, not a target in itself.
Assessing your exposure starts with understanding who actually runs Langflow and how those deployments are typically configured. The answer, unfortunately for defenders, is that the configuration that maximises usability also maximises attack surface.
VulnCheck's research identified approximately 7,000 Langflow instances accessible from the public internet, with the majority located in North America. That figure does not represent the total installed base , it represents the instances that have been deliberately or inadvertently exposed beyond their organisation's network perimeter. For security managers thinking about their own attack surface, the relevant question is whether your Langflow deployment sits among those 7,000 or whether it is adequately isolated behind controls that prevent direct internet access.
Many of these exposures are intentional. Development teams expose Langflow to allow remote contributors to collaborate on workflow design. Organisations running AI projects across multiple geographies find it convenient to make the interface reachable without a VPN. That convenience has a cost that wasn't fully visible until CVE-2026-5027 arrived. The previous Langflow vulnerability, CVE-2025-3248, was a critical RCE flaw that CISA added to its Known Exploited Vulnerabilities catalogue in May 2025. That precedent makes the current situation worse, not better , it suggests a pattern of serious security weaknesses in this platform, and it means any organisation that evaluated Langflow's security posture before May 2025 and concluded it was acceptable needs to re-evaluate that conclusion now.
Beyond the internet-exposed instances, the more pervasive risk sits inside enterprise networks. Langflow's core use cases , building RAG systems, constructing chatbots, orchestrating multi-agent AI workflows , are exactly what enterprise AI teams are working on right now. Financial institutions are using these architectures to power internal research tools and customer-facing applications. Government bodies are exploring LLM-based document processing. Technology companies are building product features on top of agent frameworks. Many of these deployments would not show up in an internet scan because they're internal , but internal doesn't mean safe if the network is breached through another vector, or if the Langflow instance has cloud network peering, VPN access, or a misconfigured security group that creates an unintended exposure path.
The access Langflow holds to internal APIs and data stores means that even an attacker who first breaches a low-value network endpoint can subsequently use a Langflow compromise to reach systems they would otherwise have no path to. That makes it an attractive lateral movement target in an environment where it hasn't been adequately hardened or segmented. If your organisation's AI infrastructure has grown quickly over the past eighteen months , as it has for many EMEA enterprises , there's a meaningful chance that Langflow or a similar tool has been deployed without the same security scrutiny applied to more established enterprise software.
The immediate action is unambiguous: upgrade to Langflow version 1.9.0. The project maintainer confirmed this version addresses CVE-2026-5027. If you are running any prior version of Langflow, you are running vulnerable software against which active exploitation has been confirmed. Patch first, then investigate what additional controls are warranted.
While you're preparing the upgrade, disable unauthenticated auto-login if you have not already done so. This does not fix the underlying path traversal flaw, but it forces attackers to obtain valid credentials before they can reach the vulnerable endpoint. It meaningfully narrows your exposure during the time between now and when the patch is deployed. Find this setting in Langflow's configuration and set LANGFLOW_AUTO_LOGIN to false in your environment variables. Restart the service after making that change.
If your Langflow instance is accessible from the internet and there is no operational reason for that exposure, remove it. Put it behind a VPN or restrict access via network security group rules, firewall policies, or a zero-trust access proxy. The 7,000 internet-accessible instances VulnCheck counted are exactly the target population attackers are scanning. Removing your instance from that population eliminates the most direct attack vector.
Audit the credentials and API keys your Langflow installation has access to. Check environment variables, .env files, and any secrets management integration. If there is any possibility that your instance was compromised prior to patching , and the timeline of active exploitation means you cannot rule this out , rotate those credentials immediately. LLM provider API keys, vector database credentials, and any internal service tokens that Langflow holds should be treated as potentially compromised until rotation is complete.
Review your Langflow server's filesystem for unexpected files, particularly in directories where Python code or configuration files are loaded at startup. VulnCheck's honeypot data showed attackers dropping files to confirm write access. If an attacker got that far, a second payload may have followed. Look at your web server logs for unexpected requests to POST /api/v2/files with unusual filename parameters containing traversal sequences. Check your application logs for session token creation events that don't correspond to known users.
Finally, ensure your threat detection coverage extends to your AI infrastructure. Langflow servers should be sending logs to your SIEM, and anomalous file creation events on those hosts should generate alerts. If your current monitoring posture treats Langflow as a developer tool outside the security perimeter, fix that gap now. The risk profile of these systems is identical to any other internet-facing application with access to sensitive data and internal services.
Knowing what to look for is the foundation of effective incident detection, and understanding indicators of compromise in this context means focusing on the specific artefacts and behavioural signals this exploitation chain produces.
In your web access logs, look for HTTP POST requests to /api/v2/files where the filenamefield in the multipart body contains dot-dot-slash sequences (../) or their URL-encoded equivalents (%2e%2e%2f, %2e%2e/, ..%2f). A successful traversal attempt will return an HTTP 200 response; failed or blocked attempts may return 400 or 500 errors, but even failed attempts indicate active scanning. The VulnCheck honeypot observations confirm that attackers are writing benign test files first, so look for small file writes to unexpected directories that precede larger or more suspicious ones.
On the filesystem, unexpected files in directories outside the intended upload path are the primary artefact. Python files (.py), configuration files, and shell scripts appearing in locations where Langflow loads code at startup are high-priority findings. Check modification timestamps on existing Python files in the Langflow installation directory , a recently modified file that you didn't change is a red flag. On Linux hosts, find / -newer /var/log/auth.log -name "*.py" 2>/dev/null can help surface recently created or modified Python files across the system.
At the process level, watch for unexpected child processes spawned from the Langflow process. If your host-based detection covers process creation events, look for shell processes, network utilities such as curl or wget, or Python invocations that originate from the Langflow parent process and were not initiated by known users. On cloud-hosted instances, check cloud provider audit logs for unexpected API calls originating from the Langflow host's IAM role or instance profile, particularly calls to secrets managers, storage buckets, or cross-account roles.
Network-level indicators include outbound connections from your Langflow server to external IP addresses that are not part of your configured LLM provider endpoints or known infrastructure. A freshly compromised server establishing a reverse shell or beaconing to a command-and-control endpoint will produce outbound traffic on unusual ports or to unusual destinations. Capture and baseline your Langflow server's normal outbound connection profile if you haven't already, so that deviations are detectable. Unusual DNS queries from the host are worth examining as well.
Langflow is an open-source visual framework for building AI agent workflows. Enterprise teams use it to construct retrieval-augmented generation systems, chatbots, and multi-agent orchestration pipelines without building everything in code from scratch. It matters for enterprise security because production Langflow instances typically hold API keys for commercial LLM providers, credentials for vector databases, and connections to internal APIs. Remote code execution on a Langflow server therefore provides an attacker with access to all of those integrations, making it a high-value pivot point in any environment where it is deployed.
Disabling unauthenticated auto-login reduces the exploitability of CVE-2026-5027 by requiring attackers to obtain valid credentials before reaching the vulnerable POST /api/v2/files endpoint. It is a meaningful defensive step if you cannot patch immediately. However, it does not fix the underlying path traversal flaw , an attacker with valid credentials can still exploit the vulnerability on an unpatched instance. The only complete mitigation is upgrading to Langflow version 1.9.0, which the project maintainer confirmed addresses the vulnerability.
Langflow version 1.9.0 is the version confirmed by the project maintainer as addressing CVE-2026-5027. If you are running any version prior to 1.9.0, your installation is vulnerable. The upgrade should be treated as urgent given that active exploitation in the wild has been confirmed by VulnCheck and SecurityWeek.
CVE-2026-5027 and CVE-2025-3248 are distinct vulnerabilities with different technical mechanisms, but they share the same platform and the same consequence: full remote code execution. CVE-2025-3248 was a critical RCE flaw that CISA added to its Known Exploited Vulnerabilities catalogue in May 2025. The recurrence of a critical RCE-class vulnerability in Langflow within roughly twelve months suggests that the platform's security posture warrants sustained scrutiny, not a one-time patch and return to business as usual. Organisations running Langflow should apply the same ongoing vulnerability management discipline to it that they apply to other internet-facing or production-critical software.
The most direct approach is to check whether the host or container running Langflow has a public IP address or a DNS record resolving to one, and whether TCP port 7860 (Langflow's default port) or any port to which you've mapped the service is reachable from outside your network perimeter. You can verify this using external port scanning tools or by checking your cloud provider's security group and firewall rules. VulnCheck identified approximately 7,000 publicly accessible Langflow instances, the majority in North America, by scanning the internet , which means an automated attacker can find yours the same way. If you discover your instance is internet-accessible and it doesn't need to be, restricting that access is an immediate priority alongside patching to version 1.9.0.
Attacks like this one rarely announce themselves through official channels first. New payloads, active infrastructure, and exploitation techniques circulate in closed forums and private channels well before any public research surfaces them. By the time an incident makes it into a threat report, organisations without early visibility are already behind.
Defendis gives your security team that early visibility. We monitor the dark web, underground forums, and threat actor channels so your team receives relevant intelligence before it becomes breaking news, context about emerging threats matched against your organisation's exposure, without requiring your analysts to spend time in places they should not have to go.
