
Reproduzierbares Labor für CVE-2026-33017, eine nicht authentifizierte RCE in Langflow. Enthält einen dockerisierten verwundbaren Dienst und einen PoC mit minimalem Schadenspotenzial, der die Codeausführung über den öffentlichen Build-Endpunkt demonstriert.
CVE-2026-33017 ist eine Unauthenticated Remote Code Execution (RCE)-Schwachstelle in Langflow, bei der ein öffentlicher Build-Endpunkt vom Angreifer kontrollierte Flow-Daten akzeptiert und dadurch die Ausführung von benutzerdefiniertem Komponentencode auf dem Server ermöglicht.
In diesem Labor sieht der Validierungsablauf wie folgt aus:
PUBLIC-Flowsjob_idDer Proof wird direkt über den Langflow-API-Events-Mechanismus abgerufen, wodurch das Ergebnis über die Systemoberfläche selbst beobachtbar ist.
Dieses Dokument stellt ein reines Schwachstellen-Labor dar.
Derzeit enthält docker compose nur einen Dienst: vuln, da dieses Projekt einem -Ansatz folgt und gepatchte Umgebungen vermeidet, die nicht auf einem offiziellen behobenen Artefakt basieren.
Das folgende Verhalten wurde in diesem Labor verifiziert:
http://localhost:78611.8.1 zurückbuild_public_tmp gibt eine job_id zurückBeispiel-Proof-Objekt:
{
"canary": "lf33017-c14fc1c9",
"id_output": "uid=1000(user) gid=0(root) groups=0(root)",
"whoami": "user",
"hostname": "155aa3fd5e2a",
"cwd": "/app",
"python_version": "3.12.12"
}
Die wichtigsten Beweise sind:
id_outputwhoamihostnamecwdpython_versionDie obigen Informationen zeigen, dass vom Angreifer kontrollierter Code tatsächlich serverseitig ausgeführt wurde.
.
├── docker-compose.yml
├── vuln/
│ └── Dockerfile
├── poc/
│ └── poc.py
├── README.md
└── .gitignore
7861 -> 7860Diese Schwachstelle existiert, weil Langflows öffentlicher Build-Endpunkt vom Benutzer bereitgestellte Flow-Definitionen akzeptiert, obwohl der Endpunkt bereits für öffentliche Flows konzipiert ist. Wenn ein Angreifer eine Knotendefinition mit benutzerdefiniertem Komponentencode übermittelt, leitet das System diesen Code in den Flow-Build-Pfad, was letztendlich zur Codeausführung auf dem Server führt.
Der PoC in diesem Projekt verwendet eine benutzerdefinierte Komponente, die ein Proof-Objekt in ihrer Ausgabe zurückgibt, um zu demonstrieren, dass vom Angreifer kontrollierter Code tatsächlich ausgeführt wird.
Der PoC in diesem Projekt ist auf minimalen Schaden ausgelegt und konzentriert sich auf klar beobachtbare Beweise über die API. Sein Ablauf ist wie folgt:
PUBLIC-Flowsjob_idDieser PoC deckt nicht ab:
docker compose up -d --build
curl -i http://localhost:7861/api/v1/version
python3 poc/poc.py --base-url http://localhost:7861 --artifact-dir ./artifacts/vuln
Wenn der PoC erfolgreich ist, sieht die Ausgabe wie folgt aus:
[+] http://localhost:7861 ready (version=1.8.1)
=== TARGET: vuln ===
Base URL : http://localhost:7861
Version : 1.8.1
Flow ID : <uuid>
HTTP : 200
Job ID : <uuid>
Canary : lf33017-xxxxxxxx
Events : artifacts/vuln/events-<job_id>.ndjson
Polls : 2
[+] Proof observed through the Langflow API events endpoint:
{
"canary": "lf33017-xxxxxxxx",
"id_output": "uid=1000(user) gid=0(root) groups=0(root)",
"whoami": "user",
"hostname": "<container-hostname>",
"cwd": "/app",
"python_version": "3.12.x"
}
[+] Vulnerable behavior observed
Die Datei artifacts/vuln/events-<job_id>.ndjson speichert rohe Event-Daten für zusätzliche Debugging-Zwecke.
Dieser PoC demonstriert, dass:
Dieser PoC ist nicht dazu gedacht, Persistenz oder fortgeschrittene Post-Exploitation zu demonstrieren, und hält die Auswirkung auf dem minimalen Niveau, das zur Validierung der Schwachstelle erforderlich ist.
Basierend auf diesem Labor ist die demonstrierte Auswirkung:
Dieses Repository enthält bewusst keinen gepatchten Dienst.
Sein Umfang beschränkt sich auf die Reproduktion des verwundbaren Verhaltens auf einem echten Upstream-Artefakt. Eine gepatchte Seite wird nur hinzugefügt, wenn ein klar verifizierbares offizielles behobenes Artefakt vom Hersteller oder Upstream-Projekt verfügbar ist.
Aus diesem Grund vermeidet dieses Repository bewusst:
Dies hält das Labor eng umrissen und technisch ehrlich. Anstatt ein künstliches Side-by-Side-Setup zu präsentieren, konzentriert sich das Repository auf drei Dinge:
In der Praxis macht dies das Repository am besten geeignet für:
docker compose down -v
Dieses Labor ist nur für Tests auf localhost konzipiert.
Nutzungsanforderungen: