प्रेस3डी स्टोर्ड XSS (CVE-2026-1985) — वर्डप्रेस साइट मालिकों को क्या जानने की आवश्यकता है

प्रकाशित: 2026-02-13  |  लेखक: हांगकांग सुरक्षा विशेषज्ञ

यह नोट 13 फरवरी 2026 को प्रकट किए गए प्रेस3डी स्टोर्ड क्रॉस-साइट स्क्रिप्टिंग कमजोरियों का संक्षिप्त, तकनीकी रूप से व्यावहारिक विश्लेषण प्रदान करता है (CVE-2026-1985)। यह वर्डप्रेस साइट मालिकों, प्रशासकों और डेवलपर्स के लिए एक अनुभवी हांगकांग सुरक्षा प्रैक्टिशनर के दृष्टिकोण से लिखा गया है जिन्हें कार्रवाई योग्य पहचान और सुधारात्मक कदमों की आवश्यकता है।.

कार्यकारी सारांश — साधारण शब्दों में

• यह क्या है: लिंक.url विशेषता के माध्यम से प्रेस3डी प्लगइन के 3डी मॉडल ब्लॉक में स्टोर्ड XSS।.
• 14. कोई भी प्रमाणित उपयोगकर्ता जिसके पास योगदानकर्ता विशेषाधिकार (या उच्चतर) हैं। एक प्रमाणित उपयोगकर्ता जिसके पास लेखक विशेषाधिकार (या उच्चतर) हैं।.
• यह क्यों महत्वपूर्ण है: स्क्रिप्ट साइट सामग्री में सहेजी जा सकती है और आगंतुकों के ब्राउज़रों में या जब प्रशासक पृष्ठ को देखते हैं, तब निष्पादित की जा सकती है, जिससे सत्र चोरी, प्रशासक क्रियाएँ, या आगे का समझौता सक्षम होता है।.
• अल्पकालिक शमन: जहां संभव हो, प्लगइन को निष्क्रिय या हटा दें, सामग्री को स्कैन और साफ करें, क्रेडेंशियल्स को घुमाएँ, और किनारे पर वर्चुअल पैचिंग या अनुरोध फ़िल्टरिंग लागू करें।.
• दीर्घकालिक: सामग्री लेखकों के लिए न्यूनतम विशेषाधिकार लागू करें, अविश्वसनीय HTML सम्मिलन को प्रतिबंधित करें, सामग्री सुरक्षा नीति (CSP) और सुरक्षित कुकी ध्वज लागू करें, और प्लगइन्स को अपडेट रखें।.

तकनीकी विवरण (क्या हो रहा है)

यह कमजोरी एक क्लासिक स्टोर्ड XSS है जिसमें वर्डप्रेस-विशिष्ट संदर्भ है:

• प्रेस3डी गुटेनबर्ग ब्लॉक में एक लिंक.url विशेषता है जो 3डी मॉडल ब्लॉकों के लिए उपयोग की जाती है।.
• जो मान लिंक.url में डाले गए थे उन्हें पोस्ट सामग्री/ब्लॉक विशेषताओं में सहेजने से पहले मान्य या एस्केप नहीं किया गया था।.
• एक लेखक एक लिंक.url स्क्रिप्ट वाला तैयार कर सकता है, एक जावास्क्रिप्ट: URI, एक रैपर और फ़िल्टर को अस्वीकार करें: URI जिसमें स्क्रिप्ट है, या HTML संस्थाएं जो ब्राउज़रों द्वारा व्याख्यायित होती हैं।.
• क्योंकि ब्लॉक डेटा संग्रहीत होता है, दुर्भावनापूर्ण सामग्री आगंतुकों को परोसी जाती है और जब ब्लॉक रेंडर होता है तो निष्पादित होती है - एक संग्रहीत XSS।.

संग्रहीत XSS परावर्तित XSS की तुलना में अधिक हानिकारक हो सकता है क्योंकि पेलोड स्थायी होते हैं, प्रशासकों को लक्षित कर सकते हैं, और लंबे समय तक सामग्री में अप्रकट रह सकते हैं।.

चित्रात्मक प्रमाण-का-कल्पना (केवल वैचारिक)

या एक दुर्भावनापूर्ण जावास्क्रिप्ट: लिंक जो क्लिक करने पर निष्पादित होता है:

<a href="javascript:">मुझ पर क्लिक करें</a>

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

एक लेखक-स्तरीय हमलावर क्या हासिल कर सकता है यह इस पर निर्भर करता है कि कौन समझौता की गई सामग्री पर जाता है:

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

व्यावसायिक प्रभावों में खाता समझौता, अनदेखी प्रशासनिक परिवर्तन, प्रतिष्ठा और SEO क्षति, और लीक किए गए डेटा के लिए संभावित कानूनी जोखिम शामिल हैं।.

“लेखक” के आवश्यक विशेषाधिकार का महत्व क्यों है

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

तात्कालिक कार्रवाई - वर्डप्रेस साइट के मालिकों के लिए चेकलिस्ट (पहले 24-48 घंटे)

1. प्रभावित इंस्टॉलेशन की पहचान करें: पुष्टि करें कि क्या Press3D स्थापित है और संस्करण ≤ 1.0.2 है।.
2. अस्थायी समाधान: प्लगइन को निष्क्रिय करें या हटा दें। यदि निष्क्रिय करना संभव नहीं है, तो प्रकाशित सामग्री से प्रभावित 3D मॉडल ब्लॉकों को हटा दें।.
3. सामग्री स्कैन: खोजें <script> टैग, जावास्क्रिप्ट: यूआरआई, रैपर और फ़िल्टर को अस्वीकार करें: यूआरआई या ब्लॉक विशेषताओं में अन्य अनएस्केप्ड HTML।.
4. क्रेडेंशियल्स को घुमाएं: लेखक+ खातों और किसी भी संदिग्ध समझौता किए गए उपयोगकर्ताओं के लिए पासवर्ड रीसेट करने के लिए मजबूर करें।.
5. वर्चुअल पैचिंग / अनुरोध फ़िल्टरिंग: सामग्री को साफ करते समय किनारे पर संदिग्ध पेलोड को ब्लॉक या सैनिटाइज करें (WAF या अनुरोध फ़िल्टर)।.
6. ऑडिट: अप्रत्याशित व्यवस्थापक उपयोगकर्ताओं, संशोधित फ़ाइलों, अज्ञात क्रॉन्स, या अपलोड में PHP फ़ाइलों की खोज करें।.
7. लॉगिंग: शोषण प्रयासों के लिए होस्टिंग पर विस्तृत लॉगिंग सक्षम करें।.

अपने डेटाबेस में दुर्भावनापूर्ण सामग्री कैसे खोजें (व्यावहारिक प्रश्न और WP-CLI)

इन्हें एक स्टेजिंग कॉपी पर या पूर्ण बैकअप के बाद चलाएं।.

SQL के माध्यम से पोस्ट सामग्री में स्क्रिप्ट टैग के लिए खोजें:

SELECT ID, post_title 
FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%javascript:%' OR post_content LIKE '%data:%';

संदिग्ध ब्लॉक विशेषता मानों के लिए खोजें (सरल पैटर्न):

SELECT ID, post_title;

WP-CLI उदाहरण — सामग्री में “<script” वाले पोस्टों की सूची:

wp post list --post_type=post,page --format=csv --fields=ID,post_title \"

सामग्री को सैनिटाइज करने का उदाहरण (PHP + WP-CLI)। चलाने से पहले DB का बैकअप लें:

<?php

WAF और वर्चुअल पैचिंग: व्यावहारिक नियम जिन्हें आप आज लागू कर सकते हैं

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

उच्च-स्तरीय रणनीति:

• स्क्रिप्ट टैग शामिल करने वाले सहेजने को ब्लॉक या साफ करें, जावास्क्रिप्ट: या रैपर और फ़िल्टर को अस्वीकार करें: REST एंडपॉइंट्स या ब्लॉक संपादक द्वारा उपयोग किए जाने वाले admin-ajax क्रियाओं में POST शरीर में URI।.
• उन अनुरोधों को लक्षित करें जो ब्लॉक्स को सहेजते हैं (REST API: /wp-json/wp/v2/posts, संपादक एंडपॉइंट्स) और ब्लॉक-विशिष्ट संदर्भ के लिए अनुरोध शरीर का निरीक्षण करें।.
• प्रारंभ में मॉनिटर/लॉग-केवल मोड को प्राथमिकता दें और एक बार आत्मविश्वास होने पर ब्लॉकिंग की ओर बढ़ें।.

वैचारिक नियम पैटर्न (अपने WAF के अनुसार अनुकूलित करें)

स्क्रिप्ट टैग शामिल करने वाले पोस्ट को सहेजने वाले REST API पर POST को ब्लॉक करें:

स्थिति:

Press3D ब्लॉक के लिए लक्षित पैटर्न (PCRE-शैली):

/"blockName"\s*:\s*"press3d/model".*?"link"\s*:\s*\{.*?"url"\s*:\s*".*?(javascript:|data:|<script)/is

POST शरीर से मेल खाने के लिए उदाहरण संवेदनशील PCRE:

(?i)"blockName"\s*:\s*"press3d/model".*?"link"\s*:\s*\{.*?"url"\s*:\s*".*?(javascript:|data:|<script)

नोट्स:

• सुनिश्चित करें कि अनुरोध-शरीर निरीक्षण सक्षम और समायोजित है (कुछ WAFs में शरीर-आकार सीमाएँ होती हैं)।.
• यदि आपका फ़िल्टरिंग सिस्टम प्रमाणित उपयोगकर्ता संदर्भ पढ़ सकता है, तो लेखक या निम्न भूमिकाओं से अनुरोध आने पर कड़े नियम लागू करें।.
• गलत सकारात्मकता को कम करने के लिए वैध उपयोग के मामलों (SVG डेटा URIs, कुछ इनलाइन छवियाँ) को व्हाइटलिस्ट करें।.

पहचान और निगरानी सिफारिशें

• लेखकों द्वारा REST API पर POST में मेल खाने वाले वर्चुअल पैच नियमों और स्पाइक्स के लिए लॉग की निगरानी करें।.
• जब पोस्ट बनाए/अपडेट किए जाते हैं जिसमें शामिल होते हैं तो अलर्ट करें 9. या विशेषताओं जैसे onload=, जावास्क्रिप्ट:, या रैपर और फ़िल्टर को अस्वीकार करें: टोकन हो।.
• अपलोड और प्लगइन निर्देशिकाओं में अप्रत्याशित फ़ाइल निर्माण के लिए देखें और बैकडोर द्वारा अक्सर उपयोग किए जाने वाले कोड पैटर्न के लिए देखें (जैसे, eval(, base64_decode + preg_replace).
• पर हल्के क्रोन-आधारित regex स्कैन चलाएँ wp_posts 8. और wp_postmeta संदिग्ध टोकन के लिए।.

सुधार और पुनर्प्राप्ति - चरण-दर-चरण

1. बैकअप: परिवर्तन करने से पहले पूर्ण फ़ाइल और DB बैकअप।.
2. प्लगइन हटाएँ/अक्षम करें: Press3D को निष्क्रिय करें या प्रभावित ब्लॉकों को हटाएँ।.
3. सामग्री की सफाई: स्क्रिप्ट टैग हटाने और तटस्थ करने के लिए WP-CLI या स्क्रिप्टेड सैनिटाइज़र का उपयोग करें जावास्क्रिप्ट:/रैपर और फ़िल्टर को अस्वीकार करें: URI; संपादनों की मैन्युअल समीक्षा करें।.
4. क्रेडेंशियल्स: Author+ उपयोगकर्ताओं के लिए पासवर्ड रीसेट करें और API कुंजी या रहस्यों को घुमाएँ।.
5. फ़ाइल-प्रणाली जांच: अपलोड में अप्रत्याशित PHP फ़ाइलों के लिए खोजें और फ़ाइल की अखंडता को विश्वसनीय बैकअप से तुलना करें।.
6. फिर से स्कैन करें: सुधार को मान्य करने के लिए मैलवेयर स्कैनर और अखंडता जांच का उपयोग करें।.
7. पैच/अपडेट: जब एक प्लगइन अपडेट उपलब्ध हो, तो उत्पादन में तैनात करने से पहले स्टेजिंग पर परीक्षण करें।.
8. घटना के बाद की समीक्षा: यह निर्धारित करें कि इंजेक्शन कैसे हुआ, और तदनुसार भूमिकाएँ और प्रशिक्षण समायोजित करें।.

दीर्घकालिक स्थिरता के लिए हार्डनिंग सिफारिशें

• न्यूनतम विशेषाधिकार: लेखकों के लिए क्षमताओं को कम करें; बिना फ़िल्टर किए गए HTML के बिना कस्टम भूमिकाओं पर विचार करें।.
• unfiltered_html को निष्क्रिय करें उन भूमिकाओं के लिए जिन्हें इसकी आवश्यकता नहीं है।.
• PHP निष्पादन की अनुमति न दें अपलोड्स निर्देशिका में (वेब सर्वर नियम)।.
• सुरक्षित कुकीज़: HttpOnly और Secure ध्वज सेट करें; SameSite को उचित रूप से सेट करें।.
• सामग्री सुरक्षा नीति (CSP): रिपोर्ट-केवल से शुरू करें और पुनरावृत्ति करें। एक प्रतिबंधात्मक CSP जो इनलाइन स्क्रिप्ट को ब्लॉक करती है, कई संग्रहीत XSS पेलोड को कम करेगी। उदाहरण प्रारंभिक नीति:

सामग्री-सुरक्षा-नीति: डिफ़ॉल्ट-स्रोत 'स्वयं'; स्क्रिप्ट-स्रोत 'स्वयं' https://trusted.cdn.example; ऑब्जेक्ट-स्रोत 'कोई नहीं'; आधार-यूआरआई 'स्वयं'; फ़्रेम-पूर्वज 'कोई नहीं';

• दो-कारक प्रमाणीकरण: उच्चाधिकार वाले खातों के लिए 2FA की आवश्यकता है।.
• थीम/प्लगइन संपादक को निष्क्रिय करें:

  define( 'DISALLOW_FILE_EDIT', true );

• स्टेजिंग और परीक्षण: उत्पादन तैनाती से पहले प्लगइन अपडेट का परीक्षण करने के लिए स्टेजिंग बनाए रखें।.

किनारे पर वर्चुअल पैचिंग क्यों महत्वपूर्ण है

प्रकट करने, विक्रेता पैच, और व्यवस्थापक अपडेट के बीच अक्सर एक समय अंतराल होता है। वर्चुअल पैचिंग (अनुरोध फ़िल्टरिंग / WAF नियम) हमले की खिड़की को इंटरसेप्ट या साफ़ करके कम करता है। इसे एक अस्थायी उपाय के रूप में माना जाना चाहिए - सामग्री की सफाई और प्लगइन पैचिंग के लिए एक पूरक, प्रतिस्थापन नहीं।.

एक प्रबंधित WAF या अनुरोध-फ़िल्टर दृष्टिकोण आमतौर पर कैसे प्रतिक्रिया करता है

1. लक्षित हस्ताक्षर बनाएं जो ब्लॉक संदर्भ से मेल खाते हैं ताकि झूठे सकारात्मक को कम किया जा सके।.
2. हस्ताक्षरों को निगरानी मोड में तैनात करें, हिट की समीक्षा करें, फिर ट्यून होने पर ब्लॉकिंग पर स्विच करें।.
3. व्यवस्थापकों को संग्रहीत पेलोड को साफ़ करने के लिए पहचान प्रश्न और सामग्री-सफाई स्क्रिप्ट प्रदान करें।.
4. एक अपस्ट्रीम पैच स्थापित होने और सामग्री साफ़ होने के बाद, अस्थायी नियमों को समाप्त करें।.

व्यावहारिक आदेश और पुनर्लेखन जो आप अभी चला सकते हैं

सामग्री को ट्रायज और साफ़ करने में मदद करने के लिए उदाहरण:

# "javascript:" को सामग्री के अंदर खोजने वाले पोस्ट खोजें"

# मैन्युअल समीक्षा के लिए संदिग्ध पोस्ट निर्यात करें

उन्नत विकल्प: एक डेटाबेस ट्रिगर या मॉडरेशन कतार जोड़ें जो संदिग्ध पैटर्न वाले पोस्ट को सहेजने पर चिह्नित करता है (केवल सावधानी और परीक्षण के साथ उपयोग करें)।.

ब्लॉकिंग बनाम उपलब्धता का संतुलन - झूठे सकारात्मक और ट्यूनिंग

नियम जो मेल खाते हैं रैपर और फ़िल्टर को अस्वीकार करें: या जावास्क्रिप्ट: वैध उपयोगों (एंबेडेड SVGs, इनलाइन डेटा छवियों) को ब्लॉक कर सकता है। विघटन को कम करने के लिए:

• 48-72 घंटों के लिए मॉनिटर/लॉग-केवल मोड में शुरू करें और हिट की समीक्षा करें।.
• ज्ञात benign पैटर्न के लिए विश्वसनीय उपयोगकर्ताओं या एंडपॉइंट्स को व्हाइटलिस्ट करें।.
• संदर्भ-जानकारी वाले नियमों का उपयोग करें: समान पैटर्न के लिए विश्वसनीय प्रशासकों को अनुमति दें जबकि लेखकों को ब्लॉक करें।.
• एकल प्रशासक संपादनों को सामूहिक स्वचालित इंजेक्शनों से अलग करने के लिए दर-सीमा को ब्लॉकिंग के साथ मिलाएं।.

पोस्ट-घटना चेकलिस्ट (पुनर्प्राप्ति सत्यापन)

• प्रकाशित सामग्री में कोई स्क्रिप्ट टैग या दुर्भावनापूर्ण URI नहीं रहना चाहिए।.
• कोई संदिग्ध उपयोगकर्ता नहीं बनाए गए; कोई अज्ञात प्रशासक खाते मौजूद नहीं हैं।.
• प्लगइन/थीम/अपलोड निर्देशिकाओं में कोई अज्ञात या हाल ही में संशोधित फ़ाइलें नहीं हैं।.
• सभी प्लगइन्स/थीम्स को सुरक्षित संस्करणों में अपडेट किया गया है।.
• हमलों के हस्ताक्षर के लिए निगरानी और चेतावनी कम से कम 90 दिनों तक सक्रिय रहती है।.
• एक पोस्ट-घटना समीक्षा पूरी की गई है और संचालन प्रक्रियाओं में जोड़ी गई है।.

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: यदि एक लेखक ने दुर्भावनापूर्ण कोड डाला, तो क्या इसका मतलब है कि लेखक दुर्भावनापूर्ण है?

उत्तर: जरूरी नहीं। लेखक खाते समझौता किए जा सकते हैं (फिशिंग, पुन: उपयोग किए गए पासवर्ड)। इंजेक्शनों को घटनाओं के रूप में मानें और क्रेडेंशियल्स और एक्सेस इतिहास की जांच करें।.

प्रश्न: क्या CSP पूरी तरह से XSS को रोक देगा?

उत्तर: CSP इनलाइन स्क्रिप्ट को ब्लॉक करके और स्क्रिप्ट स्रोतों को प्रतिबंधित करके प्रतिरोध को महत्वपूर्ण रूप से बढ़ाता है, लेकिन इसे सही तरीके से कॉन्फ़िगर करना चाहिए। सुरक्षित कुकीज़, इनपुट सैनिटाइजेशन और एज फ़िल्टरिंग के साथ CSP का उपयोग करें।.

प्रश्न: क्या मैं केवल स्वचालित स्कैनरों पर भरोसा कर सकता हूँ?

उत्तर: स्वचालित स्कैनर मदद करते हैं लेकिन जटिल ब्लॉक विशेषताओं में संग्रहीत XSS को चूक सकते हैं। स्वचालित स्कैन को लक्षित DB क्वेरी, मैनुअल समीक्षा और लॉग निगरानी के साथ मिलाएं।.

समापन सारांश

Press3D प्लगइन में संग्रहीत XSS विश्वसनीय सामग्री पथों जैसे Gutenberg ब्लॉक विशेषताओं के जोखिम को उजागर करता है जब इनपुट को मान्य या एस्केप नहीं किया जाता है। तात्कालिक प्राथमिकताएँ: प्रभावित साइटों की पहचान करें, जहां संभव हो प्लगइन को अक्षम या हटा दें, संग्रहीत सामग्री को सैनिटाइज करें, क्रेडेंशियल्स को घुमाएँ, और सफाई करते समय एज फ़िल्टरिंग लागू करें। दीर्घकालिक शमन में न्यूनतम विशेषाधिकार, CSP, सुरक्षित कुकी ध्वज, और सावधानीपूर्वक अपडेट/परीक्षण प्रक्रियाएँ शामिल हैं।.

यदि आपको अपने वातावरण के लिए पहचान प्रश्न बनाने या अनुरोध फ़िल्टर को ट्यून करने में सहायता की आवश्यकता है, तो एक योग्य सुरक्षा सलाहकार या अपनी होस्टिंग/डेवऑप्स टीम को शामिल करने पर विचार करें। यह विश्लेषण स्पष्ट, कार्यात्मक कदम प्रदान करने का लक्ष्य रखता है जिन्हें आप तुरंत लागू कर सकते हैं।.