CVE-2026-38361: dash-uploader में कई बिना प्रमाणीकरण वाली DoS भेद्यताएँ

fohrloop/dash-uploader (Python, PyPI) में कई बिना प्रमाणीकरण वाली डिनायल ऑफ़ सर्विस (DoS) समस्याएँ हैं, जिनमें (केवल यही नहीं) आउट-ऑफ़-मेमोरी (OOM) प्रोसेस क्रैश, फ़ाइल का शून्य बाइट्स में ट्रंकेशन, स्थायी डिस्क क्षरण और दस्तावेज़ित max_file_size सीमा का पूर्ण बायपास शामिल है। उसी बिना सैनिटाइज़ किए गए पैरामीटर सेट के माध्यम से अतिरिक्त संसाधन-दुरुपयोग पथ भी मौजूद हैं।

⚠️ कोई पैच उपलब्ध नहीं है, और भविष्य में कोई पैच जारी नहीं किया जाएगा

रिपॉज़िटरी को बिना किसी सक्रिय अनुरक्षक के 2025-07-19 को संग्रहीत किया गया था। प्रकाशित हर संस्करण (0.1.0 से 0.7.0a2 तक) प्रभावित है और रहेगा। पैकेज अभी भी लगभग 28,000 मासिक डाउनलोड प्राप्त करता है।

प्रोडक्शन में dash-uploader चलाने वाले किसी भी व्यक्ति को स्वयं शमन (mitigation) लागू करना होगा। अनुशंसित समाधान Plotly Dash के अंतर्निहित dcc.Upload घटक पर माइग्रेट करना है। पूर्ण विकल्पों के लिए शमन देखें।

CVE ID	CVE-2026-38361 (NVD)
भेद्यता	अनियंत्रित संसाधन खपत (CWE-400), हमेशा-गलत नियंत्रण प्रवाह कार्यान्वयन (CWE-670)
CVSS 3.1	7.5 / उच्च (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
उत्पाद	dash-uploader
प्रभावित संस्करण	0.1.0 से 0.7.0a2 तक (सभी 18 रिलीज़)
फिक्स्ड संस्करण	कोई नहीं (प्रोजेक्ट 2025-07-19 को संग्रहीत)
आक्रमण वेक्टर	दूरस्थ, बिना प्रमाणीकरण
खोजकर्ता	Muhammad Fitri Bin Mohd Sultan
निर्धारक	MITRE, 2026-05-07
संबंधित	CVE-2026-38360 (उसी लाइब्रेरी में पाथ ट्रैवर्सल)

विवरण

dash-uploader HTTP हैंडलर बिना प्रमाणीकरण वाले POST अनुरोधों को स्वीकार करता है, जिनमें हमलावर-नियंत्रित पैरामीटर मेमोरी आवंटन, फ़ाइल संचालन और निर्देशिका निर्माण में प्रवाहित होते हैं, बिना किसी बाउंड जाँच, बिना दर सीमा और बिना किसी सफाई तंत्र के। उसी कोड पथ में चार स्वतंत्र समस्याएँ हैं:

1. OOM क्रैश (सत्यापित)

7.7 GB सिस्टम पर सत्यापित: resumableTotalChunks=30000000 वाले 5 समवर्ती POST अनुरोधों ने 2 सेकंड के भीतर Linux OOM किलर को सक्रिय कर दिया। कर्नेल लॉग पुष्टि करता है:

Out of memory: Killed process 24203 (python3) total-vm:8302276kB, anon-rss:7068012kB

प्रत्येक अनुरोध range(1, resumableTotalChunks + 1) पर लिस्ट कॉम्प्रिहेंशन के माध्यम से लगभग 2.9 GB मेमोरी आवंटित करता है। सर्वर प्रोसेस समाप्त कर दिया जाता है और मैन्युअल पुनःआरंभ तक एप्लिकेशन पूरी तरह अनुपलब्ध हो जाता है।

2. फ़ाइल ट्रंकेशन (सत्यापित)

42 बाइट्स डेटा वाली एक फ़ाइल को resumableTotalChunks=0 वाले एक एकल POST अनुरोध के माध्यम से 0 बाइट्स तक कम कर दिया गया। मूल कारण यह है कि Python का all() खाली इटरेबल्स के लिए True लौटाता है, जो अपलोड हैंडलर को शून्य चंक्स को पूर्ण अपलोड मानने में धोखा देता है। मौजूदा फ़ाइल को os.unlink() के माध्यम से हटा दिया जाता है और एक खाली फ़ाइल से बदल दिया जाता है।

3. परित्यक्त अपलोड संचय (सत्यापित)

चंक फ़ाइलों वाली 10 अनाथ अस्थायी निर्देशिकाएँ बनाई गईं और डिस्क पर अनिश्चित काल तक बनी रहीं। सभी स्रोत फ़ाइलों में cleanup, ttl, expire, garbage, purge, cron, schedule और periodic के लिए कोडबेस-व्यापी खोज में शून्य परिणाम मिले। एकमात्र सफाई कॉल (shutil.rmtree) केवल पूर्ण अपलोड पर निष्पादित होती है। अधूरे सत्रों से डिस्क स्थान पुनः प्राप्त करने का कोई तंत्र नहीं है।

4. max_file_size बायपास (सत्यापित)

सर्वर ने HTTP 200 के साथ resumableTotalSize=999999999999 (~999 GB) का दावा करने वाली फ़ाइल के लिए 5 MB चंक स्वीकार किया। max_file_size पैरामीटर केवल React JavaScript घटक को भेजा जाता है। सर्वर कभी भी फ़ाइल आकार, चंक आकार, Content-Length या Flask MAX_CONTENT_LENGTH की जाँच नहीं करता। max_file_size=10 सेट करने वाले डेवलपर के पास कोई सर्वर-साइड सुरक्षा नहीं है।

कमज़ोर कोड

# dash_uploader/httprequesthandler.py
def _post(self):
    resumableTotalChunks = request.form.get("resumableTotalChunks", type=int)   # attacker-controlled, no bounds
    ...
    chunk_paths = [
        os.path.join(temp_dir, get_chunk_name(resumableFilename, x))
        for x in range(1, resumableTotalChunks + 1)                              # unbounded; e.g. 30M -> ~2.9 GB -> OOM
    ]
    upload_complete = all([os.path.exists(p) for p in chunk_paths])              # all([]) is True -> truncation when chunks=0
    if upload_complete:
        target_file_name = os.path.join(temp_root, resumableFilename)
        if os.path.exists(target_file_name):
            os.unlink(target_file_name)                                          # existing file deleted
        with open(target_file_name, "ab") as target_file:
            for p in chunk_paths:                                                # empty list -> empty file written
                ...

समान कोड पथ OOM (बड़ा resumableTotalChunks) और फ़ाइल-ट्रंकेशन प्रिमिटिव (resumableTotalChunks=0) दोनों उत्पन्न करता है।

आक्रमण वेक्टर

एक हमलावर /API/resumable एंडपॉइंट पर बिना प्रमाणीकरण वाले POST अनुरोध भेजता है।

• OOM क्रैश: resumableTotalChunks=30000000 वाले 5 समवर्ती अनुरोध प्रत्येक ~2.9 GB आवंटित करते हैं, जिससे OOM किलर सक्रिय हो जाता है।
• डिस्क क्षरण: अपलोड शुरू करें लेकिन उन्हें कभी पूरा न करें; अनाथ अस्थायी फ़ाइलें हमेशा के लिए जमा होती रहती हैं।
• फ़ाइल ट्रंकेशन: resumableTotalChunks=0 भेजें; Python all([])=True सर्वर को लक्षित फ़ाइल को खाली सामग्री से अधिलेखित करने में धोखा देता है।
• आकार बायपास: डेवलपर द्वारा निर्धारित कोई भी आकार सीमा केवल क्लाइंट JavaScript में लागू होती है, इसलिए एक सीधा HTTP अनुरोध इसे पूरी तरह बायपास कर देता है।

कोई प्रमाणीकरण या विशेषाधिकार आवश्यक नहीं है।

प्रभाव

• एकल उपयोगकर्ता-नियंत्रित POST पैरामीटर (resumableTotalChunks) से असीमित मेमोरी आवंटन द्वारा ट्रिगर Linux OOM किलर के माध्यम से सर्वर प्रोसेस क्रैश
• परित्यक्त अपलोड सत्रों के माध्यम से स्थायी डिस्क क्षरण जिन्हें कभी साफ नहीं किया जाता (कोडबेस में कोई TTL, कोई गार्बेज कलेक्शन, कोई समाप्ति तंत्र नहीं है)
• बिना सैनिटाइज़ किए resumableIdentifier के साथ os.makedirs() के माध्यम से मनमानी गहराई की निर्देशिका निर्माण द्वारा फ़ाइलसिस्टम inode क्षरण
• जब resumableTotalChunks=0 हो, तो खाली इटरेबल्स के लिए Python all() का True लौटाना फ़ाइल के शून्य बाइट्स में ट्रंकेशन के माध्यम से डेटा विनाश का कारण बनता है
• सभी फ़ाइल आकार प्रतिबंधों का बायपास क्योंकि max_file_size केवल क्लाइंट-साइड JavaScript में लागू होता है, जबकि सर्वर-साइड हैंडलर कोई आकार सत्यापन नहीं करता और कभी Flask MAX_CONTENT_LENGTH सेट नहीं करता

प्रभावित घटक