CVE-2026-33017

Langflow lets people create “flows” that automate tasks. This bug allows someone on the internet to send specially crafted flow details that cause Langflow to run attacker-written code on the server. It’s like giving a stranger a form that’s supposed to create a workflow—but instead, it lets them write and run instructions on your computer.

This matters if your business runs Langflow and has the public flow building function reachable from the internet. If attackers can reach the public endpoint used to build “public flows,” they do not need an account to trigger the code execution. Reachability is the deciding factor—if it’s not reachable from untrusted networks, the risk is reduced; if it is reachable, you should treat it as exposed.

This is RED because the vulnerability is listed in CISA KEV and exploitation is reported in the real world. Attackers do not need to log in, so once the endpoint is reachable, it can be targeted directly. Your priority should be to upgrade quickly and restrict internet access to the affected functionality until fixed.

Confirm exposure

• Identify how Langflow is deployed (public internet, behind a reverse proxy, VPN-only, etc.).
• Determine whether the public flow build endpoint used for building “public flows” is accessible from the internet. If you have a firewall, proxy, or load balancer, check whether requests can reach Langflow from untrusted networks.
• Check your application logs (and reverse proxy logs) for requests that match the public build/flow building path patterns for public flow construction. Look for unusual request volumes or requests that don’t resemble normal usage.

Upgrade to the fixed version

• Upgrade Langflow to the fixed version: Langflow fixed in 1.8.2.
• If you have multiple environments (dev/staging/prod), upgrade in this order: staging first for validation, then production.

If you cannot upgrade immediately (temporary containment)

• Block access to the public flow build functionality from the public internet (or untrusted networks) using your firewall/proxy rules.
• If you must keep public flows enabled for legitimate use, restrict them to a controlled set of networks/IPs or require a gateway/auth layer where feasible until upgrading is done.

Post-upgrade verification

• Re-check that the endpoint is no longer reachable from untrusted networks (or is now safely handled by the fixed Langflow version).
• Continue monitoring logs for attempts to access the affected endpoint.
• For a confirmed incident response workflow: if you find suspicious activity, isolate the server, rotate secrets, and treat any data exposure as possible.

CISA timeline

• CISA KEV remediation due date: 2026-04-08.

What to monitor

• Logs for the public flow build endpoint being accessed unexpectedly.
• Any signs of new processes, file changes, or unexpected outbound network connections from the Langflow host.

Severity is critical (CVSS 9.8). The weakness is consistent with arbitrary code execution issues (CWE-94: Return of Code in an Alternate Plane; CWE-95: Improper Neutralization; CWE-306: Missing Authentication for Critical Function).

Mechanism: Langflow’s public flow build endpoint accepts attacker-supplied flow data and executes it as Python on the server without effective sandboxing/restriction. This is triggered remotely via specially crafted requests that cause execution of arbitrary Python code in node definitions.

Exploitation status: This vulnerability is in CISA KEV and has reported real-world exploitation, so it should be treated as actively weaponized.

Patch: Fixed in Langflow 1.8.2 (also referenced as part of the vendor remediation guidance). The incident reports additionally note related exploitation in the broader Langflow ecosystem, underscoring attacker interest.

About KEV: CISA KEV indicates known exploitation in the wild and typically requires prompt mitigation aligned to CISA guidance.