Security Advisory XSS in Kudos Donations(CVE202411685)

वर्डप्रेस कूडोस डोनेशन्स प्लगइन में क्रॉस साइट स्क्रिप्टिंग (XSS)






CVE-2024-11685: Reflected XSS in Kudos Donations Plugin (<= 3.2.9) — What WordPress Site Owners and Developers Must Do Now


CVE-2024-11685: Kudos Donations Plugin (≤ 3.2.9) में प्रतिबिंबित XSS — वर्डप्रेस साइट के मालिकों और डेवलपर्स को अब क्या करना चाहिए

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

प्लगइन का नाम कूडोस दान
कमजोरियों का प्रकार क्रॉस-साइट स्क्रिप्टिंग (XSS)
CVE संख्या CVE-2024-11685
तात्कालिकता मध्यम
CVE प्रकाशन तिथि 2026-02-03
स्रोत URL CVE-2024-11685

सारांश: एक प्रतिबिंबित क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता (CVE-2024-11685) जो Kudos Donations वर्डप्रेस प्लगइन (संस्करण ≤ 3.2.9) को प्रभावित करती है, untrusted input को add_query_arg() के माध्यम से आउटपुट में पर्याप्त escaping के बिना प्रतिबिंबित करने की अनुमति देती है। इस मुद्दे को संस्करण 3.3.0 में ठीक किया गया था। यह सलाह तकनीकी विवरण, वास्तविक दुनिया का जोखिम, पहचान तकनीक, व्यावहारिक शमन (जिसमें WAF के साथ आभासी पैचिंग शामिल है), सुरक्षित कोडिंग सुधार, और एक घटना प्रतिक्रिया चेकलिस्ट को समझाती है - जिसे हांगकांग के सुरक्षा प्रैक्टिशनरों के दृष्टिकोण से लिखा गया है।.

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

  • क्या हुआ (संक्षेप में)
  • तकनीकी मूल कारण: add_query_arg और escaping की कमी
  • शोषण परिदृश्य और वास्तविक जोखिम
  • CVSS, OWASP मैपिंग, और प्राथमिकता
  • कैसे पता करें कि आपकी साइट कमजोर है या लक्षित की गई है
  • तात्कालिक सुधार (अपडेट, निष्क्रिय करें, अलग करें)
  • आभासी पैचिंग: WAF नियम जिन्हें आप अभी लागू कर सकते हैं
  • सुरक्षित कोडिंग सुधार — उदाहरण और सर्वोत्तम प्रथाएँ
  • घटना प्रतिक्रिया: यदि आप समझौता किए गए हैं तो क्या करें
  • दीर्घकालिक सख्ती: प्लगइन लेखकों और साइट के मालिकों के लिए प्रक्रियाएँ और नियंत्रण
  • अंतिम नोट्स और अनुशंसित अगले कदम

क्या हुआ (संक्षेप में)

एक प्रतिबिंबित क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता Kudos Donations प्लगइन में पहचानी गई थी जो वर्डप्रेस के संस्करण 3.2.9 तक और उसमें शामिल संस्करणों को प्रभावित करती है (CVE-2024-11685)। यह भेद्यता तब होती है जब उपयोगकर्ता-नियंत्रित डेटा जो क्वेरी पैरामीटर के माध्यम से पास किया जाता है, एक URL या add_query_arg() के माध्यम से आउटपुट बनाने के लिए उपयोग किया जाता है और फिर उचित escaping या आउटपुट एन्कोडिंग के बिना एक पृष्ठ में इंजेक्ट किया जाता है।.

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

तकनीकी मूल कारण: add_query_arg और escaping की कमी

मूल कारण को समझना साइट ऑपरेटरों और डेवलपर्स दोनों के लिए महत्वपूर्ण है।.

  • add_query_arg(): यह वर्डप्रेस सहायक क्वेरी स्ट्रिंग/URLs बनाता या संशोधित करता है। यह पैरामीटर स्वीकार करता है और उन पैरामीटर के साथ एक URL लौटाता है जो जोड़े या अपडेट किए गए हैं। यह स्वाभाविक रूप से असुरक्षित नहीं है - सुरक्षा इस पर निर्भर करती है कि लौटाया गया URL या पैरामीटर ब्राउज़र में कैसे आउटपुट किए जाते हैं।.
  • गलती: कच्चे इनपुट (उदाहरण के लिए, $_GET से) को add_query_arg() में डालना और फिर परिणाम को सीधे HTML में बिना escaping के इको करना। यदि एक हमलावर क्वेरी स्ट्रिंग में संग्रहीत मानों को नियंत्रित कर सकता है और वे मान HTML प्रतिक्रिया में प्रतिबिंबित होते हैं, तो वे एक URL तैयार कर सकते हैं जिसमें JavaScript या HTML के टुकड़े होते हैं जो पीड़ित के ब्राउज़र में निष्पादित होते हैं।.
  • escaping क्यों महत्वपूर्ण है: add_query_arg() अपनी वापसी मूल्य को HTML‑escape नहीं करता है। सही पैटर्न इनपुट को साफ करना (सर्वर साइड) और हमेशा आउटपुट (HTML संदर्भ) को संदर्भ के अनुसार WordPress escaping functions (esc_html, esc_attr, esc_url) का उपयोग करके escape करना है।.

सरल कमजोर पैटर्न:

// संवेदनशील: एक URL को दर्शाता है जो एक अस्वच्छ क्वेरी मान के साथ बनाया गया है'<a href="/hi/' . $url . '/">इसे साझा करें</a>';

सुरक्षित पैटर्न:

// सुरक्षित: इनपुट को साफ करें, URL बनाएं, और आउटपुट को एस्केप करें'<a href="/hi/' . esc_url( $url ) . '/">इसे साझा करें</a>';

मुख्य निष्कर्ष: हमेशा add_query_arg() की वापसी मूल्यों को ऐसे डेटा के रूप में मानें जिन्हें आउटपुट संदर्भ के लिए escape किया जाना चाहिए, और संभवतः पहले बिंदु पर इनपुट को साफ/मान्य करें।.

शोषण परिदृश्य और वास्तविक जोखिम

परावर्तित XSS पेलोड सर्वर पर संग्रहीत नहीं होते हैं - वे आने वाले अनुरोध के आधार पर उत्पन्न प्रतिक्रिया में परावर्तित होते हैं। इससे हमलों को निष्पादित करना अपेक्षाकृत सरल हो जाता है लेकिन आमतौर पर सामाजिक इंजीनियरिंग पर निर्भर करता है।.

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

CVSS, OWASP मैपिंग, और प्राथमिकता

  • CVE: CVE-2024-11685
  • CVSS (उदाहरण): 7.1 — AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L (संदर्भ पर निर्भर)
  • OWASP शीर्ष 10 मानचित्रण: A3 (इंजेक्शन/XSS)
  • प्राथमिकता: कमजोर प्लगइन का उपयोग करने वाली साइटों के लिए उच्च जोखिम के रूप में मानें, विशेष रूप से जहां व्यवस्थापक या गैर-तकनीकी कर्मचारी तैयार लिंक पर क्लिक करने के लिए धोखा खा सकते हैं। वातावरण और उपयोगकर्ता भूमिकाएँ वास्तविक दुनिया की गंभीरता को निर्धारित करती हैं।.

कैसे पता करें कि आपकी साइट कमजोर है या लक्षित की गई है

  1. सूची: सभी साइटों पर प्लगइन संस्करणों की जांच करें।.
    wp प्लगइन सूची --फॉर्मेट=json | jq '.[] | select(.name=="kudos-donations")'

    यदि संस्करण ≤ 3.2.9 है, तो अपडेट होने तक साइट को असुरक्षित मानें।.

  2. वेब सर्वर और एप्लिकेशन लॉग: Search access logs for request URLs containing suspiciously encoded sequences like <script>, onerror=, javascript:, svg/onload, or percent‑encoded variants (%3Cscript%3E). Look for repeated, unusual query strings accessing plugin endpoints.
  3. वर्डप्रेस डेटाबेस जांच: wp_posts और wp_options में डाले गए स्क्रिप्ट या अप्रत्याशित टैग के लिए खोजें।.
    SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
  4. फ़ाइल अखंडता: प्लगइन फ़ाइलों की तुलना प्लगइन की एक साफ प्रति से करें। wp-content/uploads या प्लगइन निर्देशिकाओं के तहत अप्रत्याशित संशोधनों या जोड़े गए फ़ाइलों की तलाश करें। चेकसम या फ़ाइल तुलना उपकरणों का उपयोग करें।.
  5. ब्राउज़र-साइड संकेतक: उपयोगकर्ता लिंक पर क्लिक करने के बाद रीडायरेक्ट, अप्रत्याशित पॉपअप, या अजीब फ़ॉर्म व्यवहार की रिपोर्ट कर रहे हैं। अस्पष्टीकृत लॉगिन प्रयासों या नए व्यवस्थापक उपयोगकर्ताओं की निगरानी करें।.
  6. स्वचालित स्कैनिंग: इस प्लगइन की असुरक्षा के लिए ज्ञात हस्ताक्षरों के लिए अपने सुरक्षा स्कैनर या प्लगइन स्कैनर चलाएँ। प्लगइन संपत्तियों को लक्षित करने वाले संदिग्ध क्वेरी स्ट्रिंग्स की तलाश करें।.

यदि आप संदिग्ध गतिविधि का पता लगाते हैं, तो इस सलाह में बाद में दिए गए घटना प्रतिक्रिया चरणों का पालन करें।.

तात्कालिक सुधार (अभी क्या करना है)

इन कार्यों को प्राथमिकता दें:

  1. तुरंत प्लगइन को अपडेट करें — प्लगइन लेखक ने संस्करण 3.3.0 प्रकाशित किया है जो इस समस्या को संबोधित करता है। अपडेट करना मानक समाधान है।.
  2. यदि आप तुरंत अपडेट नहीं कर सकते:
    • डैशबोर्ड से या WP-CLI के माध्यम से प्लगइन को अस्थायी रूप से निष्क्रिय करें:
      wp प्लगइन निष्क्रिय करें kudos-donations
    • या अपडेट की योजना बनाते समय साइट को रखरखाव मोड में रखें।.
  3. आपके WAF के माध्यम से वर्चुअल पैचिंग — क्वेरी स्ट्रिंग्स में दुर्भावनापूर्ण पेलोड को अवरुद्ध करने वाले नियम लागू करें और प्लगइन एंडपॉइंट्स की सुरक्षा करें। उदाहरण नियमों के लिए नीचे वर्चुअल पैचिंग अनुभाग देखें।.
  4. प्लगइन प्रशासनिक एंडपॉइंट्स तक पहुँच को प्रतिबंधित करें — जहां संभव हो, /wp-admin/ और प्लगइन पथों को IP द्वारा प्रतिबंधित करें; यदि निष्क्रिय करना संभव नहीं है तो प्लगइन फ़ाइलों के लिए अनुरोधों को अवरुद्ध करने के लिए .htaccess/Nginx नियमों का उपयोग करें।.
  5. शोषण के संकेतों की निगरानी करें — लॉगिंग बढ़ाएँ, व्यवस्थापक पासवर्ड बदलें, और यदि समझौता संदिग्ध है तो सत्रों को अमान्य करें।.
  6. कोड समीक्षा की योजना बनाएं — उन एकीकरणों की समीक्षा करें जो उपयोगकर्ता इनपुट को add_query_arg या अन्य आउटपुट संदर्भों में पास करते हैं।.

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

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

  1. क्वेरी स्ट्रिंग में स्पष्ट टोकन को अवरुद्ध करें
    if (query_string matches /(%3C|<)\s*script/i) {
        block_request(403, "XSS payload detected in query string");
    }
  2. क्वेरी स्ट्रिंग में सामान्य इनलाइन JS पैटर्न को अवरुद्ध करें
    यदि (query_string /(javascript:|onerror=|onload=|<svg|eval\(|document\.cookie|window\.location)/i से मेल खाता है) {
  3. ज्ञात पैरामीटर के लिए अपेक्षित वर्णों की श्वेतसूची बनाएं

    यदि कोई पैरामीटर जैसे “संदेश” केवल सरल पाठ शामिल करना चाहिए, तो एक सख्त पैटर्न लागू करें:

    यदि पैरामीटर "संदेश" मौजूद है और /^[\w \-.,]{0,200}$/ से मेल नहीं खाता है तो block_request();
  4. पथ-आधारित वर्चुअल पैच
    यदि request_path /wp-content/plugins/kudos-donations/i से मेल खाता है और query_string में suspicious_payload है तो block;
  5. एन्कोडिंग बचाव का पता लगाएं
    if query_string contains /%25(3C|3c)/ then block();
  6. ह्यूरिस्टिक स्कोरिंग

    संदिग्ध टोकनों को स्कोर असाइन करें; यदि कुल स्कोर एक थ्रेशोल्ड को पार करता है, तो अनुरोध को अवरुद्ध करें या चुनौती दें (CAPTCHA)।.

  7. अलर्टिंग और लॉगिंग

    फोरेंसिक विश्लेषण के लिए पूर्ण अनुरोध पेलोड के साथ अवरुद्ध अनुरोधों पर लॉग और अलर्ट करें।.

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

सुरक्षित कोडिंग सुधार — उदाहरण और सर्वोत्तम प्रथाएँ

प्लगइन्स या थीम को बनाए रखने वाले डेवलपर्स को परावर्तित XSS जोखिमों को समाप्त करने के लिए इन ठोस सुधारों और सिद्धांतों को लागू करना चाहिए।.

  1. जल्दी साफ करें, देर से बचाएं
    • अपने एप्लिकेशन में प्रवेश करते समय इनपुट को साफ करें (sanitize_text_field, absint, sanitize_email, आदि)।.
    • संदर्भ के अनुसार आउटपुट को एस्केप करें:
      • HTML बॉडी टेक्स्ट: esc_html()
      • विशेषता मान: esc_attr()
      • यूआरएल: esc_url()
      • जावास्क्रिप्ट डेटा संरचनाएँ: wp_json_encode() के साथ esc_js()
  2. URL बनाते समय उचित फ़ंक्शन का उपयोग करें
    $val = isset($_GET['val']) ? sanitize_text_field( wp_unslash( $_GET['val'] ) ) : '';'<a href="/hi/' . esc_url( $url ) . '/">लिंक</a>';
  3. कच्चे $_GET/$_REQUEST सामग्री को इको करने से बचें
    // बुरा;
  4. प्रशासनिक क्रियाओं पर नॉन्स और क्षमता जांच का उपयोग करें

    प्रमाणित उपयोगकर्ताओं के लिए GET या POST के माध्यम से क्रियाओं के लिए एक नॉन्स की पुष्टि करें और current_user_can() की जांच करें।.

  5. सामग्री सुरक्षा नीति (CSP)

    इंजेक्टेड स्क्रिप्ट के प्रभाव को कम करने के लिए CSP हेडर का उपयोग करें। उदाहरण:

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

    CSP शोषण की संभावना को कम करता है लेकिन यह एक चांदी की गोली नहीं है।.

  6. उदाहरण: कमजोर कोड को ठीक करना

    कमजोर:

    // अविश्वसनीय इनपुट के साथ कच्चा URL दर्शाना'<a href="/hi/' . $link . '/">नोट पढ़ें</a>';

    ठीक किया गया:

    $note = isset($_GET['note']) ? sanitize_text_field( wp_unslash( $_GET['note'] ) ) : '';'<a href="/hi/' . esc_url( $link ) . '/">नोट पढ़ें</a>';

घटना प्रतिक्रिया: यदि आप समझौता किए गए हैं तो क्या करें

यदि आपके पास शोषण का सबूत है, तो व्यवस्थित रूप से कार्य करें।.

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

प्लगइन लेखकों और साइट मालिकों के लिए दीर्घकालिक कठिनाई

रोकथाम समय और प्रतिष्ठा की लागत बचाती है। अनुशंसित दीर्घकालिक उपाय:

  • प्लगइन लेखकों के लिए: “इनपुट को साफ करें, आउटपुट को एस्केप करें” का पालन करें, CI में स्वचालित सुरक्षा परीक्षण का उपयोग करें (स्थैतिक विश्लेषण और गतिशील परीक्षण), कच्चे मानों को प्रिंट करने वाले आउटपुट संदर्भों को कम करें, और स्पष्ट चेंज लॉग और सुरक्षा रिलीज नोट्स प्रदान करें।.
  • साइट के मालिकों के लिए: वर्डप्रेस कोर, थीम और प्लगइन्स को अद्यतित रखें; शून्य-दिन कवरेज के लिए वर्चुअल पैचिंग का समर्थन करने वाला WAF का उपयोग करें; मजबूत प्रशासनिक प्रथाओं को लागू करें (2FA, न्यूनतम विशेषाधिकार, सत्र प्रबंधन); नियमित रूप से बैकअप लें और पुनर्स्थापनों का परीक्षण करें; समय-समय पर सुरक्षा स्कैन और पैच प्रबंधन करें।.
  1. सभी साइटों की जांच करें और Kudos Donations प्लगइन को तुरंत संस्करण 3.3.0 (या बाद में) में अपडेट करें।.
  2. यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो साइट को रखरखाव मोड में डालें और उन WAF नियमों को लागू करें जो प्लगइन को लक्षित करने वाले दुर्भावनापूर्ण क्वेरी स्ट्रिंग पेलोड को ब्लॉक करते हैं।.
  3. यहाँ वर्णित कोड पैटर्न की समीक्षा करें और सुनिश्चित करें कि सभी add_query_arg() उपयोग उचित रूप से साफ और एस्केप किए गए हैं।.
  4. यदि आप समझौते का संदेह करते हैं, तो ऊपर दिए गए घटना प्रतिक्रिया चेकलिस्ट का पालन करें या जांच के लिए एक सुरक्षा पेशेवर को शामिल करें।.

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

यदि आपको WAF नियमों, पहचान जांचों, या कई साइटों के लिए घटना प्रतिक्रिया योजना को लागू करने में हाथों-हाथ मदद की आवश्यकता है, तो वर्डप्रेस अनुभव वाले एक योग्य सुरक्षा सलाहकार को शामिल करें।.

सतर्क रहें और तेजी से कार्य करें — हांगकांग सुरक्षा समुदाय में हमारे अनुभव में, हर घंटे की देरी हमलावरों के लिए अवसर की खिड़की को बढ़ा देती है।.

— हांगकांग सुरक्षा विशेषज्ञ


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

वर्डप्रेस B स्लाइडर सब्सक्राइबर डेटा को उजागर करता है (CVE20258676)

प्लगइन नाम B स्लाइडर भेद्यता का प्रकार प्रमाणित डेटा एक्सपोजर CVE संख्या CVE-2025-8676 तात्कालिकता कम CVE प्रकाशन तिथि…