हांगकांग सुरक्षा सलाहकार संपर्क प्रबंधक XSS(CVE20258783)

वर्डप्रेस संपर्क प्रबंधक प्लगइन
प्लगइन का नाम संपर्क प्रबंधक
कमजोरियों का प्रकार प्रमाणित संग्रहीत XSS
CVE संख्या CVE-2025-8783
तात्कालिकता कम
CVE प्रकाशन तिथि 2025-08-19
स्रोत URL CVE-2025-8783

संपर्क प्रबंधक प्लगइन (≤ 8.6.5) — प्रमाणित प्रशासक द्वारा “शीर्षक” के माध्यम से संग्रहीत XSS: वर्डप्रेस साइट के मालिकों को क्या जानना चाहिए

तारीख: 19 अगस्त 2025
CVE: CVE-2025-8783
प्रभावित संस्करण: संपर्क प्रबंधक प्लगइन ≤ 8.6.5
में ठीक किया गया: 8.6.6
आवश्यक विशेषाधिकार: प्रशासक
गंभीरता (रिपोर्ट की गई): CVSS 5.9 — कम (संदर्भ महत्वपूर्ण है)

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

कार्यकारी सारांश (त्वरित पढ़ाई)

  • भेद्यता प्रकार: “शीर्षक” फ़ील्ड के माध्यम से संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)।.
  • शोषण पूर्व शर्त: हमलावर को साइट पर प्रशासक विशेषाधिकार होना चाहिए।.
  • प्रभाव: उन संदर्भों में हमलावर-नियंत्रित जावास्क्रिप्ट का निष्पादन जहां शीर्षक प्रस्तुत किया जाता है — पुनर्निर्देशित करता है, सामग्री इंजेक्शन, सत्र चोरी, विशेषाधिकार वृद्धि और स्थिरता की ओर ले जाता है।.
  • तात्कालिक समाधान: संपर्क प्रबंधक को 8.6.6 या बाद के संस्करण में अपडेट करें।.
  • यदि आप तुरंत अपडेट नहीं कर सकते: WAF नियमों (सामान्य) के माध्यम से आभासी पैचिंग लागू करें, सख्त प्रशासक नियंत्रण लागू करें (MFA, पासवर्ड रोटेशन), और संग्रहीत सामग्री की खोज/साफ करें।.

संग्रहीत XSS वास्तव में क्या है और यह बग कैसे काम करता है

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

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

प्रमुख विचार:

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

CVSS स्कोर “कम” क्यों है - और आपको अभी भी क्यों परवाह करनी चाहिए

CVSS स्कोर (5.9) उच्च विशेषाधिकार की आवश्यकता को दर्शाता है। हालाँकि, वास्तविक संचालन में गंभीरता बहुत अधिक हो सकती है क्योंकि:

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

व्यवस्थापक-फेसिंग संग्रहीत XSS को एक गंभीर संचालन जोखिम के रूप में मानें, न कि केवल एक कम प्राथमिकता वाले CVE नंबर के रूप में।.

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

  1. दुर्भावनापूर्ण व्यवस्थापक JavaScript डालता है जो AJAX कॉल करता है ताकि एक नया व्यवस्थापक उपयोगकर्ता बनाया जा सके या क्षमताओं को संशोधित किया जा सके, एक बैकडोर खाते को बनाए रखते हुए।.
  2. इंजेक्टेड स्क्रिप्ट सत्र कुकीज़ या स्थानीय भंडारण टोकन चुराती है और उन्हें एक हमलावर-नियंत्रित एंडपॉइंट पर अग्रेषित करती है, सत्र अधिग्रहण को सक्षम बनाती है।.
  3. स्क्रिप्ट अपलोड फ़ॉर्म या अनुसूचित कार्यों को संशोधित करती है ताकि एक वेबशेल को एक दूरस्थ होस्ट से लाया जा सके और इसे डिस्क पर लिखा जा सके।.
  4. लक्षित फ़िशिंग: पेलोड नकली प्रॉम्प्ट प्रदर्शित करता है या कुछ व्यवस्थापक उपयोगकर्ताओं को क्रेडेंशियल-हर्वेस्टिंग पृष्ठों पर पुनर्निर्देशित करता है।.
  5. पेलोड तीसरे पक्ष की स्क्रिप्ट (विश्लेषण, विज्ञापन) को हेरफेर करता है ताकि दुर्भावनापूर्ण सामग्री को और फैलाया जा सके या अतिरिक्त अन्वेषण किया जा सके।.

1. समझौते के संकेत (क्या देखना है)

  • शीर्षक या संपर्क प्रविष्टियाँ जिनमें अप्रत्याशित टैग या इनलाइन इवेंट विशेषताएँ (onclick=, onerror=, onload=) शामिल हैं।.
  • नए व्यवस्थापक खाते जिन्हें आपने नहीं बनाया।.
  • डैशबोर्ड विजेट या नोटिस जो अपरिचित HTML या बाहरी स्क्रिप्ट संदर्भों को शामिल करते हैं।.
  • अज्ञात डोमेन के लिए आउटबाउंड सर्वर कनेक्शन (वेब सर्वर और DNS लॉग की जांच करें)।.
  • नए क्रोन कार्य या /wp-content/uploads/ या प्लगइन निर्देशिकाओं के तहत संशोधित फ़ाइलें।.
  • अपरिचित IPs या असामान्य उपयोगकर्ता एजेंट से व्यवस्थापक लॉगिन।.
  • इंजेक्टेड सामग्री के बारे में खोज कंसोल या वेबमास्टर टूल चेतावनियाँ।.

एक त्वरित डेटाबेस जांच का नमूना: “ <script” या “javascript:” या सामान्य अस्पष्ट रूपांतरों को शामिल करने वाले फ़ील्ड के लिए प्लगइन तालिकाओं की खोज करें। हमलावर पेलोड को अस्पष्ट कर सकते हैं, इसलिए खोजों को एन्कोडेड स्ट्रिंग्स और विशेषताओं जैसे “onerror=” तक विस्तारित करें।.

तात्कालिक सुधारात्मक कदम (साइट मालिक चेकलिस्ट)

  1. पहले प्राथमिकता के रूप में संपर्क प्रबंधक प्लगइन को संस्करण 8.6.6 या बाद के संस्करण में अपडेट करें।.
  2. यदि आप तुरंत प्लगइन अपडेट लागू नहीं कर सकते हैं, तो सार्वजनिक पृष्ठों के लिए साइट को रखरखाव मोड में ले जाने पर विचार करें और प्रभावित एंडपॉइंट्स पर स्क्रिप्ट-जैसे सामग्री वाले सबमिशन को ब्लॉक करने के लिए अस्थायी HTTP-लेयर नियंत्रण (WAF नियम) लागू करें।.
  3. सभी व्यवस्थापक पासवर्ड को घुमाएं और मजबूत, अद्वितीय पासवर्ड लागू करें। घुमाने के बाद सभी उपयोगकर्ताओं के लिए लॉगआउट करने के लिए मजबूर करें।.
  4. सभी व्यवस्थापक खातों पर मल्टी-फैक्टर प्रमाणीकरण (MFA) सक्षम करें।.
  5. संग्रहीत XSS पेलोड के लिए डेटाबेस की खोज करें (जैसे “<script”, “onerror=”, “javascript:” और एन्कोडेड रूपांतर) और प्रविष्टियों को हटा दें या साफ करें।.
  6. साइट को बैकडोर, बदले हुए कोर फ़ाइलों और संदिग्ध अपलोड के लिए स्कैन करें।.
  7. व्यवस्थापक खातों का ऑडिट करें और उन खातों को हटा दें या जांचें जो अब आवश्यक नहीं हैं या संदिग्ध लगते हैं।.
  8. शीर्षक या संपर्क डेटा स्वीकार करने वाले एंडपॉइंट्स पर संदिग्ध POST के लिए सर्वर एक्सेस और त्रुटि लॉग की समीक्षा करें।.
  9. यदि सर्वर-साइड समझौते के सबूत मौजूद हैं (बैकडोर, संशोधित PHP फ़ाइलें), तो ज्ञात-साफ बैकअप से पुनर्स्थापित करें और सभी रहस्यों (API कुंजी, DB क्रेडेंशियल) को घुमाएं।.

वर्चुअल पैचिंग और HTTP-लेयर शमन (सामान्य मार्गदर्शन)

जब तात्कालिक पैचिंग संभव नहीं हो, तो HTTP-लेयर सुरक्षा (जैसे WAF नियम) सामान्य शोषण पेलोड को एप्लिकेशन तक पहुँचने से पहले ब्लॉक करके जोखिम को कम कर सकती है। ये शमन इस प्रकार होने चाहिए:

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

डेवलपर मार्गदर्शन - “शीर्षक” फ़ील्ड को संभालने के लिए सुरक्षित कोडिंग पैटर्न

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

  • सहेजने पर सैनिटाइज करें:
    • सामान्य पाठ शीर्षकों के लिए sanitize_text_field() का उपयोग करें।.
    • यदि सीमित HTML की आवश्यकता है, तो स्पष्ट व्हाइटलिस्ट के साथ wp_kses() का उपयोग करें।.
  • आउटपुट पर एस्केप करें:
    • HTML शरीर के लिए: esc_html() का उपयोग करें।.
    • विशेषताओं के लिए: esc_attr() का उपयोग करें।.
    • HTML के नियंत्रित उपसमुच्चय की अनुमति देने के लिए: wp_kses_post() या कस्टम wp_kses() के साथ स्वच्छ करें, फिर सुरक्षित रूप से आउटपुट करें।.
  • REST एंडपॉइंट्स को क्षमता जांच और अनुमति कॉलबैक के साथ सुरक्षित करें। REST API स्कीमा स्वच्छता कॉलबैक का उपयोग करें और जहां लागू हो, नॉनस की पुष्टि करें।.
  • सीधे SQL के लिए $wpdb->prepare() का उपयोग करें; जोखिम को कम करने के लिए WP APIs (update_post_meta, wp_insert_post) को प्राथमिकता दें।.
  • प्रशासनिक क्रियाओं का लॉग रखें (किसने क्या और कब बदला) ताकि घटना के बाद फोरेंसिक्स में मदद मिल सके।.

सुरक्षित सहेजने का उदाहरण (PHP)

<?php

सुरक्षित आउटपुट का उदाहरण (PHP)

<?php

नमूना WAF नियम और पहचान हस्ताक्षर (संकल्पनात्मक)

निम्नलिखित संकल्पनात्मक पहचान पैटर्न हैं जो स्टेजिंग/परीक्षण के लिए अभिप्रेत हैं। ये उदाहरण हैं - इन्हें अपने वातावरण के अनुसार समायोजित करें और झूठे सकारात्मक को कम करने के लिए मान्य करें।.

1) Detect script tags in POST payloads:
   - Rule: Block if POST body contains "<script" or "</script>" or encoded variants like "%3Cscript%3E".
   - Pattern: (?i)(?:<\s*script\b|%3C\s*script%3E)

2) Detect inline JS event handlers in attributes inside title or subject fields:
   - Pattern: (?i)(on\w+\s*=\s*['"]?[^'">]+['"]?)

3) Detect javascript: pseudo-protocol in hrefs or src:
   - Pattern: (?i)javascript\s*:

4) Detect base64-encoded JS being sent:
   - Pattern: (?i)(?:data:\s*text/javascript;base64,|data:\s*application/javascript;base64,)

5) Block suspicious POSTs into known plugin endpoints if nonce is missing or invalid:
   - Logic: If endpoint is /wp-admin/admin-post.php?action=contact_manager_save AND POST contains field "title" with suspicious content => block.

6) Rate-limit admin login attempts and POST requests to admin endpoints to prevent brute force or automated mass submissions.

नोट: HTTP-स्तरीय नियम एक शमन परत हैं और आधिकारिक विक्रेता पैच और सुरक्षित कोड परिवर्तनों का विकल्प नहीं हैं।.

पुनर्प्राप्ति और घटना प्रतिक्रिया प्लेबुक

  1. सीमित करें
    • यदि सक्रिय शोषण हो रहा है तो साइट को ऑफ़लाइन करें या रखरखाव मोड सक्षम करें।.
    • IP या प्रमाणीकरण द्वारा महत्वपूर्ण एंडपॉइंट्स तक सार्वजनिक पहुंच को अस्थायी रूप से प्रतिबंधित करें।.
  2. समाप्त करें
    • डेटाबेस से दुर्भावनापूर्ण प्रविष्टियाँ हटाएँ।.
    • अपलोड और प्लगइन/थीम फ़ोल्डरों में संदिग्ध फ़ाइलें या बैकडोर हटाएँ।.
    • यदि सर्वर-साइड बैकडोर मौजूद हैं, तो ज्ञात-भले बैकअप से पुनर्स्थापित करें।.
  3. पुनर्प्राप्त करें
    • संपर्क प्रबंधक को स्थिर संस्करण (8.6.6 या बाद का) में अपडेट करें।.
    • व्यवस्थापक पासवर्ड, एपीआई कुंजी और अन्य रहस्यों को घुमाएँ।.
    • वातावरण को मजबूत करें (फाइल अखंडता निगरानी, न्यूनतम विशेषाधिकार)।.
  4. घटना के बाद
    • उपयोगकर्ताओं और फ़ाइल परिवर्तनों के लिए पूर्ण मैलवेयर और मैनुअल ऑडिट चलाएँ।.
    • समयरेखा, प्रारंभिक पहुंच वेक्टर, और डेटा निकासी निर्धारित करने के लिए लॉग की समीक्षा करें।.
  5. रोकें
    • प्रशासनिक उपयोगकर्ताओं के लिए MFA लागू करें।.
    • जहां संभव हो, IP या VPN द्वारा प्रशासनिक पहुंच को प्रतिबंधित करें।.
    • नियमित अपडेट और परीक्षण के लिए स्टेजिंग में शेड्यूल करें और रोलबैक योजनाएँ बनाएं।.

दीर्घकालिक मजबूत बनाने और संचालन की सिफारिशें

  • न्यूनतम विशेषाधिकार का सिद्धांत — केवल उन्हीं को प्रशासनिक अधिकार दें जिन्हें इसकी आवश्यकता है।.
  • सभी प्रशासनिक उपयोगकर्ताओं के लिए दो-कारक प्रमाणीकरण।.
  • कर्तव्यों का पृथक्करण — सामग्री संपादकों और प्रशासकों के लिए अलग-अलग खाते का उपयोग करें।.
  • प्लगइन स्वच्छता — अप्रयुक्त प्लगइन्स/थीम्स को हटा दें और सक्रिय आइटम को पैच रखें।.
  • निगरानी और अलर्ट — असामान्य प्रशासनिक गतिविधि या अचानक परिवर्तनों का पता लगाएं।.
  • बैकअप और पुनर्प्राप्ति अभ्यास — नियमित रूप से बैकअप बनाए रखें और उनका परीक्षण करें।.
  • तीसरे पक्ष के घटकों के लिए कोड समीक्षा करें और जिम्मेदार प्रकटीकरण प्रक्रियाओं के साथ सक्रिय रूप से बनाए रखे जाने वाले प्लगइन्स को प्राथमिकता दें।.
  • सुरक्षा परीक्षण — CI में स्वचालित स्कैन को एकीकृत करें और महत्वपूर्ण प्लगइन्स के लिए समय-समय पर मैनुअल ऑडिट का शेड्यूल बनाएं।.

तकनीकी FAQ

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

वर्डप्रेस व्यवस्थापकों के लिए संक्षिप्त तकनीकी चेकलिस्ट (कॉपी/पेस्ट)

  • संपर्क प्रबंधक प्लगइन को 8.6.6 या बाद के संस्करण में अपडेट करें।.
  • व्यवस्थापक पासवर्ड बदलें और मजबूत अद्वितीय पासवर्ड लागू करें।.
  • सभी खातों के लिए MFA सक्षम करें जिनके पास व्यवस्थापक स्तर की पहुंच है।.
  • पूर्ण साइट मैलवेयर और फ़ाइल अखंडता स्कैन चलाएँ।.
  • व्यवस्थापक उपयोगकर्ताओं का ऑडिट करें - अप्रयुक्त या संदिग्ध खातों को हटा दें।.
  • प्लगइन द्वारा उपयोग किए जाने वाले DB फ़ील्ड में “<script”, “onerror=”, “javascript:” के लिए खोजें और किसी भी हिट को साफ करें।.
  • अपडेट के सत्यापन तक प्लगइन एंडपॉइंट्स पर स्क्रिप्ट पेलोड को ब्लॉक करने के लिए अस्थायी HTTP-लेयर नियम लागू करें।.
  • अज्ञात IPs या असामान्य POST अनुरोधों के लिए सर्वर लॉग की समीक्षा करें।.
  • यदि सर्वर-साइड समझौते के संकेत मौजूद हैं तो एक साफ बैकअप से पुनर्स्थापित करें।.

प्लगइन लेखकों के लिए: सुधारने और मजबूत करने के लिए त्वरित चेकलिस्ट

  • व्यवस्थापक POSTs के लिए क्षमताओं (current_user_can) और नॉनसेस को मान्य करें।.
  • सरल शीर्षकों के लिए sanitize_text_field() के साथ इनपुट को साफ करें; सीमित HTML के लिए wp_kses() का उपयोग करें।.
  • आउटपुट पर सही ढंग से एस्केप करें (esc_html(), esc_attr(), wp_kses_post())।.
  • REST एंडपॉइंट्स के लिए permission_callback जोड़ें।.
  • संवेदनशील परिवर्तनों और नए व्यवस्थापक निर्माण घटनाओं के लिए लॉगिंग जोड़ें।.
  • सभी रेंडर पथों के लिए एस्केपिंग/कोडिंग की पुष्टि करने वाले यूनिट और इंटीग्रेशन परीक्षण लिखें।.

समापन विचार

हांगकांग के तेज़ी से बदलते परिचालन वातावरण में, प्रशासनिक खाते अक्सर टीमों और सेवाओं के बीच साझा किए जाते हैं। इससे प्रशासनिक दृष्टिकोण से संग्रहीत XSS हमलावरों के लिए एक उच्च मूल्य का लक्ष्य बन जाता है। व्यावहारिक रक्षा में त्वरित विक्रेता पैचिंग, क्रेडेंशियल स्वच्छता (पासवर्ड बदलें, MFA लागू करें), Thorough स्कैनिंग और सफाई, और जब आप सुधार लागू करते हैं तो अस्थायी HTTP-स्तरीय सुरक्षा शामिल होती है। पैचिंग को प्राथमिकता दें और यदि आप समझौते के संकेत देखते हैं तो घटना प्लेबुक का पालन करें।.

सतर्क रहें: प्रशासन द्वारा नियंत्रित क्षेत्रों में संग्रहीत XSS को तत्कालता के साथ देखें - पैच करें, स्कैन करें, और अपनी साइट को मजबूत करें।.

0 शेयर:
आपको यह भी पसंद आ सकता है

हांगकांग सुरक्षा सलाहकार वर्डप्रेस सोलेडैड स्टोर XSS (CVE20258143)

वर्डप्रेस सोलेडैड प्लगइन <= 8.6.7 - 'pcsml_smartlists_h' कमजोरी के माध्यम से प्रमाणित (योगदानकर्ता+) स्टोर क्रॉस-साइट स्क्रिप्टिंग