इसका मतलब था कि अनुरोध प्राधिकरण पास कर सकता था और फिर भी पीड़ित के अनुलग्नक को अधिलेखित कर सकता था।

यह मुद्दा CVE-2026-34213 बन गया।

Docmost: docmost/docmost
सलाहकार: GHSA-89fp-2hch-j9gp
CVE: CVE-2026-34213
पैच किया गया: v0.71.0 में

आक्रमण श्रृंखला

हमलावर-नियंत्रित pageId जिसमें संपादन पहुँच है -> हमलावर-नियंत्रित पीड़ित attachmentId -> दोषपूर्ण अधिलेखित गार्ड क्रॉस-पेज अधिलेखन को वैध मानता है -> पीड़ित attachmentId से भंडारण पथ पुनर्निर्मित -> हमलावर बाइट्स पीड़ित फ़ाइल को बदल देते हैं -> पीड़ित पृष्ठ संशोधित अनुलग्नक को परोसना जारी रखता है

Docmost का यह भाग क्या करता है

Docmost पृष्ठ अनुलग्नकों को डेटाबेस रिकॉर्ड और भंडारण में बैकिंग फ़ाइलों के रूप में संग्रहीत करता है।

सामान्य अपलोड के लिए, सर्वर एक नई अनुलग्नक आईडी बनाता है और एक नई फ़ाइल लिखता है।

हालाँकि, डायग्राम सेव/अपडेट फ़्लो के लिए, क्लाइंट जानबूझकर एक मौजूदा attachmentId का पुन: उपयोग करता है ताकि हर बार एक नया अनुलग्नक रिकॉर्ड उत्पन्न करने के बजाय उसी डायग्राम फ़ाइल को स्थान पर अद्यतन किया जा सके।

यह व्यवहार अपने आप में वैध है।

समस्या यह है कि यह एक उच्च-जोखिम वाला पथ बनाता है:

• एक इनपुट उस पृष्ठ की पहचान करता है जिसे अधिकृत किया जा रहा है
• दूसरा इनपुट उस अनुलग्नक की पहचान करता है जिसे अधिलेखित किया जा रहा है

जब भी कोई एंडपॉइंट इन दो जिम्मेदारियों को मिलाता है, तो कार्यान्वयन को उन्हें ठीक से एक साथ बाँधना चाहिए।

Docmost ने ऐसा नहीं किया।

यह सतह देखने लायक क्यों थी

मिश्रित क्रिएट/अपडेट एंडपॉइंट प्राधिकरण बग के लिए सामान्य स्थान हैं।

कारण सरल है:

• क्रिएट फ़्लो आमतौर पर कंटेनर ऑब्जेक्ट के विरुद्ध अधिकृत होते हैं
• अपडेट फ़्लो आमतौर पर मौजूदा रिकॉर्ड के विरुद्ध अधिकृत होते हैं
• यदि एक एंडपॉइंट दोनों करने का प्रयास करता है, तो पहले गलत चीज़ को मान्य करना और दूसरे पहचानकर्ता को "सिर्फ मेटाडेटा" मानना आसान है

यहाँ बिल्कुल यही पैटर्न है।

POST /api/files/upload ने मान्य किया कि कॉलर pageId द्वारा नामित पृष्ठ को संपादित कर सकता है।

लेकिन यदि attachmentId भी प्रदान किया गया था, तो सर्वर एक अधिलेखित पथ पर स्विच हो गया और एक मौजूदा अनुलग्नक रिकॉर्ड को अलग से चुना।

इसने महत्वपूर्ण सुरक्षा प्रश्न बनाया:

क्या अधिलेखित पथ यह साबित करता है कि चयनित अनुलग्नक वास्तव में अधिकृत पृष्ठ से संबंधित है?

कमजोर संस्करणों में उत्तर 'नहीं' था।

मूल कारण

मूल कारण एक उपयोगकर्ता-नियंत्रित कुंजी के माध्यम से प्राधिकरण बाईपास था, जो अधिलेखित गार्ड में एक बूलियन तर्क बग के साथ संयुक्त था।

कमजोर फ़्लो इस तरह दिखता था:

1. AttachmentController.uploadFile() ने मल्टीपार्ट फॉर्म डेटा से pageId पढ़ा।
2. उसने उस पृष्ठ को लोड किया और validateCanEdit(page, user) को कॉल किया।
3. उसने उसी अनुरोध से वैकल्पिक attachmentId को अलग से स्वीकार किया।
4. AttachmentService.uploadFile() ने हमलावर-प्रदत्त ID द्वारा मौजूदा अनुलग्नक को लोड किया।
5. अधिलेखित गार्ड ने यह सत्यापित करने का प्रयास किया कि मौजूदा अनुलग्नक अधिकृत पृष्ठ से मेल खाता है।
6. गार्ड ने किसी भी बेमेल को अस्वीकार करने के बजाय && का उपयोग किया।

कमजोर गार्ड था:

उस स्थिति ने केवल अनुरोध को अस्वीकार किया यदि:

• पृष्ठ आईडी बेमेल थी, और
• फ़ाइल एक्सटेंशन बेमेल था, और
• कार्यक्षेत्र आईडी बेमेल थी

एक साथ।

यह उसके विपरीत है जो एक अधिलेखित गार्ड को करना चाहिए।

वास्तविक हमले के मामले के लिए, हमलावर जानबूझकर उसी कार्यक्षेत्र के अंदर रहा।

इसलिए:

• existingAttachment.workspaceId !== workspaceId false था

एक बार वह ऑपरेंड false हो गया, तो पूरी && शर्त false का मूल्यांकन करती है, भले ही अनुलग्नक किसी अलग पृष्ठ से संबंधित हो।

इसलिए सर्वर ने क्रॉस-पेज अधिलेखन को वैध माना।

यह बग का पहला भाग था।

दूसरा भाग वह है जिसने प्रभाव को वास्तविक बनाया।

जाँच के बाद, सेवा ने हमलावर-प्रदत्त attachmentId और फ़ाइलनाम का उपयोग करके गंतव्य भंडारण पथ को पुनर्निर्मित किया:

फिर, अद्यतन पथ पर, Docmost ने केवल परिवर्तनीय मेटाडेटा को अद्यतन किया जैसे:

• fileSize
• updatedAt

इसने नहीं स्वामित्व को हमलावर पृष्ठ से पुन: बाँधा।

इसलिए पीड़ित पृष्ठ उसी अनुलग्नक रिकॉर्ड और उसी अनुलग्नक आईडी को इंगित करता रहा। केवल अंतर्निहित फ़ाइल बाइट्स बदल गए।

यही कारण है कि यह एक हानिरहित बेमेल नहीं था।

यह एक स्थायी अनधिकृत अधिलेखन प्रिमिटिव था।

यह एक सुरक्षा मुद्दा क्यों है, न कि सिर्फ एक तर्क गलती

यह एक कॉस्मेटिक बग नहीं था और फ़ाइलनाम टकराव का मुद्दा नहीं था।

हमलावर को रेस की आवश्यकता नहीं थी। हमलावर को यादृच्छिक पथ का अनुमान लगाने की आवश्यकता नहीं थी। हमलावर को पीड़ित पृष्ठ पर लिखने की पहुँच की आवश्यकता नहीं थी।

उन्हें केवल आवश्यकता थी:

• पीड़ित अनुलग्नक संदर्भ सीखने के लिए पढ़ने की पहुँच, और
• उसी कार्यक्षेत्र में किसी अन्य पृष्ठ पर लिखने की पहुँच

वहाँ से, वे किसी अन्य पृष्ठ के अनुलग्नक के लिए संग्रहीत फ़ाइल बाइट्स को बदल सकते थे, जबकि पीड़ित पृष्ठ उस अनुलग्नक को संदर्भित और परोसता रहता था जैसे कि कुछ भी नहीं बदला हो।

यह एक सीधी अखंडता विफलता है।

व्यावहारिक रूप में, हमलावर कर सकता था:

• डायग्राम से छेड़छाड़ करें
• अनुलग्नकों को भ्रामक सामग्री से बदलें
• संदर्भित फ़ाइलों को दूषित करें
• भ्रामक ऑडिट ट्रेल्स बनाएं क्योंकि अनुलग्नक अभी भी पीड़ित पृष्ठ से संबंधित दिखाई देता है

महत्वपूर्ण बिंदु यह है:

सर्वर ने हमलावर द्वारा चुने गए अधिलेखित लक्ष्य को स्वीकार किया, बिना उसे उस पृष्ठ से बाँधे जिसकी संपादन अनुमति वास्तव में जाँची गई थी।

यह एक पहुँच-नियंत्रण विफलता है, न कि केवल खराब बूलियन स्वच्छता।

शोषण व्यावहारिक क्यों था

डायग्राम अनुलग्नकों के लिए शोषण विशेष रूप से व्यावहारिक था।

Docmost का क्लाइंट डायग्राम सेव के लिए जानबूझकर attachmentId का पुन: उपयोग करता है और नियतात्मक फ़ाइलनाम का उपयोग करता है:

• diagram.excalidraw.svg
• diagram.drawio.svg

यह मायने रखता है क्योंकि यह हमलावर की आवश्यकताओं को कम करता है।

सामान्य अनुलग्नकों के लिए, हमलावर को दोनों की आवश्यकता होती है:

• पीड़ित अनुलग्नक आईडी
• पीड़ित फ़ाइलनाम

डायग्राम के लिए, फ़ाइलनाम पहले से ही अनुमानित है।

इसलिए यदि हमलावर पीड़ित पृष्ठ सामग्री पढ़ सकता है, तो वे अक्सर केवल एकमात्र लापता टुकड़ा प्राप्त कर सकते हैं:

• पीड़ित attachmentId

अपने सत्यापन सेटअप में, मैंने ठीक उसी पथ का उपयोग किया:

• हमलावर के पास पीड़ित स्थान पर केवल पाठक पहुँच थी
• हमलावर के पास एक अलग हमलावर-नियंत्रित स्थान पर लेखक पहुँच थी
• दोनों स्थान एक ही कार्यक्षेत्र से संबंधित थे

यह पर्याप्त था।

शोषण ने एक ही कार्यक्षेत्र के अंदर पृष्ठ सीमाओं और स्थान सीमाओं को पार किया, जबकि दोषपूर्ण कार्यक्षेत्र जाँच को संतुष्ट किया।

प्रूफ ऑफ कॉन्सेप्ट

मैंने Docmost v0.70.3 के विरुद्ध एक डिस्पोजेबल प्रयोगशाला का उपयोग करके लाइव मुद्दे को मान्य किया, जो docmost/docmost:0.70.3, Postgres और Redis से बनाई गई थी।

PoC प्रवाह था:

1. एक मालिक खाता बनाएं।
2. उसी कार्यक्षेत्र में एक पीड़ित स्थान और एक हमलावर-नियंत्रित स्थान बनाएं।
3. दूसरे उपयोगकर्ता को हमलावर के रूप में आमंत्रित करें।
4. हमलावर को अनुदान दें:
   • पीड़ित स्थान पर पाठक पहुँच
   • हमलावर-नियंत्रित स्थान पर लेखक पहुँच
5. पीड़ित स्थान में, एक पीड़ित पृष्ठ पर एक डायग्राम अनुलग्नक अपलोड करें।
6. हमलावर के रूप में, पीड़ित पृष्ठ जानकारी प्राप्त करें और पीड़ित attachmentId नोट करें।
7. भेजें POST /api/files/upload साथ:
   • pageId = हमलावर पृष्ठ आईडी
   • attachmentId = पीड़ित अनुलग्नक आईडी
   • file = पीड़ित फ़ाइलनाम का उपयोग करके हमलावर-नियंत्रित प्रतिस्थापन फ़ाइल
8. अधिलेखन से पहले और बाद में पीड़ित अनुलग्नक डाउनलोड करें और हैश की तुलना करें।

न्यूनतम अनुरोध आकार था:

देखा गया लाइव परिणाम था:

• हमलावर द्वारा सीखी गई पीड़ित अनुलग्नक आईडी: 019d18ae-b176-751c-8525-b5f3cede131d
• अधिलेखन अनुरोध के लिए उपयोग की गई हमलावर पृष्ठ आईडी: 019d18ae-b15b-70e9-ac67-64948e87cc5e
• पीड़ित मालिक पृष्ठ आईडी बनी रही: 019d18ae-b12f-75ec-8c1c-5aff3ba6be9c
• अधिलेखन अनुरोध का सर्वर प्रतिक्रिया: 200 OK
• अधिलेखन से पहले पीड़ित फ़ाइल SHA-256:

• अधिलेखन के बाद पीड़ित फ़ाइल SHA-256:

• हमलावर पेलोड SHA-256:

• माउंटेड स्टोरेज ने पुष्टि की कि पीड़ित पथ में अब शामिल है:

यह एक पूर्ण एंड-टू-एंड अधिलेखन प्रमाण है, न कि केवल एक सैद्धांतिक स्रोत समीक्षा।

PoC इस तरह क्यों चुना गया

मैंने ट्राइएज के दौरान दो प्रकार के प्रमाण का उपयोग किया:

• एक संकीर्ण स्टैंडअलोन हार्नेस जो कमजोर अधिलेखन तर्क को प्रतिबिंबित करता था, और
• एक डिस्पोजेबल Docmost इंस्टेंस के विरुद्ध पूर्ण लाइव HTTP शोषण

स्टैंडअलोन हार्नेस बूलियन तर्क विफलता को अलग करने के लिए उपयोगी था।

लाइव HTTP PoC मजबूत कलाकृति थी क्योंकि इसने पूर्ण सुरक्षा कहानी साबित की:

• पृष्ठ प्राधिकरण हमलावर पृष्ठ पर सफल हुआ
• पीड़ित attachmentId स्वीकार किया गया
• अधिलेखन अनुरोध सफलता लौटा
• पीड़ित पृष्ठ तार्किक स्वामी बना रहा
• डिस्क पर संग्रहीत बाइट्स हमलावर-नियंत्रित सामग्री में बदल गए

पहुँच-नियंत्रण बग में यह अंतर मायने रखता है।

"शर्त गलत है" अपने आप में पर्याप्त नहीं है।

"शर्त गलत है, और एप्लिकेशन को एंड-टू-एंड एक स्थायी अनधिकृत अधिलेखन में संचालित किया जा सकता है" पूरा मामला है।

फिक्स विश्लेषण

v0.71.0 में भेजा गया फिक्स और अधिलेखित गार्ड को && से || में बदल दिया गया:

वह पैच न्यूनतम, प्रत्यक्ष और रिपोर्ट किए गए बग के लिए सही है।

यह सही नियम को पुनर्स्थापित करता है:

अधिलेखन की अनुमति केवल तभी दी जाती है जब मौजूदा अनुलग्नक अधिकृत पृष्ठ/कार्यक्षेत्र/प्रकार की धारणाओं से बिल्कुल मेल खाता हो।

एक बार गार्ड किसी भी बेमेल पर अस्वीकार कर देता है:

• क्रॉस-पेज अधिलेखन विफल हो जाते हैं
• क्रॉस-वर्कस्पेस अधिलेखन विफल हो जाते हैं
• प्रकार/एक्सटेंशन बेमेल विफल हो जाते हैं

यह सही तरह का फिक्स था:

• कोई रीडिज़ाइन नहीं
• कोई अस्पष्ट संगतता तर्क नहीं
• "सर्वोत्तम प्रयास" से पुनर्प्राप्ति का कोई प्रयास नहीं

सिर्फ अधिकृत पृष्ठ और अधिलेखित लक्ष्य के बीच एक सख्त बंधन।

अभी भी एक व्यापक इंजीनियरिंग सबक है:

सामान्य अपलोड एंडपॉइंट जो इन-प्लेस अपडेट फ़्लो भी प्रदान करते हैं, उन्हें उच्च-जोखिम वाली API सतहों के रूप में माना जाना चाहिए।

भले ही तत्काल बग ठीक हो गया हो, मजबूत दीर्घकालिक डिज़ाइन हैं:

• डायग्राम सेव फ़्लो के लिए समर्पित अपडेट एंडपॉइंट
• फ़ाइलनाम के साथ-साथ अनुलग्नक आईडी पर अपरिवर्तनीय बंधन जाँच
• प्रतिगमन कवरेज जो स्पष्ट रूप से क्रॉस-पेज अधिलेखन प्रयासों को मॉडल करता है

लेकिन भेद्यता के लिए, प्रकाशित पैच ने मूल मुद्दे को साफ-सुथरा बंद कर दिया।

प्रतिगमन मामले जो मायने रखते हैं

भले ही परियोजना ने फिक्स के आसपास अपने स्वयं के निजी परीक्षण जोड़े हों, ये वे मामले हैं जो दीर्घकालिक कवरेज के लिए मायने रखते हैं:

• समान पृष्ठ आईडी और समान अनुलग्नक आईडी के साथ अधिलेखन सफल होना चाहिए
• भिन्न पृष्ठ आईडी और समान कार्यक्षेत्र के साथ अधिलेखन विफल होना चाहिए
• भिन्न कार्यक्षेत्र के साथ अधिलेखन विफल होना चाहिए
• बेमेल फ़ाइल एक्सटेंशन के साथ अधिलेखन विफल होना चाहिए
• ज्ञात डायग्राम फ़ाइलनाम लेकिन विदेशी अनुलग्नक आईडी का उपयोग करके अधिलेखन विफल होना चाहिए
• अधिलेखन को कभी भी हमलावर-नियंत्रित बाइट्स लिखे जाने के बाद पीड़ित स्वामित्व को चुपचाप संरक्षित नहीं करना चाहिए

इन परीक्षणों का उद्देश्य केवल शुद्धता नहीं है।

यह प्राधिकरण बंधन को लॉक करना है ताकि भविष्य के "सहायक" अपलोड रिफैक्टर उसी श्रेणी के बग को फिर से न खोलें।

गंभीरता और वर्गीकरण

प्रकाशित सलाहकार ने इस मुद्दे को वर्गीकृत किया:

• CWE-639: उपयोगकर्ता-नियंत्रित कुंजी के माध्यम से प्राधिकरण बाईपास
• CVSS v3.1:

यह 7.1 / उच्च पर उतरता है, जो सही निष्कर्ष है।

यहाँ महत्वपूर्ण मीट्रिक अखंडता है।

यह कोई निम्न-श्रेणी का मेटाडेटा बग नहीं था। हमलावर ने किसी अन्य पृष्ठ के अनुलग्नक पथ पर लिखे गए प्रतिस्थापन बाइट्स को पूरी तरह से नियंत्रित किया, और पीड़ित पृष्ठ उसके बाद संशोधित ऑब्जेक्ट को परोसता रहा।

यह ठीक वैसा ही संग्रहीत क्रॉस-रिकॉर्ड छेड़छाड़ है जो अखंडता उच्च का हकदार है।

उपलब्धता कम रहना भी समझ में आता है क्योंकि डायग्राम या संलग्न दस्तावेज़ को दूषित करने से पीड़ित सामग्री अनुपयोगी हो सकती है, लेकिन प्राथमिक प्रभाव अभी भी पूर्ण सेवा व्यवधान के बजाय अनधिकृत संशोधन है।

खुलासा

मैंने GitHub Security Advisories के माध्यम से निजी रूप से मुद्दे की सूचना दी:

• मूल-कारण विश्लेषण
• एक लाइव HTTP PoC
• अनुरोध/प्रतिक्रिया साक्ष्य
• पहले/बाद के फ़ाइल हैश
• एक पिन किया गया डिस्पोजेबल प्रयोगशाला सेटअप

मुद्दे को अनुरक्षक द्वारा स्वीकार किया गया, CVE-2026-34213 सौंपा गया, और 14 अप्रैल, 2026 को प्रकाशित किया गया।

सार्वजनिक सलाहकार सूचीबद्ध करता है:

• प्रभावित संस्करण: >= v0.3.0
• पैच किया गया संस्करण: v0.71.0

वह इतिहास मेरी स्थानीय स्रोत समीक्षा से भी मेल खाता था: कमजोर अधिलेखन तर्क सबसे शुरुआती टैग किए गए रिलीज़ में मौजूद था जिसे मैंने कमजोर लाइन में जाँचा था।

यह बग वास्तव में क्या सिखाता है

यहाँ दिलचस्प सबक केवल "|| को && के बजाय उपयोग करें" नहीं है।

वह लक्षण है।

गहरा सबक है:

यदि एक उपयोगकर्ता-नियंत्रित क्षेत्र प्राधिकरण साबित करता है और दूसरा उपयोगकर्ता-नियंत्रित क्षेत्र अद्यतन किए जा रहे ऑब्जेक्ट का चयन करता है, तो उन दो क्षेत्रों को स्पष्ट रूप से और ठीक से एक साथ बाँधा जाना चाहिए।

वह नियम हर जगह दिखाई देता है:

• दस्तावेज़ अनुलग्नक
• प्रोफ़ाइल मीडिया
• क्लाउड ऑब्जेक्ट संदर्भ
• मुद्दा/टिप्पणी संपादन
• बैकग्राउंड जॉब पुनर्प्रसंस्करण

जिस क्षण कोई सिस्टम कहता है:

• "आप पृष्ठ X संपादित कर सकते हैं"
• "कृपया मुझे यह भी बताएं कि कौन सा मौजूदा रिकॉर्ड अपडेट करना है"

इसने एक सुरक्षा सीमा बनाई है जिसे सटीक-मैच अपरिवर्तनीयताओं के साथ लागू किया जाना चाहिए।

इससे नरम कुछ भी जल्दी या बाद में उपयोगकर्ता-नियंत्रित-कुंजी बग में बदल जाता है।

यह मुद्दा दूसरे बिंदु को भी पुष्ट करता है जिसे कम आंकना आसान है:

गार्ड कोड में छोटी बूलियन गलतियों के प्रथम-क्रम सुरक्षा परिणाम हो सकते हैं।

एक तीन-खंड की शर्त जो पहली नज़र में "उचित लगती है", अधिलेखित पथ के लिए सुरक्षा मॉडल को उलटने के लिए पर्याप्त थी।

यही कारण है कि ये सतहें आकस्मिक विश्वास के बजाय जानबूझकर समीक्षा की हकदार हैं।

मुख्य बिंदु

• Docmost ने नए अपलोड और इन-प्लेस अनुलग्नक अद्यतन दोनों के लिए एक एंडपॉइंट का उपयोग किया।
• प्राधिकरण कॉलर-प्रदत्त pageId के विरुद्ध जाँचा गया था, लेकिन अधिलेखित लक्ष्य चयन एक अलग कॉलर-प्रदत्त attachmentId का उपयोग करता था।
• अधिलेखित गार्ड ने केवल तभी अस्वीकार किया जब सभी बेमेल शर्तें एक साथ सत्य थीं।
• उसी-कार्यक्षेत्र हमले के मामले में, वह जाँच खुली विफल हुई।
• सेवा ने पीड़ित अनुलग्नक आईडी से भंडारण पथ का पुनर्निर्माण किया और उसमें हमलावर-नियंत्रित बाइट्स लिखे।
• अनुलग्नक रिकॉर्ड अधिलेखन के बाद पीड़ित पृष्ठ से बंधा रहा।
• नियतात्मक डायग्राम फ़ाइलनाम ने शोषण को विशेष रूप से व्यावहारिक बना दिया।
• v0.71.0 में फिक्स ने गार्ड को किसी भी बेमेल पर अस्वीकार करने के लिए सही ढंग से बदल दिया।

अंतिम शब्द

यह भेद्यता विदेशी भंडारण व्यवहार के बारे में नहीं थी।

यह एक अद्यतन पथ के बारे में था जो एक हमलावर-चयनित ऑब्जेक्ट पहचानकर्ता पर अधिक भरोसा करता था जितना उसे करना चाहिए था।

Docmost ने एक पृष्ठ पर संपादन पहुँच साबित की, दूसरे पृष्ठ से एक मौजूदा अनुलग्नक आईडी स्वीकार की, और फिर एक दोषपूर्ण अधिलेखन जाँच को उस बेमेल को एक सफल क्रॉस-पेज फ़ाइल प्रतिस्थापन में बदलने दिया।

यही कारण है कि यह CVE-2026-34213 बन गया।

v0.71.0 में पैच ने तत्काल मुद्दे को साफ-सुथरा ठीक किया, लेकिन व्यापक सबक मूल्यवान बना हुआ है:

जब प्राधिकरण और ऑब्जेक्ट चयन अलग-अलग उपयोगकर्ता-नियंत्रित क्षेत्रों में विभाजित होते हैं, तो सटीक बंधन सुरक्षा संपत्ति है।