// threat brief

CVE-2026-33017Actively exploited

Langflow public flow endpoint RCE: anyone can run Python on the server without logging in

CVSS: 9.8 CRITICAL
CISA KEV: 2026-03-25
Weakness: CWE-94 · CWE-95 · CWE-306
Topics: AI security

PlainCVE Team · Published 2026-09-24 · AI-assisted · Press brief ↓

Human review 2026-09-24Command tests: none yetReproduced: not yetVerification record ↓

Langflow's public flow endpoint ran Python code sent by anyone, with no login, letting attackers take over the server. Exploited in the wild.

Who is affected	Organizations running Langflow before 1.9.0 (or langflow-base before 0.9.0) that already have a reachable public flow or a setup that lets unauthenticated users create one (for example AUTO_LOGIN on), where the instance is reachable over the network. Version 1.8.2, widely reported as patched, is still vulnerable.
What happens	An attacker with no account can run any code with the server process's permissions and read environment variables holding AI provider API keys, cloud credentials and database passwords.
What to do now	Upgrade Langflow to 1.9.0 or later. If a pre-1.9.0 instance was reachable from the internet, assume it was compromised and rotate all keys. View evidence(4) Vendor / maintainerThe vendor advisory offers only one fix, upgrading to 1.9.0 or later, and publishes no workaround.github.com Vulnerability databaseThe CISA requirement carried in the NVD record: apply the vendor's mitigations, follow BOD 22-01 for cloud services, or stop using the product.Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.services.nvd.nist.gov ResearchersIf you cannot upgrade yet, Sysdig recommends restricting network access to the public build endpoint or disabling public flow building.If a patched version is not yet available, restrict network access to the /api/v1/build_public_tmp endpoint or disable public flow building entirely.sysdig.com ResearchersCSA advises assuming compromise and rotating all keys if a pre-1.9.0 instance was internet-accessible; blocking the endpoint at a reverse proxy or WAF is only a stopgap.Assume compromise if running a pre-1.9.0 instance that was internet-accessible.labs.cloudsecurityalliance.org
Affected versions	All versions before 1.9.0 (vendor advisory says ≤ 1.8.2; the CNA and GitLab say < 1.9.0; whether 1.8.3 and 1.8.4 are fixed is unconfirmed, so treat them as affected); the separate langflow-base package is affected before 0.9.0 (JFrog) View evidence: sources disagree(4) Vendor / maintainerDisputedThe vendor advisory lists langflow <= 1.8.2 as affected, which disagrees with the CNA record's < 1.9.0 (whether 1.8.3 and 1.8.4 are affected is unconfirmed).github.com CVE recordDisputedThe CVE record (GitHub as CNA) says all versions before 1.9.0 are affected, which disagrees with the vendor advisory's <= 1.8.2.In versions prior to 1.9.0, the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint allows building public flows without requiring authentication.cveawg.mitre.org Vendor / maintainerThe attack needs a reachable public flow; the vendor advisory's prerequisites say that with AUTO_LOGIN on, an unauthenticated attacker can create one.all prerequisites can be met by an unauthenticated attackergithub.com ResearchersJFrog tested the PyPI and Docker builds and found 1.8.2, widely reported as patched, still exploitable.This confirms that version 1.8.2 is still vulnerable.research.jfrog.com
Fixed versions	langflow 1.9.0 or later, langflow-base 0.9.0 or later (JFrog showed 1.8.2 is not fixed) View evidence(4) Vendor / maintainerThe vendor advisory gives langflow 1.9.0 and later as the patched versions.github.com CVE recordThe CVE record also says 1.9.0 fixes it.This issue has been fixed in version 1.9.0.cveawg.mitre.org Vulnerability databaseThe GitLab Advisory Database recommends upgrading to 1.9.0 or later.Upgrade to version 1.9.0 or above.advisories.gitlab.com ResearchersJFrog notes that the separate langflow-base package is patched from 0.9.0.0.9.0 (to be released) includes a patch.research.jfrog.com
CVSS vector	Show full vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
Timeline	First public 2026-03-16 First attacks 2026-03-18 · Sysdig saw first in-the-wild exploitation attempts source
CISA KEV	Listed (2026-03-25): attacks have been seen in the wild View evidence(4) Vulnerability databaseThe NVD record shows CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on 2026-03-25, with a federal deadline of 2026-04-08.services.nvd.nist.gov ResearchersSysdig saw the first exploitation attempt at 16:04 UTC on 2026-03-18; its "about 20 hours" is counted from the GitHub global advisory database entry at 20:05 UTC on 3/17.Within 20 hours of the advisory’s publication, the Sysdig Threat Research Team (TRT) observed the first exploitation attempts in the wild.sysdig.com Our assessmentCounted from the vendor's repository advisory at 12:20 UTC on 3/16, the first exploitation attempt came about 52 hours later. ResearchersJFrog also reports that the vulnerability is actively exploited and listed in CISA KEV.Langflow CVE-2026-33017 is actively exploited and listed in CISA KEVresearch.jfrog.com

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?

01Find every Langflow install and check its version
Include the PyPI langflow and langflow-base packages, Docker images and nightly builds. Treat langflow below 1.9.0 and langflow-base below 0.9.0 as vulnerable, including 1.8.2.
Read-only check
```
pip list 2>/dev/null | grep -i '^langflow'
```
02Check exposure: public flows, internet reachability, AUTO_LOGIN
Risk is highest if a reachable public flow already exists, or the setup lets unauthenticated users create one, and the instance is reachable over the network. Per the vendor advisory, when AUTO_LOGIN is on (everyone is signed in as a superuser automatically) someone who never logged in can create a public flow themselves, so having no public flow today does not make you safe.
Read-only check
```
env | grep -i LANGFLOW_AUTO_LOGIN
```
Step 1
03Search access logs for the public build endpoint
Look for requests to /api/v1/build_public_tmp, especially from unfamiliar sources or in large repeated bursts. The attacker IPs published by Sysdig can be used for matching (see Further reading).
Read-only check
```
grep -n 'build_public_tmp' /path/to/access.log
```
Step 2
04Look for signs that code was executed
Researcher advice: shells or curl/wget started by the Langflow process, reads of .env or other sensitive files, DNS lookups or connections to callback services such as interactsh / oast.*, and traffic to the C2 addresses Sysdig published.
Step 4 Step 5

MITIGATEFix / mitigatePatch; block it if you cannot patch yet

01Upgrade to 1.9.0 or later
This is the vendor-stated fix and the only complete one. After the fix, the public endpoint only uses the flow stored in the database.
Changes your environment
```
pip install -U "langflow>=1.9.0"
```
Step 2 Step 3
02Environments that install langflow-base on its own
JFrog lists the langflow-base package as affected too, fixed from 0.9.0. Environments that install only langflow-base should upgrade it to 0.9.0 or later.
Changes your environment
```
pip install -U "langflow-base>=0.9.0"
```
Step 2 Step 3
03Can't upgrade yet: block the endpoint or take it offline
The vendor published no workaround besides the fix. Researchers suggest blocking or restricting /api/v1/build_public_tmp and putting the instance behind a firewall, authentication layer or WAF; take internet-exposed instances offline until upgraded.
Step 1 Step 2
04Turn off AUTO_LOGIN for shared deployments
The official docs recommend LANGFLOW_AUTO_LOGIN=False for shared or public deployments and not exposing ports directly to the internet. This alone does not fix this flaw, but it reduces other exposure.
Step 1

RESPONDRespondIf you find signs of compromise

01Assume compromise and rotate credentials
Researcher advice: if a pre-1.9.0 instance was reachable from the internet, assume it was compromised and rotate all AI-provider and cloud API keys plus database credentials.
Step 5
02Review environment variables and look for persistence
List which secrets the instance held to decide what to rotate, and check for any second-stage program left behind. Rebuild from a clean environment if needed.
Step 4 Step 5

HARDENHardenPrevent the next one

01Use a secrets manager and scoped keys
Don't keep keys in plain environment variables; use scoped API keys with usage limits so one compromised instance costs less.
Step 5
02Inventory AI tooling and verify fixes yourself
1.8.2 was widely called patched but wasn't. Put AI tools like Langflow into vulnerability management and confirm the fix is really in the version you run.

Full remediation steps and notes

Check the version. pip show langflow langflow-base; for Docker deployments, check the image tag. langflow-base needs 0.9.0 or later. 1.8.2 does not count as fixed, so don’t rely on version numbers quoted in news reports.
Upgrade. pip install -U "langflow>=1.9.0", or switch to a 1.9.0+ Docker image. PyPI lists 1.9.0 as released on 2026-04-14. For environments with only langflow-base: pip install -U "langflow-base>=0.9.0".
Order matters. If the instance was internet-facing, isolate or take it offline first, then upgrade, then rotate credentials. Rotating while the old version is still exposed risks the new keys being stolen too.
Vendor vs. researchers. The vendor advisory offers only the upgrade. Blocking the endpoint, WAFs, taking instances offline, and assuming compromise and rotating keys come from Sysdig and CSA. CISA requires federal agencies to apply vendor mitigations, follow BOD 22-01 for cloud services, or stop using the product.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.

Attacker
Finds an exposed Langflow instance and a public flow ID
The vendor advisory notes public flows are common for demos and sharing, and their IDs can be learned from shared links. Sysdig observed automated scanning for targets.
Defense: Don't expose Langflow ports directly to the internet; put it behind a firewall or an authentication layer.
Attacker
Calls the public flow build endpoint with a flow definition of their own
This endpoint is meant to work without login. The attacker's definition carries custom Python component code.
Defense: Stopgap before upgrading (researcher advice): block or restrict the /api/v1/build_public_tmp path at a reverse proxy or WAF.
Your system
Langflow uses the caller's definition instead of the stored flow
Older versions followed the logic "if the caller sent a definition, use it; otherwise load the saved one."
Defense: Upgrade to 1.9.0 or later: the public endpoint always loads the stored flow and ignores any caller-supplied definition.
Your system
The server runs the Python code with exec()
While building the flow, custom component code runs without a sandbox, with the same permissions as the server process.
Defense: Monitor for shells, curl or wget started by the Langflow process (Sysdig suggests Falco rules).
Attacker
Reconnaissance, credential theft and attempts to persist
Sysdig observed attackers listing directories, dumping environment variables, harvesting credentials and trying to deliver a second-stage payload to stay on the machine.
Defense: Keep secrets in a secrets manager rather than environment variables; use scoped API keys with usage limits; rotate them immediately if compromised.

Who is affected

Condition	Affected?
Langflow before 1.9.0 + a reachable public flow already exists, or the setup lets unauthenticated users create one (for example AUTO_LOGIN on) + reachable over the network	Affected
Langflow 1.8.2	Affected. Many reports called it patched, but JFrog showed both the PyPI and Docker builds are still exploitable
Langflow 1.8.3, 1.8.4	Unconfirmed. The vendor advisory says ”≤ 1.8.2” is affected; the CNA and GitLab say ”< 1.9.0”. This page recommends treating them as affected
Langflow 1.9.0 or later	Fixed
langflow-nightly 1.9.0.dev18	JFrog confirmed the fix works
langflow-base before 0.9.0	Affected (listed by JFrog; fixed from 0.9.0, released on PyPI 2026-04-14)

Per the vendor advisory, the attacker needs a reachable public flow and its ID, which can be learned from shared links. But the advisory’s Prerequisites also state that if AUTO_LOGIN (automatic superuser sign-in) is on, an unauthenticated attacker can create a public flow themselves, so there is no authentication barrier at all. The condition is therefore “a reachable public flow already exists, or the setup lets unauthenticated users create one”; having no public flow today does not make you safe. The current docs say this setting defaults to on in the application and off in the official Docker images; whether the defaults were the same in the vulnerable versions is unconfirmed.

How it works

Langflow lets people build AI workflows (“flows”) by connecting components. A flow can be made public so people can run it without logging in. A flow definition can include custom Python component code, and when Langflow “builds” a flow it runs that code with Python’s exec() (a function that runs a piece of text as a program), without a sandbox.

The endpoint that runs public flows (/api/v1/build_public_tmp/{flow_id}/flow) had two problems at once:

It is designed to work without login (CWE-306, missing authentication for a critical function).
Besides loading the flow stored in the database, it also accepted a full flow definition sent by the caller.

Together, this meant anyone could send a flow definition carrying Python code, and the server would run it with its own permissions (CWE-94 code injection, CWE-95 eval injection). The vendor advisory lists theft of environment variables, such as API keys and database credentials, among the impacts.

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)

def build_public_flow(flow_id, data=None):
    # Use the caller's definition if one was sent; otherwise load the saved one
    flow = data if data is not None else load_saved_flow(flow_id)
    build(flow)  # custom component code inside gets executed

The fixed approach:

Show code example(python)

def build_public_flow(flow_id, data=None):
    # Always load the stored flow; ignore any definition the caller sent
    flow = load_saved_flow(flow_id)
    build(flow)

Fix commit 73b6612 does exactly this and adds unit tests to check the parameter is ignored. The vendor’s stated principle: public flows run only the stored definition, never one sent by the caller.

Timeline

Date	Event
2026-02-26	Reported by researcher Aviral Srivastava (per secondary news cited by CSA; the vendor credits “Aviral2642”)
2026-03-16	Vendor publishes security advisory GHSA-vwmf-pq79-vjvx in the GitHub repository (12:20 UTC), the first public disclosure
2026-03-17	The same advisory is published to GitHub’s global advisory database (20:05 UTC), a separate publication event; Sysdig uses this as the advisory publication time, and GitLab also gives 3/17
2026-03-17 / 20	1.8.2 released (GitHub tag 3/17, PyPI 3/20); later shown not to fix the bug
2026-03-18	Sysdig sees the first exploitation attempt (16:04 UTC); credential theft seen that evening. Sysdig’s “about 20 hours” counts from the 3/17 20:05 global advisory; counted from the 3/16 repository advisory it is about 52 hours
2026-03-20	CVE published
2026-03-25	CISA adds it to the Known Exploited Vulnerabilities catalog; federal due date 2026-04-08
2026-03-26	JFrog shows 1.8.2 is still exploitable; GitHub issue #12345 opened
2026-03-26 / 04-01	1.8.3 and 1.8.4 released on PyPI; fix status unconfirmed
2026-04-06 / 14	1.9.0 released (GitHub tag 4/6, PyPI 4/14), the first confirmed fixed release

Verification Reviewed and checked against sources; not yet reproduced in our lab

Reviewed	2026-09-24

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

AdvisoryUnauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint (GHSA-vwmf-pq79-vjvx) · Langflow (langflow-ai), 2026-03-16 · accessed 2026-09-23
CVE / NVD / OSVNVD CVE API record CVE-2026-33017 · NIST NVD, 2026-03-20 · accessed 2026-09-23
CVE / NVD / OSVCVE-2026-33017 CVE record · CVE Program / GitHub (CNA), 2026-03-20 · accessed 2026-09-23
Patch / releasefix: prevent RCE via data parameter in build_public_tmp endpoint (#12160) · Langflow (langflow-ai) · accessed 2026-09-23
Patch / releaseRelease 1.8.2 · Langflow (langflow-ai), 2026-03-17 · accessed 2026-09-23
Patch / releaseRelease 1.9.0 · Langflow (langflow-ai), 2026-04-06 · accessed 2026-09-23
Otherlangflow release history · PyPI · accessed 2026-09-23
AdvisoryLangflow Unauth RCE (CVE-2025-3248) · GitHub Advisory Database, 2025-06-17 · accessed 2026-09-23
AdvisoryCVE-2026-33017: Unauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint · GitLab Advisory Database, 2026-03-17 · accessed 2026-09-23
OtherCVE-2026-33017 is not fixed in langflow 1.8.2 · Issue #12345 · GitHub (langflow-ai/langflow), 2026-03-26 · accessed 2026-09-23
ResearchLangflow CVE-2026-33017: Latest 'fixed' version is still exploitable · JFrog Security Research, 2026-03-26 · accessed 2026-09-23
ResearchCVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours · Sysdig, 2026-03-19 · accessed 2026-09-23
ResearchLangflow RCE CVE-2026-33017: Exploited Within 20 Hours · Cloud Security Alliance, 2026-03-25 · accessed 2026-09-23
VendorAPI keys and authentication · Langflow · accessed 2026-09-23
AdvisoryGitHub Advisory Database API record GHSA-vwmf-pq79-vjvx · GitHub Advisory Database, 2026-03-17 · accessed 2026-09-24
AdvisoryGitHub repository security advisory API record GHSA-vwmf-pq79-vjvx · Langflow (langflow-ai), 2026-03-16 · accessed 2026-09-24
Otherlangflow-base release history · PyPI · accessed 2026-09-24

Press brief

In one sentence

Langflow is an open-source tool for building AI workflows. Its endpoint for running "public flows" needs no login, yet it ran Python code sent by the caller, letting anyone take over the server. Security firm Sysdig saw attacks about 20 hours after the advisory entered GitHub's advisory database on March 17, 2026, and the US agency CISA added the flaw to its Known Exploited Vulnerabilities catalog on March 25, 2026. The confirmed fixed version is 1.9.0; 1.8.2, widely described as the patch, is still vulnerable.

Key facts

Severity: CVSS 3.1 9.8 (NVD); CVSS 4.0 9.3 (CNA) services.nvd.nist.gov
Added to CISA KEV: 2026-03-25 (federal due date 2026-04-08) cveawg.mitre.org
Fixed version: 1.9.0 or later github.com
1.8.2 not fixed: Shown by JFrog on 2026-03-26 research.jfrog.com
First exploitation attempt: About 20 hours after the GitHub global advisory (2026-03-17 20:05 UTC) was published (2026-03-18 16:04 UTC, observed by Sysdig) sysdig.com

Confirmed

The public flow build endpoint needs no login and ran Python code from a caller-supplied flow definition.
CISA lists it as known exploited; Sysdig observed scanning, reconnaissance and credential theft.
1.8.2 is still vulnerable; 1.9.0 is the confirmed fixed version.

Unconfirmed / disputed

Whether 1.8.3 and 1.8.4 are fixed: the vendor advisory (≤ 1.8.2) and the CNA and GitLab (< 1.9.0) disagree.
The 1.9.0 release date: the GitHub tag says April 6, PyPI says April 14, and CSA claims March 17 alongside the advisory.
NVD's exact affected version range could not be checked by hand.
The 2026-02-26 report date comes only from secondary news cited by CSA.

Quotable line

A public button that should only have played the saved script was willing to perform whatever script a stranger handed it.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

Langflow public flow endpoint RCE: anyone can run Python on the server without logging in

Langflow is an open-source tool for building AI workflows. Its endpoint for running "public flows" needs no login, yet it ran Python code sent by the caller, letting anyone take over the server. Security firm Sysdig saw attacks about 20 hours after the advisory entered GitHub's advisory database on March 17, 2026, and the US agency CISA added the flaw to its Known Exploited Vulnerabilities catalog on March 25, 2026. The confirmed fixed version is 1.9.0; 1.8.2, widely described as the patch, is still vulnerable.

Key facts:
- Severity:CVSS 3.1 9.8 (NVD); CVSS 4.0 9.3 (CNA)(https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33017)
- Added to CISA KEV:2026-03-25 (federal due date 2026-04-08)(https://cveawg.mitre.org/api/cve/CVE-2026-33017)
- Fixed version:1.9.0 or later(https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx)
- 1.8.2 not fixed:Shown by JFrog on 2026-03-26(https://research.jfrog.com/post/langflow-latest-version-was-not-fixed/)
- First exploitation attempt:About 20 hours after the GitHub global advisory (2026-03-17 20:05 UTC) was published (2026-03-18 16:04 UTC, observed by Sysdig)(https://www.sysdig.com/blog/cve-2026-33017-how-attackers-compromised-langflow-ai-pipelines-in-20-hours)

Confirmed:
- The public flow build endpoint needs no login and ran Python code from a caller-supplied flow definition.
- CISA lists it as known exploited; Sysdig observed scanning, reconnaissance and credential theft.
- 1.8.2 is still vulnerable; 1.9.0 is the confirmed fixed version.

Unconfirmed / disputed:
- Whether 1.8.3 and 1.8.4 are fixed: the vendor advisory (≤ 1.8.2) and the CNA and GitLab (< 1.9.0) disagree.
- The 1.9.0 release date: the GitHub tag says April 6, PyPI says April 14, and CSA claims March 17 alongside the advisory.
- NVD's exact affected version range could not be checked by hand.
- The 2026-02-26 report date comes only from secondary news cited by CSA.

「A public button that should only have played the saved script was willing to perform whatever script a stranger handed it.」— PlainCVE
https://plaincve.date/en/vulns/cve-2026-33017-langflow-public-flow-rce

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Langflow public flow endpoint RCE: anyone can run Python on the server without logging in". PlainCVE. https://plaincve.date/en/vulns/cve-2026-33017-langflow-public-flow-rce (accessed YYYY-MM-DD)

BibTeX

@misc{cve202633017langflowpublicflowrce2026,
  title  = {Langflow public flow endpoint RCE: anyone can run Python on the server without logging in},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-33017-langflow-public-flow-rce},
  note   = {Updated 2026-09-24}
}