FlawOpen

flawopen.com/Teardowns/cve-2026-5027-langflow-multipart-file-write

● CVE-2026-5027 · CVSS 8.8[1], [2] · उच्च
सुरक्षा अनुसंधान · FlawOpen

Langflow CVE-2026-5027: अपलोड में path traversal

CVE-2026-5027 में path traversal से Langflow upload area के बाहर फ़ाइल लिखी जा सकती थी। GTIG ने शोषण की सूचना दी; 1.9.0 या नए संस्करण पर जाएँ।[1], [2], [6]

CVSS वेक्टरCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H[1], [2]
💡 आसान भाषा में (ELI5)

डाकघर ऐसा पार्सल लेता है जिसका लेबल और गंतव्य भेजने वाला चुनता है। यदि कर्मचारी अंतिम पता जाँचे बिना उस लेबल को डाकघर के फ़ोल्डर से जोड़ दे, तो पार्सल बाहर जा सकता है। Langflow का upload route multipart फ़ाइल नाम पर भरोसा करता था, और storage layer यह अलग से नहीं जाँचती थी कि अंतिम path अनुमत फ़ोल्डर के भीतर है।[2], [3]

इस पेज के मुख्य शब्द

CVE-2026-5027
Langflow के POST /api/v2/files multipart नाम में path traversal के लिए Tenable का दिया पहचानकर्ता: CWE-22, CVSS 3.1 8.8 और कम विशेषाधिकार आवश्यक।[1], [2]
Multipart फ़ाइल नाम
Multipart upload के Content-Disposition में client द्वारा दिया नाम। यह अविश्वसनीय इनपुट है, सुरक्षित फ़ाइल path नहीं।[1], [2]
Path containment
फ़ाइल बनाने या लिखने से पहले candidate path को resolve करके साबित करना कि वह अनुमत storage directory के भीतर ही है।[3], [4], [7]
पहचानकर्ता नोट
Langflow का संबंधित GHSA CVE-2026-33309 सूचीबद्ध करता है, जबकि Tenable और Google GTIG CVE-2026-5027 उपयोग करते हैं। यह लेख GTIG पहचानकर्ता का पालन करता है और दोनों रिकॉर्ड को बिना चुपचाप मिलाए स्रोतों में रखता है।[4], [5], [6]

फ्रेमवर्क मैपिंग

  • इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-22

मूल कारण विश्लेषण (Root Cause)

Tenable का CVE-2026-5027 रिकॉर्ड बताता है कि POST /api/v2/files traversal घटकों वाला multipart नाम स्वीकार कर इच्छित directory के बाहर लिख सकता था। सुरक्षा सीमा API route और local storage दोनों में है: URL parameter validation, multipart Content-Disposition से आए नाम को validate नहीं करती; नाम को folder से जोड़ना containment सिद्ध नहीं करता। CVE vector में कम privilege (PR:L) आवश्यक है; यह दावा न करें कि CVE स्वयं authentication bypass करती है। Google GTIG CVE-2026-5027 को वास्तविक हमलों में पुष्ट शोषण वाली कमजोरियों में रखता है, लेकिन उसका सार्वजनिक सार सार्वभौमिक code execution सिद्ध नहीं करता। Arbitrary file write का अधिक गंभीर असर writable paths, process privileges और deployment configuration पर निर्भर है; इसे conditional impact कहें, guaranteed RCE नहीं। Langflow का संबंधित GHSA CVE-2026-33309 सूचीबद्ध करता है और 1.9.0 fix की ओर संकेत करता है। यह लेख Tenable और GTIG के अनुसार CVE-2026-5027 इस्तेमाल करता है और identifier अंतर स्पष्ट रखता है। Langflow के merged patch में API पर नाम validation और storage layer में canonical path containment है, directory creation से पहले भी।[1], [2], [3], [4], [5], [6]

हमले का चरण-दर-चरण प्रवाह

चरण 1

कम privilege वाला उपयोगकर्ता upload API तक पहुँचता है

CVE-2026-5027 का CVSS vector कम privilege माँगता है। प्रभावित route POST /api/v2/files है; रिकॉर्ड authentication bypass स्थापित नहीं करता।[1], [2]

चरण 2

Request multipart फ़ाइल नाम देती है

नाम client-controlled Content-Disposition metadata से आता है। URL parameter जाँच इस अलग input source को sanitize नहीं करती।[1], [2], [4]

चरण 3

Path storage boundary पार करता है

Canonical containment जाँच के बिना traversal components upload directory के बाहर resolve हो सकते हैं।[1], [2], [3], [7]

चरण 4

Root के बाहर फ़ाइल लिखी जाती है

दस्तावेज़ित असर arbitrary file write है। Code execution writable paths, process privileges और deployment पर निर्भर है; हर upload को RCE न मानें।[1], [2], [6]

चरण 5

दोनों validation boundaries ठीक करें

Langflow ने API filename validation और storage canonical containment को 1.9.0 release line में merge किया। Update करें और installed packages तथा running image जाँचें।[2], [3], [4]

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

ये source-shaped संक्षिप्त उदाहरण हैं, upstream का शब्दशः diff नहीं। कमजोर flow client के filename को storage path मानता है। सुरक्षित pattern नाम validate करता है और storage layer में canonical destination को canonical root के भीतर जाँचता है; upstream PR separators और control characters भी रोकता है तथा directory बनाने से पहले containment जाँचता है। HTTP layer validation के बावजूद storage जाँच बनाए रखें। उदाहरण के लिए Path.is_relative_to वाला Python चाहिए और hostile writable directories में यह अकेले check/use race नहीं रोकता। Production में race-resistant file operations और सख्त permissions रखें। सुरक्षा path containment है, केवल filename blacklist नहीं।[3], [2], [4], [7]

सोर्स अंश: Langflow api/v2/files.py और services/storage/local.py — security boundary का संक्षिप्त उदाहरण

कमज़ोर कार्यान्वयन
# vulnerable data flow का सरल उदाहरण।
new_filename = file.filename
file_path = folder_path / new_filename
await write_upload(file, file_path)
सुरक्षित और सुदृढ़ फ़िक्स
from pathlib import Path

def confined_upload_path(root: Path, client_name: str | None) -> Path:
    name = Path(client_name or "").name
    if not name or name in {".", ".."} or chr(0) in name:
        raise ValueError("invalid upload filename")

    base = root.resolve()
    target = (base / name).resolve()
    if not target.is_relative_to(base):
        raise ValueError("upload path escapes storage root")
    return target

# बनाने या लिखने से ठीक पहले storage boundary पर इसे call करें।
target = confined_upload_path(upload_root, file.filename)
await write_upload(file, target)

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

स्रोत