वह समस्या CVE-2026-34212 बन गई।

Docmost: docmost/docmost
सलाहकार: GHSA-cf68-cff9-hq4w
CVE: CVE-2026-34212
पैच किया गया संस्करण: v0.71.0

हमला श्रृंखला

हमलावर-नियंत्रित अटैचमेंट नोड URL -> पेज JSON स्वीकार और अपरिवर्तित संग्रहीत -> HTML/React रेंडरिंग उस URL को एंकर href में बदलता है -> पीड़ित अटैचमेंट क्रिया पर क्लिक करता है -> हमलावर-नियंत्रित JavaScript Docmost ओरिजिन में निष्पादित होता है

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

Docmost पेज सामग्री को ProseMirror/Tiptap-संगत JSON प्रारूप में संग्रहीत करता है।

उस सामग्री मॉडल में निम्नलिखित के लिए कस्टम ब्लॉक नोड शामिल हैं:

• चित्र
• आरेख
• एम्बेड
• अटैचमेंट

अटैचमेंट नोड निम्नलिखित फ़ील्ड संग्रहीत करता है:

• url
• name
• mime
• size
• attachmentId

सर्वर पेज सामग्री को कई प्रारूपों में स्वीकार करता है:

• json
• markdown
• html

और इसे संग्रहीत करने से पहले ProseMirror JSON में सामान्यीकृत करता है।

इसका मतलब है कि कोई भी नोड प्रकार जो URL ले जा सकता है, एक सीधी ट्रस्ट सीमा का हिस्सा है।

यदि उन नोड प्रकारों में से कोई अंततः <a href> में रेंडर होता है, तो URL स्कीम हैंडलिंग वैकल्पिक नहीं है। यह सुरक्षा मॉडल का हिस्सा है।

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

कस्टम एडिटर एक्सटेंशन सुरक्षा विचलन का एक लगातार स्रोत हैं।

आधार प्रणाली पहले से ही जानती हो सकती है कि खतरनाक URL को सही तरीके से कैसे संभालना है, लेकिन प्रत्येक कस्टम नोड को अभी भी अपने स्वयं के सिंक पर समान नियमों को फिर से लागू करना होता है।

यह एक अनुमानित समीक्षा रणनीति बनाता है:

• URL जैसा फ़ील्ड संग्रहीत करने वाले प्रत्येक नोड प्रकार को खोजें
• वह फ़ील्ड कहाँ स्वीकार किया जाता है, इसका पता लगाएं
• वह फ़ील्ड कहाँ रेंडर किया जाता है, इसका पता लगाएं
• इसके स्वच्छता व्यवहार की तुलना प्लेटफ़ॉर्म के सामान्य लिंक हैंडलिंग से करें

ठीक यही इस बग को उजागर करता है।

Docmost के सामान्य लिंक एक्सटेंशन ने पहले से ही javascript: को खतरनाक माना।

इसके अटैचमेंट नोड ने ऐसा नहीं किया।

एक बार जब आप यह विषमता देखते हैं, तो सुरक्षा प्रश्न स्पष्ट हो जाता है:

क्या मैं एक अटैचमेंट नोड को बनाए रख सकता हूँ जिसका url javascript: है और इसे एक जीवित एंकर में वापस रेंडर करवा सकता हूँ?

उत्तर हाँ था।

मूल कारण

मूल कारण सामग्री नोड प्रकारों में असंगत URL स्वच्छता था।

सर्वर-साइड सामग्री पथ ने मनमाने अटैचमेंट URL को तब तक स्वीकार किया जब तक समग्र सामग्री ProseMirror स्कीमा से मेल खाती थी।

कमजोर संस्करण में:

• CreatePageDto ने content?: string | object स्वीकार किया
• PageService.parseProsemirrorContent() ने markdown, html, या json को सामान्यीकृत किया
• सर्वर ने तब jsonToNode(prosemirrorJson) को कॉल किया
• यदि स्कीमा सत्यापन पास हो गया, तो सामग्री संग्रहीत हो गई

उस सत्यापन चरण ने संरचनात्मक वैधता की जाँच की, URL सुरक्षा की नहीं।

कमजोर सर्वर तर्क का महत्वपूर्ण भाग प्रभावी रूप से था:

वहाँ कोई अटैचमेंट URL स्कीम सामान्यीकरण नहीं हुआ।

बाद में, अटैचमेंट एक्सटेंशन ने हमलावर-नियंत्रित मान को सीधे रेंडर किया।

कमजोर अटैचमेंट नोड ने ऐसा किया:

और फिर:

क्लाइंट साइड पर, React नोड व्यू ने इसे फिर से लपेटा:

लेकिन getFileUrl() ने केवल विशेष मामलों को संभाला:

• पूर्ण http URL
• /api/...
• /files/...

बाकी सब कुछ अपरिवर्तित वापस कर दिया गया।

तो एक पेलोड जैसे:

बच गया:

• JSON संग्रहण
• सर्वर-साइड स्कीमा सत्यापन
• HTML रेंडरिंग
• क्लाइंट-साइड URL हैंडलिंग

यह अकेले ही संग्रहीत XSS के लिए पर्याप्त होगा।

मूल कारण को विशेष रूप से स्पष्ट करने वाली बात तुलनात्मक बिंदु है।

Docmost के सामान्य लिंक एक्सटेंशन ने स्पष्ट रूप से javascript: को अवरुद्ध किया:

• इसने parseHTML() में javascript: को अस्वीकार कर दिया
• इसने renderHTML() में javascript: href को खाली कर दिया

तो उत्पाद पहले से ही जानता था कि यह स्कीम खतरनाक है।

अटैचमेंट नोड बस उसी नीति को लागू करने में विफल रहा।

यही कारण है कि यह "एडिटर में सामान्य XSS" नहीं था।

यह एक नोड-विशिष्ट ट्रस्ट-बाउंड्री गैप था।

यह एक सुरक्षा समस्या क्यों है, सिर्फ गायब स्वच्छता नहीं

यह बग केवल असुरक्षित HTML सौंदर्यशास्त्र के बारे में नहीं था।

इसने एक हमलावर को जो पेज संपादित कर सकता था, एक दुर्भावनापूर्ण पेलोड को बनाए रखने की अनुमति दी जो बाद में Docmost ओरिजिन में निष्पादित होगा जब कोई अन्य उपयोगकर्ता रेंडर किए गए अटैचमेंट के साथ इंटरैक्ट करेगा।

यह मायने रखता है क्योंकि ओरिजिन-इन स्क्रिप्ट यह कर सकती है:

• वह डेटा पढ़ सकती है जिसे पीड़ित एक्सेस कर सकता है
• पीड़ित के रूप में प्रमाणित अनुरोध जारी कर सकती है
• वह सामग्री संशोधित कर सकती है जिसे पीड़ित को संशोधित करने की अनुमति है
• सत्र में उजागर किसी भी DOM या API सतह का दुरुपयोग कर सकती है

क्लिक की आवश्यकता इसे एक मामूली समस्या में कम नहीं करती है।

क्लिक सामान्य उत्पाद व्यवहार का हिस्सा है: UI जानबूझकर अटैचमेंट को एक कार्रवाई योग्य लिंक/आइकन के रूप में प्रस्तुत करता है।

तो सुरक्षा प्रश्न यह नहीं है "क्या हमलावर बिना किसी इंटरैक्शन के मनमानी JS को मजबूर कर सकता है?"

असली सवाल यह है:

क्या एप्लिकेशन हमलावर-नियंत्रित स्क्रिप्ट-युक्त सामग्री संग्रहीत करता है और बाद में इसे अन्य उपयोगकर्ताओं को एक भरोसेमंद इंटरैक्शन पथ के रूप में प्रस्तुत करता है?

कमजोर संस्करणों में, इसने ऐसा किया।

यह संग्रहीत XSS है।

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

शोषण पथ सीधा था:

• पेज संपादन अधिकार वाला कोई भी उपयोगकर्ता पेलोड लगा सकता था
• दुर्भावनापूर्ण URL अपरिवर्तित संग्रहण में बच गया
• पेज सामान्य रूप से रेंडर हुआ
• दर्शकों को केवल पेज तक मानक पहुँच की आवश्यकता थी
• अटैचमेंट क्रिया पर एक क्लिक निष्पादन को ट्रिगर करने के लिए पर्याप्त था

इसने उच्च-विशेषाधिकार वाले उपयोगकर्ताओं को भी यथार्थवादी लक्ष्य बना दिया।

यदि एक कार्यक्षेत्र मालिक, व्यवस्थापक, या व्यापक रूप से भरोसेमंद संपादक ने हमलावर-नियंत्रित सामग्री देखी और अटैचमेंट क्रिया पर क्लिक किया, तो हमलावर की स्क्रिप्ट उस अधिक विशेषाधिकार प्राप्त सत्र संदर्भ में चलेगी।

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

हमलावर की विशेषाधिकार आवश्यकता केवल कम थी। पीड़ित का विशेषाधिकार स्तर निर्धारित करता है कि XSS सत्र में कितना मूल्य था।

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

मैंने Docmost v0.70.3 के खिलाफ लाइव समस्या को मान्य किया।

PoC ने केवल सामान्य HTTP अनुरोधों और एप्लिकेशन के अपने पेज API का उपयोग किया।

प्रवाह था:

1. एक उपयोगकर्ता के रूप में लॉग इन करें जो पेज संपादित कर सकता है।
2. एक पेज बनाएँ या चुनें।
3. format: "json" और एक अटैचमेंट नोड जिसका url एक javascript: पेलोड है, के साथ POST /api/pages/update भेजें।
4. POST /api/pages/info के माध्यम से पेज वापस अनुरोध करें।
5. पुष्टि करें कि संग्रहीत JSON में अभी भी दुर्भावनापूर्ण URL है।
6. उसी पेज को HTML रूप में अनुरोध करें और पुष्टि करें कि सर्वर एक एंकर लौटाता है जिसका href अभी भी javascript:... है।
7. UI में, एक दर्शक द्वारा रेंडर किए गए अटैचमेंट क्रिया पर क्लिक करने से Docmost ओरिजिन में पेलोड निष्पादित होता है।

न्यूनतम दुर्भावनापूर्ण सामग्री थी:

मेरे परीक्षण से देखा गया लाइव परिणाम था:

• API ने दुर्भावनापूर्ण अटैचमेंट नोड को अपरिवर्तित स्वीकार किया
• संग्रहीत पेज ID 019d18cf-4212-70b0-894a-fe20080fb0f1 थी
• POST /api/pages/info ने संग्रहीत JSON लौटाया जिसमें:

• POST /api/pages/info format: "html" के साथ निम्नलिखित HTML लौटाया:

वह HTML प्रतिक्रिया महत्वपूर्ण प्रमाण है।

मुझे एक अस्पष्ट दावे पर निर्भर नहीं रहना पड़ा कि "ब्राउज़र कुछ दिलचस्प कर सकता है।"

एप्लिकेशन ने स्वयं सटीक निष्पादन योग्य सिंक रेंडर किया।

एक बार जब कोई उपयोगकर्ता उस अटैचमेंट लिंक/आइकन पर क्लिक करता है, तो ब्राउज़र javascript: URL को उस पृष्ठ के ओरिजिन में निष्पादित करता है जिसने इसे बनाया।

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

एडिटर-संचालित XSS के लिए, अकेले स्क्रीनशॉट कमजोर सबूत हैं।

वे लक्षण दिखाते हैं, सीमा विफलता नहीं।

यही कारण है कि मैंने PoC को दो स्पष्ट जाँच बिंदुओं के आसपास संरचित किया:

1. भंडारण प्रमाण
2. रेंडर किए गए सिंक प्रमाण

भंडारण प्रमाण ने दिखाया कि सर्वर ने खतरनाक स्कीम को स्वीकार और संरक्षित किया।

रेंडर किए गए सिंक प्रमाण ने दिखाया कि एप्लिकेशन ने उस संग्रहीत मान को वापस इसमें बदल दिया:

यह विभाजन मायने रखता है।

यदि कोई उत्पाद खतरनाक इनपुट संग्रहीत करता है लेकिन प्रत्येक सिंक से पहले इसे निष्क्रिय कर देता है, तो आपके पास एक सख्ती अंतर हो सकता है लेकिन जरूरी नहीं कि एक लाइव XSS हो।

यदि उत्पाद खतरनाक इनपुट संग्रहीत करता है और बाद में इसे एक वास्तविक निष्पादन सिंक में रेंडर करता है, तो आपके पास पूर्ण भेद्यता श्रृंखला है।

यहाँ यही हुआ।

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

फिक्स v0.71.0 में भेजा गया और अटैचमेंट URL पर URL स्वच्छता लागू करके रेंडर किए गए शोषण पथ को संबोधित किया।

अटैचमेंट एक्सटेंशन अब sanitizeUrl आयात और उपयोग करता है, जिसमें शामिल है:

• पार्सिंग के दौरान data-attachment-url को स्वच्छ करना
• रेंडरिंग के दौरान data-attachment-url को स्वच्छ करना
• एंकर href को स्वच्छ करना

अवधारणात्मक रूप से, पैच ने अटैचमेंट नोड को इससे बदल दिया:

• कच्चे अटैचमेंट URL पर भरोसा करें
• कच्चा अटैचमेंट URL उत्सर्जित करें

इसमें:

• अटैचमेंट URL को सामान्यीकृत करें इससे पहले कि यह रेंडर किए गए नोड का हिस्सा बने

क्लाइंट-साइड हेल्पर getFileUrl() को भी अपडेट किया गया ताकि अज्ञात स्कीम अब अछूती न गुजरें। पैच किए गए संस्करण में, फ़ॉलबैक पथ sanitizeUrl(src) लौटाता है, न कि src को ज्यों का त्यों।

यह फिक्स का एक महत्वपूर्ण हिस्सा है क्योंकि कमजोर डिज़ाइन में दो प्रबलित समस्याएँ थीं:

• नोड ने एक कच्चा href रेंडर किया
• क्लाइंट फ़ॉलबैक ने अज्ञात स्कीम को स्वीकार्य माना

पैच ने दोनों धारणाओं को हटा दिया।

यह लाइव XSS पथ के लिए एक अच्छा फिक्स था क्योंकि इसने अटैचमेंट URL हैंडलिंग को एडिटर के बाकी सुरक्षा मॉडल के साथ संरेखित किया।

हालांकि, अभी भी एक व्यापक सख्ती सबक है:

क्लाइंट-साइड या रेंडर-टाइम स्वच्छता यहाँ आवश्यक है, लेकिन पेज बनाने/अपडेट के दौरान खतरनाक स्कीम का सर्वर-साइड अस्वीकरण एक और भी मजबूत अपरिवर्तनीय होगा।

सबसे सुरक्षित दीर्घकालिक मॉडल है:

• स्पष्ट रूप से खतरनाक स्कीम को अंतर्ग्रहण पर अस्वीकार करें
• रेंडर सीमाओं पर फिर से स्वच्छता लागू करें

रिच-कंटेंट सिस्टम में गहराई में रक्षा मायने रखती है।

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

दीर्घकालिक कवरेज के लिए, ये वे मामले हैं जो सबसे अधिक मायने रखते हैं:

• JSON पेज अपडेट जिसमें attachment.attrs.url = "javascript:..."
• HTML आयात जिसमें data-attachment-url="javascript:..."
• अटैचमेंट रेंडरिंग को कभी भी href="javascript:..." उत्सर्जित नहीं करना चाहिए
• क्लाइंट फ़ॉलबैक हेल्पर को अज्ञात निष्पादन योग्य स्कीम को अपरिवर्तित नहीं लौटाना चाहिए
• अटैचमेंट नोड और सामान्य लिंक नोड को समतुल्य URL-स्कीम नीति साझा करनी चाहिए
• सुरक्षित आंतरिक अटैचमेंट पथ जैसे /api/files/... और /files/... सामान्य रूप से काम करते रहना चाहिए

मुख्य बिंदु निरंतरता है।

यदि सामान्य लिंक को स्वच्छ किया जाता है लेकिन कस्टम URL-युक्त नोड को नहीं, तो एडिटर के पास वास्तव में एक एकल URL सुरक्षा नीति नहीं है।

इसमें टुकड़े हैं, और टुकड़े वही हैं जहाँ XSS बग रहते हैं।

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

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

• CWE-79: वेब पेज जनरेशन के दौरान इनपुट का अनुचित न्यूट्रलाइज़ेशन
• CVSS v3.1:

यह 7.6 / उच्च पर आता है।

यह एक बचाव योग्य वर्गीकरण है।

महत्वपूर्ण गुण हैं:

• कम हमलावर विशेषाधिकार आवश्यकता
• संग्रहीत पेलोड
• Docmost ओरिजिन में निष्पादन
• दायरा परिवर्तन
• सार्थक गोपनीयता प्रभाव क्योंकि स्क्रिप्ट पीड़ित-दृश्य इन-ऐप डेटा तक पहुँच सकती है

उपयोगकर्ता इंटरैक्शन आवश्यक बना हुआ है क्योंकि पीड़ित को अटैचमेंट लिंक/आइकन सक्रिय करना होता है। यही कारण है कि UI:R सही है।

लेकिन एक बार जब वह इंटरैक्शन होता है, तो सुरक्षा सीमा बहुत पहले ही विफल हो चुकी होती है: एप्लिकेशन ने एक खतरनाक स्कीम संग्रहीत की और इसे एक निष्पादन सिंक में वापस रेंडर किया।

प्रकटीकरण

मैंने समस्या की निजी रूप से GitHub सुरक्षा सलाहकार के माध्यम से रिपोर्ट की:

• मूल-कारण विश्लेषण
• एक लाइव HTTP PoC
• संग्रहीत JSON साक्ष्य
• रेंडर किए गए HTML सिंक साक्ष्य
• एक पिन किया हुआ डिस्पोज़ेबल टेस्ट लैब

समस्या को स्वीकार किया गया, CVE-2026-34212 सौंपा गया, और 14 अप्रैल, 2026 को प्रकाशित किया गया।

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

• प्रभावित संस्करण: 0.70.3
• पैच किया गया संस्करण: 0.71.0

मेरा लाइव सत्यापन v0.70.3 पर किया गया था, जो प्रकाशित कमजोर संस्करण से मेल खाता है।

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

यहाँ मुख्य सबक केवल "URL को स्वच्छ करें" नहीं है।

हर कोई पहले से ही यह जानता है।

अधिक दिलचस्प सबक यह है:

यदि किसी एप्लिकेशन में एक सुरक्षित URL-युक्त नोड प्रकार और एक असुरक्षित URL-युक्त नोड प्रकार है, तो असुरक्षित वास्तविक नीति है।

रिच-टेक्स्ट सिस्टम अक्सर कस्टम एक्सटेंशन को सुरक्षा समीक्षा की तुलना में तेज़ी से जमा करते हैं।

यह ठीक इस प्रकार की विषमता पैदा करता है:

• मानक लिंक पथ सख्त होता है
• अटैचमेंट पथ को "आंतरिक" या "विशेष" माना जाता है
• विशेष पथ चुपचाप आसान XSS सिंक बन जाता है

यह बग यह भी दिखाता है कि स्कीमा सत्यापन पर्याप्त क्यों नहीं है।

jsonToNode() ने सत्यापित किया कि सामग्री संरचनात्मक रूप से वैध ProseMirror डेटा थी। इसने यह साबित नहीं किया कि सामग्री रेंडर करने के लिए सुरक्षित थी।

वे अलग-अलग प्रश्न हैं।

सुरक्षा समीक्षा तब बहुत तेज हो जाती है जब आप उन प्रश्नों को अलग रखते हैं:

• क्या यह सामग्री संरचनात्मक रूप से मान्य है?
• क्या यह सामग्री संग्रहीत करने के लिए सुरक्षित है?
• क्या यह सामग्री प्रत्येक सिंक पर रेंडर करने के लिए सुरक्षित है?

अटैचमेंट नोड पहले प्रश्न में पास हुआ और तीसरे में विफल रहा।

इस तरह संग्रहीत सामग्री बग अन्यथा अच्छी तरह से संरचित एडिटर पाइपलाइनों के अंदर जीवित रहते हैं।

मुख्य बिंदु

• Docmost ने पेज सामग्री में कच्चे अटैचमेंट नोड URL स्वीकार किए।
• सर्वर-साइड पेज सत्यापन ने ProseMirror स्कीमा आकार की जाँच की, URL-स्कीम सुरक्षा की नहीं।
• कमजोर अटैचमेंट नोड ने data-attachment-url और एंकर href को सीधे हमलावर-नियंत्रित इनपुट से रेंडर किया।
• क्लाइंट हेल्पर getFileUrl() ने अज्ञात स्कीम को अपरिवर्तित लौटाया।
• सामान्य लिंक नोड ने पहले से ही javascript: को अवरुद्ध किया, लेकिन अटैचमेंट नोड ने ऐसा नहीं किया।
• एक कम-विशेषाधिकार वाला संपादक एक बार पेलोड लगा सकता था और बाद के दर्शकों को लक्षित कर सकता था।
• लाइव PoC ने संग्रहीत दृढ़ता और रेंडर किए गए निष्पादन योग्य सिंक दोनों को साबित किया।
• v0.71.0 में फिक्स ने अटैचमेंट नोड और क्लाइंट फ़ॉलबैक पथ में sanitizeUrl हैंडलिंग जोड़ी।

अंतिम शब्द

यह भेद्यता ब्राउज़र की विचित्रता के बारे में नहीं थी।

यह एक कस्टम सामग्री नोड के बारे में था जिसने एप्लिकेशन के अपने URL सुरक्षा अनुमानों को दरकिनार कर दिया।

Docmost ने एक हमलावर-नियंत्रित अटैचमेंट URL स्वीकार किया, इसे भंडारण के माध्यम से संरक्षित किया, और फिर इसे एप्लिकेशन ओरिजिन में एक जीवित एंकर में वापस रेंडर किया।

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

v0.71.0 में पैच ने सक्रिय XSS पथ को साफ-सुथरा बंद कर दिया, लेकिन व्यापक सबक वह है जिसे रखना चाहिए:

एडिटर-भारी अनुप्रयोगों में, प्रत्येक कस्टम नोड जो URL ले जा सकता है, अपनी स्वयं की सुरक्षा सीमा है, और इसकी समीक्षा एक के रूप में की जानी चाहिए।