
Lokales Docker-Labor zur Reproduktion von CVE-2026-55255, einer IDOR-Schwachstelle in Langflows Responses API. Validiert die Ausführung von Cross-User-Flows in verwundbaren und gepatchten Versionen anhand eines requestbasierten PoC.
/api/v1/responsesDieses Repository enthält ein lokales Docker-Labor zur Reproduktion und Validierung von CVE-2026-55255, einer Schwachstelle durch unsichere direkte Objektreferenz (IDOR), die die OpenAI-kompatible Responses-API von Langflow betrifft.
Langflow ist eine Open-Source-Plattform zum Erstellen und Bereitstellen von KI-gestützten Agenten und Workflows. Das angreifbare Verhalten betrifft den Endpunkt /api/v1/responses, bei dem ein authentifizierter Angreifer die Flow-UUID eines anderen Benutzers als model-Wert angeben kann und Langflow dazu bringt, diesen fremden Flow auszuführen.
Dieses Labor vergleicht zwei Langflow-Versionen:
| Dienst | Langflow-Version | Zweck | URL |
|---|---|---|---|
| vuln | 1.9.0 | Angreifbares Vergleichsziel | http://localhost:7860 |
| patched | 1.9.1 | Gepatchtes Vergleichsziel | http://localhost:7861 |
Der demonstrierte HTTP-Validierungspfad in diesem lokalen Labor ist:```text Authenticated attacker API key → POST /api/v1/responses → request body sets model to victim-owned flow UUID → vulnerable target executes the victim-owned flow → patched target returns flow_not_found and does not execute the victim-owned flow
Im anfälligen Ziel kann der dem Angreifer gehörende API-Schlüssel den dem Opfer gehörenden Flow ausführen, und die Antwort enthält den nur für das Opfer bestimmten Marker:```text
VICTIM_ONLY_CONTEXT_55255_VULN
Im gepatchten Ziel gibt dieselbe Cross-User-Anfrage den Opfer-Marker nicht zurück und gibt einen OpenAI-artigen Fehlertext zurück:```json {"error":{"message":"Flow with id '' not found","type":"invalid_request_error","code":"flow_not_found"}}
Dieses Labor validiert das verwundbare versus gepatchte HTTP-Verhalten mit Langflow 1.9.0 und Langflow 1.9.1.
Das Labor ist absichtlich auf lokale Docker-Dienste beschränkt. Es zielt nicht auf externe Systeme ab und beinhaltet keinen Diebstahl von Anmeldeinformationen, Datenbank-Dumping, zerstörerische Payloads, externe Callbacks, Malware, Persistenz oder Post-Exploitation-Aktivitäten.
## Bestätigte Fakten
| Behauptung | Beweis | Wie man es in diesem Labor überprüft |
| ----- | -------- | ------------------------- |
| CVE-2026-55255 betrifft den `/api/v1/responses`-Endpunkt von Langflow. | Das GitHub Advisory GHSA-qrpv-q767-xqq2 beschreibt eine IDOR in `/api/v1/responses`. | Überprüfen Sie den Abschnitt 'References' und führen Sie den PoC gegen beide lokalen Ziele aus. |
| Das GitHub Advisory listet betroffene Versionen als `< 1.9.1` und gepatchte Version als `1.9.1`. | GitHub Advisory GHSA-qrpv-q767-xqq2. | Vergleichen Sie die verwundbaren und gepatchten Zielversionen in `docker-compose.yml`. |
| Einige nachgelagerte Schwachstellenquellen sind sich über die genaue behobene Version uneinig. | GitHub/GitLab führen `1.9.1` als behoben auf; einige nachgelagerte Intelligence-Seiten erwähnen `1.9.2` oder enthalten gemischte Formulierungen. | Überprüfen Sie den Abschnitt 'References' und verlassen Sie sich auf die Laborvalidierung für das getestete 1.9.1-Verhalten. |
| Dieses Labor verwendet Langflow 1.9.0 als verwundbares Vergleichsziel. | Der `vuln`-Dienst verwendet `langflowai/langflow:1.9.0`. | Überprüfen Sie `docker-compose.yml` und führen Sie `docker compose ps` aus. |
| Dieses Labor verwendet Langflow 1.9.1 als gepatchtes Vergleichsziel. | Der `patched`-Dienst verwendet `langflowai/langflow:1.9.1`. | Überprüfen Sie `docker-compose.yml` und führen Sie `docker compose ps` aus. |
| Die Responses API von Langflow verwendet `POST /api/v1/responses`. | Die Langflow-Dokumentation beschreibt den OpenAI-kompatiblen Responses API-Endpunkt. | Führen Sie den PoC oder eine manuelle curl-Anfrage gegen `/api/v1/responses` aus. |
| Die Responses API von Langflow akzeptiert eine Flow-ID als `model`-Wert. | Die Langflow-Dokumentation gibt an, dass der `model`-Wert durch eine `flow_id` ersetzt wird. | Überprüfen Sie den PoC-Anfragetext. |
| Langflow-API-Anfragen erfordern einen API-Key über `x-api-key`. | Die Langflow-API-Dokumentation beschreibt die API-Key-Authentifizierung mit dem `x-api-key`-Header. | Überprüfen Sie die PoC-Anfrageheader. |
| Der PoC ist anfragebasiert. | `poc/validate_idor.py` sendet HTTP-Anfragen und ruft keine Docker-, Docker-Compose-, Shell-Befehle oder Container-APIs auf. | Überprüfen Sie `poc/validate_idor.py`. |
| Das verwundbare Ziel führt einen vom Opfer stammenden Flow mit einem vom Angreifer stammenden API-Key aus. | Die verwundbare Antwort gibt `VICTIM_ONLY_CONTEXT_55255_VULN` zurück. | Führen Sie den verwundbaren PoC-Befehl mit der Flow-ID des Opfers und dem API-Key des Angreifers aus. |
| Das gepatchte Ziel blockiert denselben Cross-User-Ausführungspfad. | Die gepatchte Antwort gibt `error.code = flow_not_found` zurück und gibt den Opfer-Marker nicht zurück. | Führen Sie den gepatchten PoC-Befehl mit der Flow-ID des Opfers und dem API-Key des Angreifers aus. |
## Annahmen und Unbekanntes
Dieses Labor verwendet Langflow 1.9.0 als verwundbares Vergleichsziel, da das GitHub Advisory GHSA-qrpv-q767-xqq2 Versionen vor 1.9.1 als betroffen identifiziert und lokale Tests das verwundbare Verhalten in 1.9.0 bestätigt haben.
Dieses Labor verwendet Langflow 1.9.1 als gepatchtes Vergleichsziel, da das GitHub Advisory GHSA-qrpv-q767-xqq2 1.9.1 als gepatchte Version aufführt und lokale Tests bestätigt haben, dass 1.9.1 den getesteten Cross-User `/api/v1/responses`-Ausführungspfad mit `flow_not_found` blockiert.
Es gibt eine Versionsdiskrepanz zwischen den Quellen. GitHub- und GitLab-Advisories listen Versionen vor 1.9.1 als betroffen und 1.9.1 als behoben. Einige nachgelagerte Schwachstellen-Intelligence-Seiten erwähnen 1.9.2 oder enthalten gemischte Formulierungen bezüglich der behobenen Version. Dieses Repository dokumentiert diese Diskrepanz und validiert das getestete Verhalten direkt:```text
Langflow 1.9.0
→ attacker API key + victim flow UUID
→ victim marker returned
→ vulnerable behavior observed
Langflow 1.9.1
→ attacker API key + victim flow UUID
→ flow_not_found
→ victim marker not returned
→ blocked behavior observed
Dieses Labor geht davon aus, dass der Angreifer bereits eine Opfer-Flow-UUID kennt. Der PoC führt keine Brute-Force-Angriffe auf Flow-IDs durch, keine Enumeration von Flows und versucht nicht, Opfer-Flow-IDs zu entdecken.
Dieses Labor konzentriert sich auf das beobachtbare HTTP-Verhalten von:```text POST /api/v1/responses
mit dieser Anfrageform:```json
{
"model": "<victim-flow-id>",
"input": "cross-user CVE-2026-55255 validation request",
"stream": false
}
Das Labor demonstriert die nicht autorisierte Ausführung von Cross-User-Flows im anfälligen Ziel und das blockierte Verhalten im gepatchten Ziel.
Das Labor demonstriert nicht:
Die Grundursache von CVE-2026-55255 ist eine Autorisierungslücke in der Flow-Auflösungslogik von Langflow.
Der Endpunkt /api/v1/responses akzeptiert eine Flow-UUID über das Feld model. In anfälligen Versionen konnte der UUID-Suchpfad innerhalb von get_flow_by_id_or_endpoint_name() ein Flow-Objekt direkt über den Primärschlüssel laden, ohne durchzusetzen, dass die aufgelöste Flow.user_id mit dem authentifizierten API-Key-Benutzer übereinstimmte.
Das anfällige Verhalten kann wie folgt zusammengefasst werden: