Verified Behavior in This Lab

The following behavior has been verified in this lab:

• A vulnerable Langflow instance runs at http://localhost:7861
• The version endpoint returns 1.8.1
• A public flow can be created
• build_public_tmp returns a job_id
• The PoC can continue polling events
• The proof object is returned through the API
• Attacker-controlled code is executed within the Langflow runtime

Example proof object:

The key evidence is:

• id_output
• whoami
• hostname
• cwd
• python_version

The information above shows that attacker-controlled code was actually executed on the server side.

Repository Layout

Requirements

• Linux or macOS
• Docker Desktop or Docker Engine
• Docker Compose v2
• Python 3

Service Overview

vuln

• Vulnerable Langflow instance
• Bound port: 7861 -> 7860
• Used to reproduce CVE-2026-33017 on localhost

How the Vulnerability Works

This vulnerability exists because Langflow’s public build endpoint accepts user-supplied flow definitions, even though the endpoint is already designed for public flows. When an attacker submits a node definition containing custom component code, the system passes that code into the flow build path, which ultimately results in code execution on the server.

The PoC in this project uses a custom component that returns a proof object in its output to demonstrate that attacker-controlled code is actually executed.

PoC Design

The PoC in this project is designed to be least-harm and focuses on clearly observable proof through the API. Its workflow is as follows:

1. Wait for Langflow to become ready
2. Call the auto-login endpoint to obtain a token
3. Create a PUBLIC flow
4. Send custom component code to the public build endpoint
5. Receive a job_id
6. Poll the build events API
7. Parse the proof object from the event payload

This PoC does not cover:

• Opening a shell
• Making a reverse connection
• Establishing persistence
• Dumping secrets
• Using a webshell

Run the Lab

1) Start the vulnerable service

2) Verify the version endpoint

3) Run the PoC

Expected Output

When the PoC succeeds, the output will look like this:

The file artifacts/vuln/events-<job_id>.ndjson stores raw event data for additional debugging.

What the Current PoC Proves

This PoC demonstrates that:

• An attacker can invoke the public build flow
• Attacker-controlled code is executed on the Langflow server
• The execution context is returned through the API
• The real impact is unauthenticated code execution

This PoC is not intended to demonstrate persistence or advanced post-exploitation and keeps the impact at the minimum level necessary to validate the vulnerability.

Impact

Based on this lab, the demonstrated impact is:

• An unauthenticated attacker can execute Python code on the Langflow server
• An attacker can access the runtime context of the process
• An attacker can execute one-shot system commands
• An attacker can access the working directory and runtime metadata

Why There Is No Patched Service

This repository does not include a patched service by design.

Its scope is limited to reproducing the vulnerable behavior on a real upstream artifact. A patched side is only added when there is a clearly verifiable official fixed artifact available from the vendor or upstream project.

For that reason, this repository deliberately avoids:

• building a local image to simulate a fixed release,
• modifying the image source to imitate patch behavior, or
• adding helper scripts that would create the appearance of a vulnerable-versus-patched comparison without an authentic upstream patched artifact.

This keeps the lab narrowly scoped and technically honest. Rather than presenting an artificial side-by-side setup, the repository focuses on three things:

• reproducible vulnerable behavior,
• a transparent proof-of-concept, and
• documentation that stays aligned with real upstream artifacts.

In practice, this makes the repository best suited for:

• vulnerable reproduction,
• technical analysis and write-up support, and
• portfolio use where reproducibility and credibility matter more than a synthetic patched environment.

Cleanup

Safety Notes

This lab is designed for testing on localhost only.

Usage requirements:

• Use it only in your own environment
• Do not modify the PoC into a webshell or persistence mechanism
• Do not include real tokens or real secrets in the repository
• If a patched side is added in the future, it must use an official fixed artifact only