प्रमाणित (योगदानकर्ता) संग्रहीत XSS ONLYOFFICE DocSpace में (<= 2.1.1) — साइट मालिकों को अब क्या करना चाहिए

लेखक: हांगकांग सुरक्षा विशेषज्ञ — दिनांक: 2026-02-03

सारांश: ONLYOFFICE DocSpace संस्करण ≤ 2.1.1 (CVE‑2024‑11750) में संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) की एक भेद्यता एक प्रमाणित उपयोगकर्ता को योगदानकर्ता विशेषाधिकारों के साथ स्क्रिप्ट पेलोड्स संग्रहीत करने की अनुमति देती है जो अन्य उपयोगकर्ताओं के ब्राउज़रों में निष्पादित होती हैं। संस्करण 2.1.2 में सुधार शामिल है। यह सलाह एक संक्षिप्त तकनीकी सारांश, वास्तविक हमले के परिदृश्य, पहचान तकनीक, और साइट मालिकों और प्रशासकों के लिए स्पष्ट शमन कदम प्रदान करती है — जब तत्काल अपडेट करना संभव नहीं हो तो व्यावहारिक विकल्पों के साथ।.

सामग्री की तालिका

• अवलोकन: क्या हुआ
• तकनीकी सारांश: भेद्यता कैसे काम करती है
• यथार्थवादी हमले के परिदृश्य और प्रभाव
• प्रभावित संस्करण और CVE / CVSS संदर्भ
• साइट प्रशासकों के लिए तत्काल कदम
• यह कैसे पता करें कि क्या आप लक्षित हुए हैं
• जब आप तुरंत अपडेट नहीं कर सकते हैं तो कैसे शमन करें
• दीर्घकालिक मजबूत करना और सर्वोत्तम प्रथाएँ
• वर्चुअल पैचिंग तुरंत कैसे मदद करती है
• व्यावहारिक कमांड और कोड स्निपेट्स (परिशिष्ट)
• अंतिम नोट्स और अनुशंसित समयरेखा

अवलोकन: क्या हुआ

3 फरवरी 2026 को ONLYOFFICE DocSpace में संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) समस्या सार्वजनिक रूप से प्रकट की गई। भेद्यता (CVE‑2024‑11750) एक योगदानकर्ता (एक प्रमाणित उपयोगकर्ता जिसके पास सीमित विशेषाधिकार हैं) को सामग्री प्रस्तुत करने की अनुमति देती है जो बाद में पर्याप्त सफाई या एन्कोडिंग के बिना प्रस्तुत की जाती है, जिसके परिणामस्वरूप स्क्रिप्ट निष्पादन होता है जब कोई अन्य उपयोगकर्ता प्रभावित पृष्ठ या दस्तावेज़ प्रविष्टि को देखता है। प्लगइन लेखक ने संस्करण 2.1.2 में एक पैच जारी किया।.

यह सलाह वर्डप्रेस साइट मालिकों और प्रशासकों के लिए लिखी गई है — विशेष रूप से हांगकांग में बहु-लेखक साइटों, इंट्रानेट्स, या शिक्षण प्लेटफार्मों का प्रबंधन करने वाली टीमों के लिए जहां योगदानकर्ता खाते सामान्य हैं। इसे पढ़ें और जल्दी कार्रवाई करें: सुधार सरल है (अपडेट), लेकिन अंतरिम नियंत्रणों से जोखिम कम होता है जबकि आप पैच का परीक्षण और लागू करते हैं।.

तकनीकी सारांश: भेद्यता कैसे काम करती है

संग्रहीत XSS तब होता है जब हमलावर-नियंत्रित डेटा सर्वर पर संग्रहीत होता है और बाद में उचित सत्यापन, सफाई, और आउटपुट एन्कोडिंग के बिना पृष्ठों में प्रस्तुत किया जाता है।.

• आवश्यक विशेषाधिकार: योगदानकर्ता (सामग्री बना सकता है लेकिन आमतौर पर प्रकाशित या प्लगइन्स का प्रबंधन नहीं कर सकता)।.
• कमजोरियों का प्रकार: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (स्थायी XSS)।.
• ट्रिगर: एक योगदानकर्ता उन फ़ील्ड में एक पेलोड इंजेक्ट करता है जिन्हें प्लगइन संग्रहीत करता है (शीर्षक, विवरण, टिप्पणियाँ, मेटाडेटा)। उन फ़ील्ड को बाद में व्यवस्थापक या सार्वजनिक दृश्य में शब्दशः प्रदर्शित किया जाता है।.
• शोषण जोखिम: यदि एक व्यवस्थापक या अन्य उच्च-विशेषाधिकार उपयोगकर्ता पेलोड को देखता है, तो स्क्रिप्ट उस उपयोगकर्ता के ब्राउज़र संदर्भ में निष्पादित होती है, जिससे कुकी/टोकन चोरी, प्रमाणित अनुरोधों के माध्यम से विशेषाधिकार प्राप्त क्रियाएँ, या कार्यक्षेत्र का समझौता हो सकता है।.
• सुधार: ONLYOFFICE DocSpace 2.1.2 में अपडेट करें — पैच प्रभावित क्षेत्रों की उचित सफाई/कोडिंग सुनिश्चित करता है।.

यथार्थवादी हमले के परिदृश्य और प्रभाव

संग्रहीत XSS स्थायी है और इसे उच्च-विशेषाधिकार उपयोगकर्ताओं द्वारा सक्रिय किए जाने पर हथियार बनाया जा सकता है। उदाहरण:

• व्यवस्थापक खाता समझौता: एक योगदानकर्ता एक दस्तावेज़ विवरण में एक स्क्रिप्ट लगाता है। जब एक व्यवस्थापक दस्तावेज़ खोलता है, तो स्क्रिप्ट सत्र टोकन को एक हमलावर को निकालती है और साइट पर कब्जा करने की अनुमति देती है।.
• सामग्री विकृति या गलत सूचना: इंजेक्ट किया गया मार्कअप संपादकीय पृष्ठों पर धोखाधड़ी वाले बैनर या पॉपअप जोड़ता है, जिससे प्रतिष्ठा को नुकसान होता है।.
• CSRF चेनिंग: स्क्रिप्ट व्यवस्थापक अंत बिंदुओं पर पृष्ठभूमि अनुरोध करता है, यदि अंत बिंदु सुरक्षा कमजोर है तो सेटिंग्स बदलता है या उपयोगकर्ता बनाता है।.
• आपूर्ति-श्रृंखला पिवट: स्क्रिप्ट आंतरिक दस्तावेज़ आईडी, एपीआई कुंजी, या अन्य संवेदनशील यूआई आइटम को खोजता है और उन्हें लीक करता है।.

भले ही शोषण के लिए एक विशेषाधिकार प्राप्त उपयोगकर्ता को सामग्री देखने की आवश्यकता हो, संपादकीय कार्यप्रवाहों के लिए जोखिम महत्वपूर्ण है जहां व्यवस्थापक नियमित रूप से प्रस्तुतियों का पूर्वावलोकन करते हैं।.

प्रभावित संस्करण और CVE / CVSS संदर्भ

• प्रभावित: ONLYOFFICE DocSpace ≤ 2.1.1
• में ठीक किया गया: 2.1.2
• CVE: CVE‑2024‑11750
• CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L (स्कोर ~6.5)

वेक्टर पर नोट्स: हमलावर को नेटवर्क एक्सेस और एक योगदानकर्ता खाता चाहिए। एक विशेषाधिकार प्राप्त उपयोगकर्ता को दुर्भावनापूर्ण सामग्री को देखना या उसके साथ इंटरैक्ट करना चाहिए (UI:R)। दायरा C है — प्रभाव विशेषाधिकार सीमाओं को पार कर सकता है।.

साइट व्यवस्थापकों के लिए तात्कालिक कदम (सबसे तेज़ जोखिम में कमी)

1. प्लगइन को अपडेट करें (सिफारिश की गई): जितनी जल्दी हो सके ONLYOFFICE DocSpace 2.1.2 लागू करें। जब संभव हो, उत्पादन से पहले स्टेजिंग पर परीक्षण करें।.
2. यदि आप तुरंत अपडेट नहीं कर सकते — अल्पकालिक शमन:
   • असत्यापित योगदानकर्ता खातों को अस्थायी रूप से निलंबित या हटा दें जिन्हें आप मान्य नहीं कर सकते।.
   • योगदानकर्ताओं की भूमिकाएँ सब्सक्राइबर या एक कस्टम भूमिका में बदलें जब तक पैच लागू नहीं हो जाता।.
   • सामग्री मॉडरेशन को लागू करें: उच्च-privilege उपयोगकर्ताओं द्वारा प्रस्तुत सामग्री को देखने से पहले ड्राफ्ट और व्यवस्थापक/संपादक अनुमोदन की आवश्यकता करें।.
3. WAF के साथ आभासी पैचिंग लागू करें: यदि अपडेट में देरी होती है, तो प्लगइन एंडपॉइंट्स पर संभावित XSS पेलोड को ब्लॉक करने के लिए WAF नियम लागू करें (नीचे नियम सुझाव देखें)। आभासी पैचिंग शोषण प्रयासों को एप्लिकेशन लॉजिक तक पहुँचने से पहले रोक सकती है।.
4. दुर्भावनापूर्ण सामग्री के लिए स्कैन करें: XSS मार्करों जैसे <script, javascript:, onerror=, onload=, <iframe, एन्कोडेड समकक्षों के लिए पोस्ट, पोस्टमेटा, टिप्पणियाँ और प्लगइन मेटाडेटा खोजें।.
5. यदि समझौता संदिग्ध है तो व्यवस्थापक क्रेडेंशियल्स को घुमाएँ: पासवर्ड रीसेट करने के लिए मजबूर करें, सत्रों को अमान्य करें, और किसी भी उजागर टोकन को घुमाएँ।.
6. उच्च-privilege क्रियाओं का ऑडिट करें: समझौते के संकेतों के लिए हाल के प्लगइन/थीम परिवर्तनों, नए उपयोगकर्ताओं और अनुसूचित कार्यों की समीक्षा करें।.

यह कैसे पता करें कि क्या आप लक्षित हुए हैं

पहचान स्वचालित स्कैनिंग को मैनुअल समीक्षा के साथ मिलाती है।.

1. स्क्रिप्ट टैग के लिए डेटाबेस खोज (त्वरित): WP-CLI या सीधे DB क्वेरी का उपयोग करें (पहले बैकअप लें)। उदाहरण कमांड:

# <script शामिल करने वाले पोस्ट खोजें"

2. अस्पष्ट पेलोड के लिए स्कैन करें: Search for onerror=, onload=, %3Cscript, <script, javascript:, hex/unicode encoded sequences, or unusual concatenation patterns.
3. मैन्युअल समीक्षा: योगदानकर्ताओं से हाल की सामग्री का निरीक्षण करें: दस्तावेज़ शीर्षक, विवरण, नोट्स, और कोई भी फ़ील्ड जो प्लगइन व्यवस्थापक दृश्य में उजागर करता है।.
4. लॉग विश्लेषण: योगदानकर्ता खातों से प्लगइन एंडपॉइंट्स पर असामान्य POST अनुरोधों या स्क्रिप्ट-जैसे पेलोड वाले अनुरोधों की तलाश करें।.
5. स्वचालित स्कैनर: सामग्री और मेटाडेटा में संग्रहीत XSS का पता लगाने के लिए एक प्रतिष्ठित स्कैनर का उपयोग करें, जिसमें कस्टम पोस्ट प्रकार और प्लगइन एंडपॉइंट शामिल हैं।.

जब आप तुरंत अपडेट नहीं कर सकते हैं तो कैसे कम करें (वर्चुअल पैचिंग + कॉन्फ़िगरेशन)

जब संचालन संबंधी बाधाएँ तत्काल अपग्रेड को रोकती हैं, तो स्तरित नियंत्रणों का उपयोग करके जोखिम को कम करें।.

1. WAF के माध्यम से वर्चुअल पैचिंग

नियम लागू करें जो प्लगइन के एंडपॉइंट को लक्षित करने वाले संभावित XSS पेलोड का पता लगाते और अवरुद्ध करते हैं। यदि पैरामीटर नाम अज्ञात हैं, तो सामान्य लेकिन लक्षित पैटर्न का उपयोग करें और पहचान (लॉग) से अवरोधन तक के नियमों को चरणबद्ध करें।.

वैचारिक नियम स्थितियाँ:

• ज्ञात ONLYOFFICE DocSpace एंडपॉइंट या प्रशासनिक एंडपॉइंट पर POST/PUT अनुरोधों पर ट्रिगर करें।.
• यदि कोई पैरामीटर <script, javascript:, onerror=, onload=, या एन्कोडेड समकक्षों को शामिल करता है तो अवरुद्ध करें।.
• मेल खाने वाले लॉगिंग से शुरू करें, फिर झूठे सकारात्मक से बचने के लिए क्रमिक रूप से अवरुद्ध करें।.

Regex अवधारणाएँ (अपने WAF इंजन के अनुसार अनुकूलित करें):

• कच्चे स्क्रिप्ट टैग का पता लगाएँ (केस असंवेदनशील): (?i)<\s*script\b
• इवेंट हैंडलर्स का पता लगाएँ: (?i)on(?:error|load|click|submit)\s*=\s*[‘”]?
• जावास्क्रिप्ट छद्म-प्रोटोकॉल का पता लगाएँ: (?i)javascript\s*:

2. योगदानकर्ताओं के लिए बिना फ़िल्टर वाला HTML प्रतिबंधित करें

कुछ सेटअप गैर-प्रशासकों को बिना फ़िल्टर वाला HTML प्रदान करते हैं। योगदानकर्ता खातों के लिए उस क्षमता को अस्थायी रूप से हटा दें। साइट-विशिष्ट प्लगइन या functions.php में जोड़ने के लिए उदाहरण कोड:

<?php

3. प्लगइन सबमिशन के लिए मॉडरेशन लागू करें

योगदानकर्ता सबमिशन के प्रशासनिक दृश्य में दिखाई देने से पहले प्रशासक/संपादक की स्वीकृति की आवश्यकता है, जिन्हें विशेषाधिकार प्राप्त उपयोगकर्ता नियमित रूप से खोलते हैं।.

4. योगदानकर्ता पहुंच अस्थायी रूप से हटा दें

योगदानकर्ताओं को सब्सक्राइबर में बदलें या एक न्यूनतम अस्थायी भूमिका बनाएं जिसमें सामग्री निर्माण के विशेषाधिकार न हों जब तक कि प्लगइन पैच न हो जाए।.

5. सहेजने पर साफ़ करें (अस्थायी फ़िल्टर)

यदि प्लगइन सहेजने के हुक को उजागर करता है, तो सहेजने पर मेटा फ़ील्ड को साफ़ करने के लिए एक अल्पकालिक फ़िल्टर जोड़ें। उदाहरण (अस्थायी):

<?php

नोट: यह एक अल्पकालिक रक्षात्मक उपाय है। अंतिम उपाय प्लगइन अपडेट है।.

दीर्घकालिक मजबूत करना और सर्वोत्तम प्रथाएँ

• न्यूनतम विशेषाधिकार का सिद्धांत: योगदानकर्ता क्षमताओं को सीमित करें। जब तक आवश्यक और विश्वसनीय न हो, बिना फ़िल्टर किए गए HTML या फ़ाइल अपलोड देने से बचें।.
• इनपुट पर साफ़ करें + मान्य करें, आउटपुट पर एन्कोड करें: प्लगइन लेखकों को सर्वर-साइड पर मान्य करना चाहिए और उपयुक्त रूप से esc_html(), esc_attr(), wp_kses_post() का उपयोग करके आउटपुट पर एस्केप करना चाहिए।.
• नॉनसेस और क्षमता जांच: सुनिश्चित करें कि AJAX/REST एंडपॉइंट्स current_user_can() की जांच करें और नॉनसेस को मान्य करें।.
• सामग्री मॉडरेशन वर्कफ़्लो: संपादकीय समीक्षा लागू करें जहां ऊंचे भूमिकाओं को निम्न-privileged उपयोगकर्ताओं से सामग्री को मंजूरी देनी चाहिए।.
• नियमित प्लगइन रखरखाव: प्लगइनों को अपडेट रखें और समय पर सलाह प्राप्त करने के लिए कमजोरियों की निगरानी करें।.
• प्रशासनिक पहुंच को मजबूत करें: दो-कारक प्रमाणीकरण का उपयोग करें, जहां व्यावहारिक हो वहां प्रशासनिक पृष्ठों के लिए IP प्रतिबंध, और संदिग्ध लॉगिन की निगरानी करें।.
• लॉगिंग और अलर्टिंग: अवरुद्ध WAF घटनाओं, अप्रत्याशित फ़ाइल परिवर्तनों, और नए प्रशासनिक उपयोगकर्ताओं के निर्माण पर अलर्ट करें।.

वर्चुअल पैचिंग (WAF) आपको अब कैसे मदद करता है

एक WAF जिसमें एप्लिकेशन-जानकारी वाले नियम होते हैं, तत्काल सुरक्षा प्रदान करता है जो शोषण प्रयासों को रोक सकता है जब आप तुरंत प्लगइन को अपडेट नहीं कर सकते। उपयोगी क्षमताएँ:

• ज्ञात शोषण पैटर्न को ब्लॉक करने के लिए वर्चुअल पैचिंग।.
• संदर्भित नियम जो प्लगइन एंडपॉइंट्स या भूमिकाओं को लक्षित करते हैं जो दुरुपयोग के लिए संभावित हैं।.
• अनुरोध साफ़ करना ताकि आने वाले डेटा से स्पष्ट इनलाइन स्क्रिप्ट और इवेंट हैंडलर्स को हटा दिया जा सके।.
• लॉगिंग और फोरेंसिक्स शोषण प्रयासों को विश्लेषण के लिए कैप्चर करने के लिए।.

हांगकांग में नियामक या प्रतिष्ठात्मक चिंताओं वाले संगठनों के लिए, एक WAF को एक सख्त पैच शेड्यूल के साथ जोड़ना तत्काल और दीर्घकालिक जोखिम दोनों को कम करता है।.

व्यावहारिक कमांड और कोड स्निपेट्स (परिशिष्ट)

हमेशा क्वेरी चलाने या परिवर्तन करने से पहले अपने डेटाबेस और फ़ाइलों का बैकअप लें। जहां संभव हो, स्टेजिंग में परीक्षण करें।.

1. WP‑CLI खोज उदाहरण

# <script के लिए पोस्ट सामग्री खोजें"

2. त्वरित सफाई (अत्यधिक सावधानी से उपयोग करें)

उदाहरण: एक विशिष्ट मेटा कुंजी से टैग हटाएँ (पहले परीक्षण करें):

<?php

3. सहेजने पर अस्थायी स्वच्छता

<?php

4. उदाहरण mod_security / सामान्य WAF नियम (संकल्पना)

SecRule REQUEST_BODY "(?i)(<\s*script\b|javascript:|on(error|load|click|submit)\s*=)" \"

अंतिम नोट्स और अनुशंसित समयरेखा

1. 24 घंटे के भीतर: यदि संभव हो तो ONLYOFFICE DocSpace को 2.1.2 में अपडेट करें। यदि नहीं, तो योगदानकर्ता क्षमताओं को सीमित करें और प्लगइन एंडपॉइंट्स पर वर्चुअल पैचिंग (WAF) सक्षम करें।.
2. 72 घंटे के भीतर: पोस्ट, पोस्टमेटा, और टिप्पणियों में इंजेक्टेड पेलोड के लिए स्कैन करें। यदि आप शोषण के सबूत पाते हैं तो दुर्भावनापूर्ण सामग्री को हटा दें और व्यवस्थापक क्रेडेंशियल्स को बदलें।.
3. 30 दिनों के भीतर: संपादकीय कार्यप्रवाह को मजबूत करें, निरंतर निगरानी लागू करें, और समय पर सुरक्षा अपडेट लागू करने के लिए एक विश्वसनीय प्रक्रिया सुनिश्चित करें।.

स्टोर किया गया XSS सूक्ष्म और स्थायी हो सकता है; जबकि प्लगइन अपडेट मूल कारण को ठीक करता है, परतदार सुरक्षा (WAF, भूमिका सख्ती, स्वच्छता, निगरानी) जोखिम को कम करती है जब तक पैच व्यापक रूप से लागू नहीं होता। यदि आपको WAF नियम बनाने, लक्षित स्कैन चलाने, या हांगकांग होस्टिंग वातावरण में सुधारों का परीक्षण करने में सहायता की आवश्यकता है, तो एक विश्वसनीय सुरक्षा सलाहकार या आपकी होस्टिंग समर्थन टीम से संपर्क करें और अपने होस्टिंग विवरण साझा करें ताकि वे अनुकूलित मार्गदर्शन प्रदान कर सकें।.