एचके एनजीओ चेतावनी देता है वर्डप्रेस CSRF ऑब्जेक्ट इंजेक्शन (CVE202549895)

PluginBuddy.com प्लगइन द्वारा WordPress ServerBuddy
प्लगइन का नाम PluginBuddy.com द्वारा ServerBuddy
कमजोरियों का प्रकार क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) और PHP ऑब्जेक्ट इंजेक्शन
CVE संख्या CVE-2025-49895
तात्कालिकता कम
CVE प्रकाशन तिथि 2025-08-16
स्रोत URL CVE-2025-49895

चेतावनी: ServerBuddy (<= 1.0.5) — CSRF को PHP ऑब्जेक्ट इंजेक्शन (CVE-2025-49895) से जोड़ा गया — WordPress मालिकों को अब क्या करना चाहिए

दिनांक: 2025-08-16 | लेखक: हांगकांग सुरक्षा विशेषज्ञ | टैग: WordPress, सुरक्षा, CSRF, PHP ऑब्जेक्ट इंजेक्शन

TL;DR

ServerBuddy (संस्करण ≤ 1.0.5) को प्रभावित करने वाली एक भेद्यता को सार्वजनिक रूप से CVE-2025-49895 के रूप में ट्रैक किया गया है। यह दोष एक प्रमाणित क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) या एक अनुरोध योग्य एंडपॉइंट को PHP ऑब्जेक्ट इंजेक्शन से जोड़ सकता है, जो अनुचित तरीके से अनुक्रमित डेटा को संभालने के कारण होता है। कुछ सार्वजनिक मेटाडेटा पैच प्राथमिकता को “कम” के रूप में लेबल करने के बावजूद, तकनीकी श्रृंखला (CSRF → PHP ऑब्जेक्ट इंजेक्शन) गंभीर परिणामों को सक्षम कर सकती है — जिसमें मनमाना कोड निष्पादन, साइट का समझौता, या डेटा चोरी शामिल है — जो सर्वर कॉन्फ़िगरेशन और उपलब्ध गैजेट श्रृंखलाओं पर निर्भर करता है।.

तात्कालिक प्राथमिकता: अपने साइटों पर ServerBuddy की जांच करें (संस्करण ≤ 1.0.5), यदि मौजूद हो तो इसके एंडपॉइंट्स को अक्षम या ब्लॉक करें, प्रशासनिक सत्रों को मजबूत करें, और समझौते के संकेतों के लिए स्कैन करें। यह सलाह तकनीकी विवरण, जोखिम परिदृश्य, पहचान मार्गदर्शन, संकुचन कदम, वर्चुअल-पैच/WAF रणनीतियाँ, और एक घटना प्रतिक्रिया चेकलिस्ट को स्पष्ट करती है।.

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

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

CVE: CVE-2025-49895
रिपोर्ट किया गया: 13 अगस्त 2025 — प्रकाशित: 16 अगस्त 2025

यह क्यों खतरनाक है — त्वरित परिचय

यहां दो भेद्यता वर्ग मिलते हैं:

  • CSRF (क्रॉस-साइट अनुरोध धोखाधड़ी): एक हमलावर एक लॉगिन किए हुए उपयोगकर्ता को विशेषाधिकार प्राप्त अनुरोध करने के लिए धोखा दे सकता है।.
  • PHP ऑब्जेक्ट इंजेक्शन (POI): जब अविश्वसनीय इनपुट unserialize() (या समकक्ष) तक पहुंचता है, तो एक हमलावर ऐसे अनुक्रमित ऑब्जेक्ट बना सकता है जो कक्षाओं को स्थापित करते हैं और जादुई विधियों को सक्रिय करते हैं, जिससे फ़ाइल लेखन, कमांड निष्पादन, या डेटा निकासी हो सकती है यदि गैजेट श्रृंखलाएँ मौजूद हैं।.

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

तकनीकी मार्गदर्शिका — एक CSRF → PHP ऑब्जेक्ट इंजेक्शन श्रृंखला सामान्यतः कैसे काम करती है

हम एक एक्सप्लॉइट प्रकाशित नहीं करेंगे, लेकिन प्रशासकों और रक्षकों को निवारण लागू करने के लिए तंत्र को समझना आवश्यक है:

  1. ट्रिगर बिंदु: प्लगइन एक एंडपॉइंट (एडमिन-एजेक्स क्रिया, एडमिन पृष्ठ, या REST मार्ग) को उजागर करता है जो POST डेटा स्वीकार करता है और उस इनपुट के एक भाग को unserialize() या समकक्ष असुरक्षित डीसिरियलाइजेशन में पास करता है।.
  2. CSRF वेक्टर: एंडपॉइंट में एंटी-CSRF जांच की कमी है (कोई नॉनस नहीं, या संदर्भ/उत्पत्ति सत्यापन गायब है), इसलिए एक तैयार किया गया फॉर्म या स्क्रिप्ट एक दुर्भावनापूर्ण साइट पर एक प्रशासक के ब्राउज़र को प्रमाणित करते समय पेलोड सबमिट करने का कारण बन सकता है।.
  3. दुर्भावनापूर्ण पेलोड: POST बॉडी में सीरियलाइज्ड PHP डेटा होता है (जैसे, O:##:”ClassName”:…), जिसे unserialize() इंस्टेंटिएट कर सकता है।.
  4. गैजेट श्रृंखला: मौजूदा कक्षाएं जिनमें जादुई तरीके (__wakeup, __destruct, __toString, आदि) होते हैं, साइड इफेक्ट्स (फाइल लेखन, कमांड निष्पादन, आदि) उत्पन्न करने के लिए दुरुपयोग की जा सकती हैं।.
  5. परिणाम: प्रभाव प्रशासक खाता संशोधन से लेकर स्थायी बैकडोर और पूर्ण साइट अधिग्रहण तक भिन्न होते हैं, जो गैजेट्स और सर्वर कॉन्फ़िगरेशन पर निर्भर करते हैं।.

जोखिम भरा पैटर्न (केवल चित्रण के लिए):

<?php

यदि एक हमलावर एक साइट प्रशासक के ब्राउज़र को उस पेलोड को POST करने के लिए मजबूर कर सकता है, तो वे प्रशासक के विशेषाधिकारों के तहत खतरनाक कोड पथों को निष्पादित कर सकते हैं।.

जोखिम मूल्यांकन - यह कितना गंभीर है?

सार्वजनिक मेटाडेटा उच्च तकनीकी संभावनाओं को सूचीबद्ध करता है (जैसे, CVSS-जैसे 8.8)। वास्तविक दुनिया का प्रभाव इस पर निर्भर करता है:

  • क्या एंडपॉइंट प्रमाणीकरण की आवश्यकता है और यह किस विशेषाधिकार स्तर की आवश्यकता है।.
  • सक्रिय प्लगइन्स/थीम्स में शोषण योग्य गैजेट श्रृंखलाओं की उपस्थिति।.
  • सर्वर कॉन्फ़िगरेशन (खतरनाक PHP कार्यों की उपलब्धता, फ़ाइल अनुमतियाँ)।.
  • प्रशासक सत्र स्वच्छता (स्थायी लॉगिन, साझा प्रशासक सत्र)।.

CSRF आवश्यकता के साथ भी, हमलावर अक्सर सामाजिक इंजीनियरिंग या वॉटरिंग-होल तकनीकों के माध्यम से सफल होते हैं। इसे उच्च प्राथमिकता के रूप में मानें।.

वर्डप्रेस साइट मालिकों के लिए तात्कालिक कार्रवाई (चरण-दर-चरण)

  1. सूची

    • जांचें कि ServerBuddy स्थापित है या नहीं: WP प्रशासन → प्लगइन्स, या WP-CLI के माध्यम से:
      wp प्लगइन सूची | grep सर्वरबडी
    • यदि स्थापित है, तो संस्करण रिकॉर्ड करें — यदि ≤ 1.0.5 है, तो इसे संवेदनशील मानें।.
  2. रोकथाम (सबसे तेज प्रभावी सुरक्षा उपाय)

    • तुरंत प्लगइन को निष्क्रिय करें:
      • वर्डप्रेस प्रशासन के माध्यम से: प्लगइन को निष्क्रिय करें
      • या WP-CLI:
        wp प्लगइन निष्क्रिय करें सर्वरबडी-बाय-प्लगइनबडी
    • यदि हटाना संभव है और आपके पास एक ज्ञात-स्वच्छ बैकअप है, तो प्लगइन को पूरी तरह से हटा दें।.
  3. संवेदनशील एंडपॉइंट्स तक पहुंच को अवरुद्ध करें

    • जब आप प्लगइन को ऑफलाइन नहीं ले जा सकते, तो वेब सर्वर स्तर पर प्लगइन PHP फ़ाइलों या प्रशासनिक मार्गों तक पहुंच को अवरुद्ध करें (.htaccess, nginx), या प्लगइन पथों को लक्षित करने वाले संदिग्ध POSTs को अवरुद्ध करें। उदाहरण (Apache .htaccess):
      <Files "serverbuddy-admin.php">
        Require all denied
      </Files>
      
    • वैकल्पिक रूप से, अपने फ़ायरवॉल/WAF को POST बॉडी में अनुक्रमित ऑब्जेक्ट पैटर्न वाले अनुरोधों को अवरुद्ध करने के लिए कॉन्फ़िगर करें (नीचे WAF अनुभाग देखें)।.
  4. सत्र और क्रेडेंशियल स्वच्छता

    • सभी व्यवस्थापक पासवर्ड और API कुंजियों को बदलें।.
    • सभी उपयोगकर्ताओं को लॉगआउट करने के लिए मजबूर करके सत्रों को अमान्य करें।.
    • यदि उपयोग किया गया हो तो SSO/OAuth क्लाइंट रहस्यों को बदलें।.
  5. समझौते के लिए स्कैन करें और जांचें

    • पूर्ण मैलवेयर और फ़ाइल-इंटीग्रिटी स्कैन चलाएं।.
    • हाल ही में संशोधित फ़ाइलों का निरीक्षण करें (वेब रूट, अपलोड, wp-content, mu-plugins):
      find /path/to/site -type f -mtime -7 -print
    • प्लगइन एंडपॉइंट्स पर संदिग्ध POSTs, असामान्य उपयोगकर्ता एजेंट, या “O:” या अनुक्रमित संरचनाओं वाले POST शरीरों के लिए वेब सर्वर और PHP लॉग की जांच करें।.
  6. बैकअप और पुनर्स्थापना योजना

    • अभी एक ताजा बैकअप लें (डेटाबेस + फ़ाइलें)।.
    • यदि समझौता पाया जाता है, तो उल्लंघन से पहले लिए गए एक स्वच्छ बैकअप से पुनर्स्थापना पर विचार करें।.
  7. निगरानी करें

    • उन्नत लॉगिंग सक्षम करें (फ़ाइल परिवर्तन पहचान, लॉगिन अलर्ट)।.
    • संदिग्ध क्रॉन कार्यों, नए व्यवस्थापक उपयोगकर्ताओं, या अज्ञात अनुसूचित कार्यों पर नज़र रखें।.

पहचानने के सुझाव - क्या देखना है

  • HTTP एक्सेस लॉग: संदिग्ध गतिविधि से ठीक पहले प्लगइन मार्गों पर POST अनुरोध।.
  • अनुरोध शरीर: अनुक्रमित PHP ऑब्जेक्ट नोटेशन, जैसे, O:8:"ClassName":... या व्यवस्थापक एंडपॉइंट्स पर भेजे गए लंबे POST पैरामीटर/base64 ब्लॉब।.
  • PHP त्रुटि लॉग: unserialize() विफलताओं से चेतावनियाँ या त्रुटियाँ।.
  • अप्रत्याशित व्यवस्थापक क्रियाएँ: नए व्यवस्थापक उपयोगकर्ता, थीम/प्लगइन फ़ाइलों में परिवर्तन, अज्ञात अनुसूचित घटनाएँ।.
  • फ़ाइल प्रणाली में परिवर्तन: लिखने योग्य स्थानों (अपलोड, wp-content) में नए PHP फ़ाइलें।.
  • आउटबाउंड कनेक्शन: वेब सर्वर से असामान्य नेटवर्क गतिविधि।.

सुझाए गए grep कमांड:

# लॉग में अनुक्रमित वस्तु सिंटैक्स के लिए खोजें

एक वेब एप्लिकेशन फ़ायरवॉल (WAF) कैसे मदद करता है — वर्चुअल पैचिंग रणनीति

यदि कोई आधिकारिक सुधार अभी उपलब्ध नहीं है, तो किनारे पर वर्चुअल पैचिंग (WAF) कमजोर कोड तक पहुँचने से पहले दुर्भावनापूर्ण पेलोड को ब्लॉक करके तत्काल शोषण जोखिम को कम कर सकता है। मुख्य रणनीतियाँ:

  1. अनुक्रमित वस्तु पेलोड को ब्लॉक करें उन एंडपॉइंट्स में जो उन्हें प्राप्त नहीं करना चाहिए — ऐसे POST बॉडीज़ की तलाश करें जिनमें पैटर्न हो O:\d+: या संदिग्ध s:\d+: अनुक्रमों को शामिल करते हैं।.
  2. CSRF अपेक्षाओं को लागू करें — एक मान्य WP नॉनस की आवश्यकता करें या प्रशासन POSTs के लिए संदर्भ/उत्पत्ति की जांच करें; अपेक्षित नॉनस गायब होने पर अनुरोधों को ब्लॉक करें।.
  3. गैजेट-क्लास नामों के लिए ह्यूरिस्टिक्स — यदि पेलोड में ज्ञात जोखिम भरे क्लास नाम शामिल हैं और अनुरोध संदर्भ असामान्य प्रतीत होता है, तो ब्लॉक करें।.
  4. दर-सीमा और थ्रॉटल प्रशासनिक एंडपॉइंट्स पर POSTs और बार-बार संदिग्ध गतिविधि को ब्लॉक करें।.

वैचारिक हस्ताक्षर उदाहरण:

  • उन प्रशासनिक एंडपॉइंट्स पर POSTs को ब्लॉक करें जहाँ POST बॉडी अनुक्रमित वस्तु नोटेशन के लिए regex से मेल खाती है:
    O:\d+:"[A-Za-z0-9_\\\]+":\d+: {
  • उन अनुरोधों को ब्लॉक करें जो अनुक्रमित पेलोड्स को शामिल करते हैं और मान्य WP नॉनस पैरामीटर/हेडर की कमी होती है।.

उदाहरण ModSecurity-शैली नियम (वैचारिक — अपने वातावरण के लिए अनुकूलित और परीक्षण करें):

SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,status:403,id:100001,severity:2,msg:'एडमिन एंडपॉइंट पर PHP सीरियलाइज्ड ऑब्जेक्ट पेलोड को ब्लॉक करें'" 

नोट: स्टेजिंग पर नियमों का परीक्षण करें और पहले झूठे सकारात्मक को कम करने के लिए लॉगिंग-केवल मोड पर विचार करें।.

CSRF और असुरक्षित डीसिरियलाइजेशन के खिलाफ अपने वर्डप्रेस साइट को कैसे मजबूत करें

डेवलपर्स के लिए

  1. अविश्वसनीय उपयोगकर्ता इनपुट को कभी भी अनसीरियलाइज न करें। संरचित डेटा के लिए JSON (json_encode/json_decode) को प्राथमिकता दें।.
  2. यदि डीसिरियलाइजेशन आवश्यक है, तो डीसिरियलाइज करने से पहले डेटा पर हस्ताक्षर करें और मान्य करें।.
  3. हमेशा क्षमताओं (current_user_can()) और नॉनसेस (check_admin_referer() या wp_verify_nonce()) की पुष्टि करें प्रशासनिक क्रियाओं के लिए।.
  4. केवल रेफरर पर निर्भर रहने के बजाय SameSite कुकी विशेषताओं और नॉनसेस का उपयोग करें।.
  5. डायनामिक eval() से बचें और कड़े स्वच्छता और पहुंच जांचों के साथ फ़ाइल संचालन की सुरक्षा करें।.

साइट के मालिकों / प्रशासकों के लिए

  • WP कोर, थीम और प्लगइन्स को विश्वसनीय स्रोतों से अपडेट रखें।.
  • प्रशासनिक उपयोगकर्ताओं को सीमित करें और न्यूनतम विशेषाधिकार लागू करें।.
  • मजबूत पासवर्ड का उपयोग करें और प्रशासनिक खातों के लिए दो-कारक प्रमाणीकरण सक्षम करें।.
  • सुरक्षित कुकी विशेषताओं को कॉन्फ़िगर करें, जैसे:
    सेट-कुकी: वर्डप्रेस_logged_in=; सुरक्षित; HttpOnly; SameSite=Lax

घटना प्रतिक्रिया चेकलिस्ट (यदि आप समझौता होने का संदेह करते हैं)

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

व्यावहारिक grep/find उदाहरण — क्रियाशील जांचें

grep -i "O:[0-9]\+:" /var/log/nginx/* /var/log/apache2/*

यदि आप मेल खाते हैं, तो उन्हें संदिग्ध मानें और रोकथाम और जांच के लिए बढ़ाएं।.

दीर्घकालिक सुधार प्लगइन टीमों को लागू करना चाहिए

  • असुरक्षित unserialize() उपयोग को हटा दें।.
  • उपयोग से पहले सभी दूरस्थ इनपुट को मान्य और स्वच्छ करें।.
  • प्रत्येक क्रिया अंत बिंदु पर क्षमता जांच और नॉनसेस की आवश्यकता करें।.
  • स्वचालित परीक्षण जोड़ें जो सुनिश्चित करते हैं कि अंत बिंदु नॉनसेस/अमान्य रेफरर अनुरोधों को अस्वीकार करते हैं।.
  • उन कोड पथों का पुनः ऑडिट करें जो दूरस्थ डेटा (AJAX, REST, फॉर्म) स्वीकार करते हैं।.
  • एक सार्वजनिक भेद्यता प्रकटीकरण कार्यक्रम (VDP) और समय पर पैच नीति बनाए रखें।.

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

प्रश्न: यदि मेरी साइट पर कोई सक्रिय प्रशासक नहीं है, तो क्या मैं अभी भी असुरक्षित हो सकता हूँ?

उत्तर: सामान्य CSRF के लिए एक प्रमाणित सत्र की आवश्यकता होती है। हालाँकि, प्रकटीकरण ने यह नोट किया कि कुछ परिदृश्यों में बिना प्रमाणीकरण के पहुंच संभव थी। यदि अंत बिंदु बिना प्रमाणीकरण के पहुंच योग्य है, तो आपका जोखिम काफी अधिक है।.

प्रश्न: मैंने प्लगइन को निष्क्रिय कर दिया — क्या मुझे अभी भी स्कैन करने की आवश्यकता है?

उत्तर: हाँ। यदि निष्क्रिय करने से पहले शोषण हुआ, तो पहले से ही एक बैकडोर या स्थिरता हो सकती है। एक गहन स्कैन और फोरेंसिक समीक्षा करें।.

प्रश्न: क्या वर्डप्रेस कोर को अपडेट करने से मुझे सुरक्षा मिलेगी?

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

सारांश और व्यावहारिक चेकलिस्ट

  • अपने साइटों पर ServerBuddy ≤ 1.0.5 के लिए जांचें।.
  • यदि मौजूद हो तो प्लगइन को अक्षम या हटा दें।.
  • यदि हटाना तुरंत संभव नहीं है, तो वेब सर्वर पर या किनारे के नियमों के साथ प्लगइन एंडपॉइंट्स को ब्लॉक करें जो:
    • व्यवस्थापक/प्लगइन एंडपॉइंट्स पर अनुक्रमित ऑब्जेक्ट पेलोड्स को ब्लॉक करें।.
    • व्यवस्थापक POSTs पर मान्य नॉनस की आवश्यकता होती है।.
  • व्यवस्थापक पासवर्ड को घुमाएं और सक्रिय सत्रों से लॉगआउट करने के लिए मजबूर करें।.
  • समझौते के लिए स्कैन करें, जांच के लिए लॉग और बैकअप को सुरक्षित रखें।.
  • विक्रेता पैच की निगरानी करें और इसे केवल प्रामाणिकता की पुष्टि के बाद लागू करें।.

लेखक के बारे में

यह सलाह एक हांगकांग स्थित सुरक्षा विशेषज्ञ द्वारा तैयार की गई थी, जिसे वर्डप्रेस घटना प्रतिक्रिया और वेब एप्लिकेशन हार्डनिंग का अनुभव है। यदि आपको पेशेवर सहायता की आवश्यकता है, तो एक प्रतिष्ठित सुरक्षा परामर्श या स्थानीय घटना प्रतिक्रिया टीम को फोरेंसिक समीक्षा और सुधार करने के लिए संलग्न करें।.

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

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

योगदानकर्ता स्टोर किए गए क्रॉस साइट स्क्रिप्टिंग भेद्यता (CVE20259849)

वर्डप्रेस एचटीएमएल सोशल शेयर बटन प्लगइन <= 2.1.16 - प्रमाणित (योगदानकर्ता+) स्टोर किए गए क्रॉस-साइट स्क्रिप्टिंग भेद्यता