तत्काल: ओगुलो – 360° टूर में प्रमाणित योगदानकर्ता संग्रहीत XSS (<=1.0.11) — वर्डप्रेस साइट मालिकों को अब क्या करना चाहिए

तारीख: 2025-08-22   |   लेखक: WP-फायरवॉल अनुसंधान टीम

सारांश: एक संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता (CVE-2025-9131) का खुलासा किया गया है जो ओगुलो – 360° टूर वर्डप्रेस प्लगइन (संस्करण <= 1.0.11) को प्रभावित करता है। एक प्रमाणित उपयोगकर्ता जिसके पास योगदानकर्ता स्तर के विशेषाधिकार या उससे अधिक हैं, वह प्लगइन के स्लग पैरामीटर के माध्यम से साइट में दुर्भावनापूर्ण सामग्री इंजेक्ट कर सकता है। यह पोस्ट जोखिम को तोड़ती है, व्यावहारिक शमन कदमों को समझाती है, और उन तात्कालिक और दीर्घकालिक नियंत्रणों का वर्णन करती है जिन्हें आपको तुरंत लागू करना चाहिए।.

यह क्यों महत्वपूर्ण है (साधारण भाषा)

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

प्रमुख तथ्य:

• भेद्यता: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)
• प्रभावित प्लगइन: ओगुलो – 360° टूर (संस्करण <= 1.0.11)
• CVE: CVE-2025-9131
• शोषण के लिए आवश्यक विशेषाधिकार: योगदानकर्ता
• सार्वजनिक खुलासा तिथि: 2025-08-22
• आधिकारिक पैच: प्रकाशन के समय उपलब्ध नहीं

साइटें जो अतिथि लेखकों, रियल एस्टेट भागीदारों, या तीसरे पक्ष के योगदानकर्ताओं की अनुमति देती हैं, वे उच्च जोखिम में हैं क्योंकि योगदानकर्ता खाते आमतौर पर ऐसे कार्यप्रवाहों के लिए उपयोग किए जाते हैं।.

तकनीकी अवलोकन (क्या हो रहा है)

यह एक क्लासिक स्टोर किया गया XSS है: एक उपयोगकर्ता-नियंत्रित मान (पोस्ट स्लग / पोस्ट_नाम) को सही तरीके से मान्य या एस्केप नहीं किया जाता है इससे पहले कि इसे सहेजा जाए और बाद में प्रशासनिक या सार्वजनिक संदर्भ में प्रदर्शित किया जाए। प्लगइन प्रमाणित उपयोगकर्ताओं से एक स्लग पैरामीटर स्वीकार करता है और उस पैरामीटर में खतरनाक वर्णों और मार्कअप को साफ़ या प्रतिबंधित करने में विफल रहता है, जिससे स्क्रिप्ट-जैसे पेलोड को स्टोर करने की अनुमति मिलती है।.

जब एक व्यवस्थापक या अन्य विशेषाधिकार प्राप्त उपयोगकर्ता प्रशासनिक इंटरफ़ेस में पृष्ठ को देखता है (या यदि स्लग प्रदर्शित होता है तो संभावित सार्वजनिक दृश्य में), तो स्टोर किया गया पेलोड उनके ब्राउज़र में साइट के मूल के तहत निष्पादित होता है। चूंकि स्क्रिप्ट एक लॉगिन किए गए व्यवस्थापक के संदर्भ में चलती है, यह कुकीज़, स्थानीय भंडारण तक पहुँच सकती है, या संवेदनशील कार्यों को करने के लिए DOM-आधारित क्रियाएँ कर सकती है जो व्यवस्थापक के प्रमाणित सत्र का उपयोग करती हैं।.

यह विशेष रूप से समस्या क्यों है:

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

वास्तविक दुनिया के प्रभाव परिदृश्य

1. क्रेडेंशियल चोरी और खाता अधिग्रहण

   दुर्भावनापूर्ण स्लग पेलोड एक व्यवस्थापक के ब्राउज़र को हमलावर-नियंत्रित एंडपॉइंट पर कुकीज़ या टोकन भेजने का कारण बन सकते हैं। वे टोकन सत्र अपहरण या खाता अधिग्रहण की अनुमति दे सकते हैं।.

2. विशेषाधिकार वृद्धि या सामग्री विषाक्तता

   एक समझौता किया गया व्यवस्थापक खाता बैकडोर स्थापित करने, नए व्यवस्थापक उपयोगकर्ताओं को बनाने, रीडायरेक्ट इंजेक्ट करने, या SEO स्पैम डालने के लिए उपयोग किया जा सकता है।.

3. भागीदार और आपूर्ति श्रृंखला समझौता

   भागीदार योगदान वाले साइटों पर, हमलावर उच्च-मूल्य वाले भागीदार खातों को लक्षित कर सकते हैं या संवेदनशील भागीदार/CRM डेटा को निकाल सकते हैं जिसे व्यवस्थापकों द्वारा एक्सेस किया गया है।.

4. स्थायी मैलवेयर और SEO स्पैम

   स्टोर किए गए पेलोड स्थायी रूप से क्रिप्टोमाइनर्स, स्पैम लिंक, या ड्राइव-बाय मैलवेयर को सेवा दे सकते हैं जो आगंतुकों और खोज रैंकिंग को नुकसान पहुँचाते हैं।.

शोषण की कठिनाई और पूर्वापेक्षाएँ

पूर्वापेक्षाएँ:

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

कठिनाई: सीधे जहां योगदानकर्ता स्लग को नियंत्रित कर सकते हैं। शोषण उन साइटों पर सबसे खतरनाक है जहां व्यवस्थापक अक्सर नए सबमिशन का पूर्वावलोकन या प्रबंधन करते हैं।.

संभावना: उन साइटों पर मध्यम से उच्च जो योगदानकर्ता-स्तरीय सामग्री स्वीकार करती हैं; कड़ी नियंत्रण वाली साइटों पर कम।.

साइट मालिकों के लिए तात्कालिक कार्रवाई (अल्पकालिक शमन)

यदि आपकी साइट प्रभावित प्लगइन का उपयोग करती है और कोई आधिकारिक पैच अभी उपलब्ध नहीं है, तो इन चरणों को तुरंत लागू करें।.

1. योगदानकर्ता पहुंच को प्रतिबंधित करें

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

2. प्लगइन को निष्क्रिय या हटा दें

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

3. संदिग्ध स्लग और पेलोड के लिए डेटाबेस को स्कैन करें

   wp_posts.post_name में स्क्रिप्ट-जैसे या एन्कोडेड पेलोड के लिए खोजें। उदाहरण SQL (हमेशा पहले DB का बैकअप लें):

   -- Example SQL (run via wp-cli or phpMyAdmin after making a DB backup)
   SELECT ID, post_title, post_name FROM wp_posts
   WHERE post_name REGEXP '(<script|%3Cscript|javascript:|on[a-z]+=)';

   हटाने से पहले संदिग्ध प्रविष्टियों की पुष्टि करें; गलत सकारात्मक संभव हैं।.

4. मौजूदा प्रविष्टियों को साफ करें

   उन्हें प्रस्तुत करने या फिर से सहेजने से पहले वर्डप्रेस कोर फ़ंक्शंस का उपयोग करके स्लग को सामान्य करें। उदाहरण के लिए, sanitize_title() के साथ post_name को साफ करने के बाद संदिग्ध पोस्ट को फिर से सहेजें।.

5. शोषण प्रयासों के लिए लॉग की निगरानी करें

   अप्रत्याशित वर्णों के साथ स्लग पैरामीटर वाले असामान्य POST अनुरोधों पर नज़र रखें। एक ही IP या खाते से बार-बार प्रयासों पर अलर्ट करें।.

6. अपने संपादकों और व्यवस्थापकों को सूचित करें

   अपनी टीम को बताएं कि जब तक समस्या का समाधान नहीं हो जाता, तब तक संदिग्ध सामग्री पर क्लिक न करें या नए योगदानकर्ताओं से पूर्वावलोकन लिंक न खोलें।.

सुरक्षित डेवलपर शमन (सर्वर / कोड-पक्ष)

साइट ऑपरेटर या डेवलपर्स त्वरित, कम प्रयास वाले फ़िल्टर जोड़ सकते हैं जो वातावरण को मजबूत करते हैं:

1. पोस्ट सम्मिलन पर स्लग स्वच्छता लागू करें

   सहेजने से पहले post_name को स्वच्छ करने के लिए एक फ़िल्टर जोड़ें:

   // एक mu-plugin या थीम functions.php में जोड़ें (पहले स्टेजिंग पर परीक्षण करें);

   sanitize_title() एक वर्डप्रेस कोर फ़ंक्शन है जो असुरक्षित वर्णों को हटा देता है; इसे कस्टम एड-हॉक स्वच्छकर्ताओं के बजाय उपयोग करें।.

2. स्लग को एस्केप करें और प्रशासनिक दृश्य में आउटपुट करें

   प्रशासनिक टेम्पलेट में प्रिंट करते समय हमेशा डेटा को एस्केप करें:

   echo esc_attr( $post->post_name );

3. प्लगइन एंडपॉइंट्स पर क्षमता जांचें

   सुनिश्चित करें कि स्लग डेटा स्वीकार करने वाले एंडपॉइंट्स केवल उन भूमिकाओं के लिए चलें जिन्हें नियंत्रण की आवश्यकता है:

   if ( ! current_user_can( 'edit_posts' ) ) {

4. REST और AJAX इनपुट को स्वच्छ करें

   REST अनुरोध सत्यापन कॉलबैक का उपयोग करें और फ़ील्ड को स्वच्छ करें; उन अनुरोधों को अस्वीकार करें जहां स्लग में अनुमति न दिए गए वर्ण होते हैं।.

इन परिवर्तनों को पहले स्टेजिंग पर लागू करें और पूरी तरह से परीक्षण करें; ये शमन हैं जब तक कि प्लगइन रखरखाव करने वाला एक औपचारिक पैच जारी नहीं करता।.

वर्चुअल पैचिंग और प्रबंधित WAFs (आप अभी क्या कर सकते हैं)

जब एक आधिकारिक सुधार अभी उपलब्ध नहीं है, तो वेब एप्लिकेशन परिधि पर वर्चुअल पैचिंग एक प्रभावी अस्थायी उपाय हो सकता है। प्रबंधित WAFs या परिधि नियमों को एप्लिकेशन तक पहुँचने से पहले शोषण प्रयासों को ब्लॉक कर सकते हैं।.

अनुशंसित वर्चुअल-पैचिंग रणनीतियाँ (विक्रेता-निष्पक्ष):

• उन अनुरोधों को ब्लॉक करें जहां स्लग-जैसे पैरामीटर संदिग्ध पैटर्न (<script, javascript:, on* हैंडलर, एन्कोडेड समकक्ष) शामिल हैं।.
• POST, PUT और REST API पेलोड की जांच करें, URL-एन्कोडेड मानों को डिकोड करें, और ओबफस्केटेड पेलोड का पता लगाएं।.
• केवल वैध स्लग की अनुमति दें जिसमें अल्फ़ान्यूमेरिक वर्ण, डैश और अंडरस्कोर शामिल हों; समीक्षा के लिए अन्य को फ्लैग या ब्लॉक करें।.
• ब्लॉक किए गए प्रयासों पर लॉग और अलर्ट करें; पुनरावृत्ति अपराधियों को दर-सीमा लगाने या अस्थायी रूप से ब्लॉक करने पर विचार करें।.

वर्चुअल पैचिंग उचित कोड फिक्स के लिए एक स्थायी विकल्प नहीं है, लेकिन यह संग्रहीत XSS पेलोड को सहेजने से रोक सकता है और कोड-स्तरीय शमन लागू करते समय जोखिम को कम कर सकता है और आधिकारिक पैच की प्रतीक्षा कर सकता है।.

पहचान: क्या देखना है (समझौते के संकेत)

संकेत कि भेद्यता का शोषण किया जा सकता है:

• अप्रत्याशित व्यवस्थापक व्यवहार या नए व्यवस्थापक उपयोगकर्ता।.
• सार्वजनिक पृष्ठों से अनिर्दिष्ट रीडायरेक्ट।.
• पृष्ठों में JavaScript जो आपने या आपके संपादकों ने नहीं जोड़ा।.
• डेटाबेस प्रविष्टियाँ (post_name या मेटा मान) जिनमें कोणीय ब्रैकेट, स्क्रिप्ट टैग, या एन्कोडेड पेलोड शामिल हैं।.
• एक्सेस लॉग जो संदिग्ध पेलोड के साथ स्लग स्वीकार करने वाले एंडपॉइंट्स पर POST या REST अनुरोध दिखाते हैं।.
• सुरक्षा उपकरणों या WAFs से ब्लॉक किए गए स्क्रिप्ट-जैसे सामग्री के बारे में अलर्ट।.

सुझाए गए प्रश्न (चलाने से पहले हमेशा बैकअप लें):

SELECT ID, post_name, post_title FROM wp_posts
WHERE post_name REGEXP '(<script|%3Cscript|javascript:|on[a-z]+\s*=)' LIMIT 100;

SELECT post_id, meta_key, meta_value FROM wp_postmeta
WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 200;

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 200;.

यदि आप संदिग्ध प्रविष्टियाँ पाते हैं: सबूत (DB डंप, लॉग) निर्यात और संरक्षित करें, दुर्भावनापूर्ण फ़ील्ड को साफ करें (sanitize_title() या सुरक्षित रूप से पोस्ट फिर से सहेजें), और यदि समझौता होने का संदेह हो तो व्यवस्थापक क्रेडेंशियल और API कुंजी को घुमाएँ।

1. दीर्घकालिक सुधार और हार्डनिंग

   न्यूनतम विशेषाधिकार के सिद्धांत को लागू करें.

2. भूमिकाओं और क्षमताओं का पुनर्मूल्यांकन करें। योगदानकर्ता खातों को विश्वसनीय उपयोगकर्ताओं तक सीमित करें। एक्सेस को ठीक करने के लिए भूमिका प्रबंधन का उपयोग करें।

   साइट-व्यापी इनपुट मान्यता को हार्डन करें.

3. सभी उपयोगकर्ता-प्रस्तुत स्ट्रिंग्स को अविश्वसनीय मानें। इनपुट पर मान्य करें और साफ करें; आउटपुट पर एस्केप करें।

   बाहरी योगदान के लिए संपादकीय समीक्षा की आवश्यकता; योगदानकर्ता खातों द्वारा सीधे प्रकाशन को रोकें।.

4. सॉफ़्टवेयर को अद्यतित रखें

   जैसे ही सत्यापित पैच उपलब्ध हों, WordPress कोर, थीम और प्लगइन्स को अपडेट करें।.

5. व्यापक लॉगिंग और निगरानी लागू करें

   WAF लॉग, सर्वर लॉग और WordPress गतिविधि लॉग को बनाए रखें। असामान्य सहेजने या प्रशासनिक गतिविधि की निगरानी करें।.

6. स्वचालित भेद्यता स्कैनिंग का उपयोग करें

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

7. सामग्री सुरक्षा नीति (CSP) का उपयोग करें

   एक सावधानीपूर्वक परिभाषित CSP इनलाइन स्क्रिप्ट और शत्रुतापूर्ण बाहरी स्क्रिप्ट को ब्लॉक करके XSS प्रभाव को कम कर सकता है। वैध सुविधाओं को तोड़ने से बचने के लिए CSP का पूरी तरह से परीक्षण करें।.

घटना प्रतिक्रिया चेकलिस्ट (यदि आपको शोषित किया गया)

1. अलग करें: यदि संभव हो तो साइट को रखरखाव मोड में डालें; असामान्य IP को अस्थायी रूप से ब्लॉक करें और प्रशासनिक पहुंच को प्रतिबंधित करें।.
2. सबूत को संरक्षित करें: विश्लेषण के लिए डेटाबेस स्नैपशॉट और लॉग को सुरक्षित स्थान पर निर्यात करें।.
3. साफ करें: पोस्ट, मेटाडेटा और प्लगइन सेटिंग्स से दुर्भावनापूर्ण संग्रहीत पेलोड को हटा दें। साफ स्रोतों से कोर/थीम/प्लगइन्स को फिर से स्थापित करें।.
4. क्रेडेंशियल्स को घुमाएं: सभी प्रशासकों के लिए पासवर्ड रीसेट करें और API कुंजी या एप्लिकेशन पासवर्ड को फिर से जारी करें।.
5. पुनर्स्थापित करें: यदि आवश्यक हो तो एक साफ बैकअप से पुनर्स्थापित करें।.
6. विश्लेषण करें और मजबूत करें: मूल कारण विश्लेषण करें, कोड पैच करें, भूमिकाओं और प्लगइन स्वच्छता की समीक्षा करें।.
7. सूचित करें: यदि संवेदनशील डेटा उजागर हुआ है तो प्रभावित हितधारकों और भागीदारों को सूचित करें।.

जिम्मेदार प्रकटीकरण और त्वरित विक्रेता प्रतिक्रिया क्यों महत्वपूर्ण है

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

• सभी उपयोगकर्ता इनपुट को साफ करें और मान्य करें, विशेष रूप से उन फ़ील्ड को जो डेटाबेस में संग्रहीत हैं और प्रशासनिक संदर्भों में प्रदर्शित होते हैं।.
• अपने स्वयं के स्वच्छता के बजाय कोर एपीआई (sanitize_title, sanitize_text_field, wp_kses) का उपयोग करें।.
• बिना एस्केप किए प्रशासनिक पृष्ठों में कच्चे इनपुट को दर्शाने से बचें।.

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

प्रश्न: यदि मेरी साइट योगदानकर्ताओं को स्वीकार नहीं करती है, तो क्या मैं सुरक्षित हूँ?
उत्तर: जोखिम कम है, लेकिन यह सत्यापित करें कि क्या प्लगइन्स, एकीकरण, या आयात आपके पक्ष में स्लग सेट कर सकते हैं। यह भी जांचें कि क्या पिछले योगदानकर्ताओं ने पहले से ही सामग्री इंजेक्ट की हो सकती है।.

प्रश्न: क्या संग्रहीत XSS का उपयोग उन आगंतुकों द्वारा किया जा सकता है जो लॉग इन नहीं हैं?
उत्तर: हाँ—यदि संग्रहीत पेलोड सार्वजनिक पृष्ठों को प्रभावित करता है। प्रशासकों के खिलाफ हमले आमतौर पर उच्च विशेषाधिकार के कारण अधिक गंभीर होते हैं।.

प्रश्न: क्या सामग्री सुरक्षा नीति पर्याप्त है?
उत्तर: CSP एक मजबूत रक्षा-इन-गहराई उपाय है लेकिन उचित इनपुट मान्यता और स्वच्छता का विकल्प नहीं है।.

प्रश्न: क्या मुझे प्लगइन हटाना चाहिए?
उत्तर: यदि गैर-आवश्यक है, तो इसे निष्क्रिय करना या हटाना सबसे सुरक्षित तात्कालिक कदम है। यदि आवश्यक है, तो पैच उपलब्ध होने तक हार्डनिंग, डेटाबेस स्कैन और परिधीय नियमों को प्राथमिकता दें।.

सारांश और अंतिम सिफारिशें

ओगुलो – 360° टूर संग्रहीत XSS (CVE-2025-9131) यह दर्शाता है कि स्लग जैसे सरल इनपुट बिंदु जब मान्य नहीं होते हैं तो हमले के वेक्टर बन सकते हैं। क्योंकि एक योगदानकर्ता खाता इस भेद्यता को सक्रिय कर सकता है, कोई भी साइट जो उपयोगकर्ता योगदानों की अनुमति देती है बिना सख्त समीक्षा के संभावित रूप से उजागर होती है।.

तात्कालिक कार्य योजना (क्रमबद्ध):

1. यदि आप प्लगइन चला रहे हैं तो जोखिम मानें: योगदानकर्ताओं को प्रतिबंधित करें या जहां संभव हो तुरंत प्लगइन को निष्क्रिय करें।.
2. सर्वर-साइड और कोड-साइड उपाय लागू करें (स्लग सैनीटाइजेशन, क्षमता जांच)।.
3. यदि आप प्लगइन को पैच नहीं कर सकते हैं, तो आक्रामक पेलोड को ब्लॉक करने के लिए परिधि पर वर्चुअल पैचिंग लागू करें (प्रबंधित WAF नियम)।.
4. संग्रहीत पेलोड के डेटाबेस को स्कैन और साफ करें; यदि समझौता होने का संदेह हो तो व्यवस्थापक क्रेडेंशियल्स को बदलें।.
5. लॉग की निगरानी करें और यदि आवश्यक हो तो साफ बैकअप से पुनर्स्थापित करने के लिए तैयार रहें।.
6. जैसे ही एक सत्यापित पैच जारी किया जाता है, प्लगइन को अपडेट करें।.

यदि आपको ऊपर बताए गए तकनीकी उपायों को लागू करने में सहायता की आवश्यकता है, तो तत्काल सफाई, स्कैनिंग और हार्डनिंग में मदद के लिए एक विश्वसनीय सुरक्षा पेशेवर को शामिल करने पर विचार करें। हांगकांग और व्यापक क्षेत्र में ऐसे सलाहकार और घटना प्रतिक्रिया टीमें हैं जो वर्डप्रेस घटना हैंडलिंग में अनुभवी हैं और वर्णित कदमों को लागू करने में मदद कर सकते हैं।.

सतर्क रहें। इनपुट को मान्य करें, विशेषाधिकार सीमित करें, और सॉफ़्टवेयर को अपडेट रखें।.