WP JobHunt ≤ 7.6 — प्रमाणित प्राधिकरण बाईपास (CVE-2025-7374): वर्डप्रेस साइट मालिकों को अब क्या करना चाहिए

लेखक: हांगकांग सुरक्षा विशेषज्ञ   |   तारीख: 2025-10-09

TL;DR

एक मध्यम-गंभीर प्राधिकरण बाईपास (टूटी हुई प्रमाणीकरण / A7) WP JobHunt के संस्करणों को 7.6 तक और इसमें प्रभावित करता है (CVE-2025-7374)। “उम्मीदवार” भूमिका वाले एक प्रमाणित उपयोगकर्ता उन क्रियाओं को ट्रिगर कर सकता है जो उच्च-प्राधिकारित खातों तक सीमित होनी चाहिए क्योंकि सर्वर-साइड प्राधिकरण जांच अपर्याप्त हैं। एक स्थिर रिलीज़ (7.7) उपलब्ध है — तुरंत अपग्रेड करें। यदि आप तुरंत अपग्रेड नहीं कर सकते हैं, तो अस्थायी शमन पर विचार करें: प्लगइन को अक्षम करें, उम्मीदवार क्षमताओं को मजबूत करें, WAF/वर्चुअल-पैच नियम लागू करें, और संदिग्ध गतिविधियों के लिए ऑडिट करें।.

यह सलाह एक हांगकांग सुरक्षा विशेषज्ञ द्वारा तैयार की गई है। यह तकनीकी विवरण में भेद्यता को स्पष्ट करती है, सुरक्षित पहचान और शमन रणनीतियों (नमूना WAF नियम और वर्डप्रेस हार्डनिंग स्निपेट्स सहित) को दिखाती है, और यदि आप समझौता होने का संदेह करते हैं तो घटना प्रतिक्रिया के कदमों का वर्णन करती है।.

आपको यह क्यों पढ़ना चाहिए

• WP JobHunt एक सामान्य भर्ती प्लगइन है; प्राधिकरण त्रुटियाँ निम्न-प्राधिकारित उपयोगकर्ताओं को प्राधिकारित क्रियाएँ करने की अनुमति देती हैं।.
• दोष प्रमाणीकरण (एक उम्मीदवार खाता) की आवश्यकता है लेकिन जहां सार्वजनिक पंजीकरण की अनुमति है, वहां इसे बड़े पैमाने पर हथियार बनाना तुच्छ है।.
• आपको संक्षिप्त, क्रियाशील मार्गदर्शन प्राप्त होगा: पहचान, तत्काल शमन (वर्चुअल-पैचिंग / WAF), और पुनर्प्राप्ति के कदम।.

क्या हुआ (उच्च स्तर)

WP JobHunt ≤ 7.6 में एक प्राधिकरण बाईपास पाया गया। मूल कारण AJAX और/या REST एंडपॉइंट्स या कस्टम प्लगइन क्रियाओं में अनुपस्थित या गलत क्षमता जांच है। “उम्मीदवार” भूमिका (या समान निम्न-प्राधिकारित भूमिकाएँ) वाले प्रमाणित खाते उन कार्यक्षमताओं तक पहुँच सकते हैं जो नियोक्ताओं या प्रशासकों के लिए निर्धारित हैं। विक्रेता ने 7.7 में उचित प्राधिकरण जांच लागू करके समस्या को ठीक किया।.

क्योंकि शोषण के लिए प्रमाणीकरण की आवश्यकता होती है, जोखिम इस बात पर निर्भर करता है कि आपकी साइट सार्वजनिक पंजीकरण की अनुमति देती है या यदि हमलावर उम्मीदवार क्रेडेंशियल प्राप्त कर सकते हैं। कई नौकरी साइटें आवेदकों के लिए स्व-पंजीकरण की अनुमति देती हैं; यदि आपकी साइट ऐसा करती है, तो इसे तत्काल समझें।.

प्रभाव

• निम्न-प्राधिकारित उपयोगकर्ताओं द्वारा विशेषाधिकार वृद्धि और अनधिकृत क्रियाएँ।.
• लिस्टिंग बनाने/संशोधित करने, आवेदन डेटा को बदलने, उपयोगकर्ता मेटा को बदलने, या ऐसी क्रियाएँ करने की संभावना जो प्रशासक खाता अधिग्रहण की ओर ले जा सकती हैं — इस पर निर्भर करता है कि आपकी साइट कौन से एंडपॉइंट्स को उजागर करती है।.
• यदि शोषण किया गया, तो हमलावर बैकडोर स्थापित कर सकते हैं, प्रशासक खाते बना सकते हैं, या नौकरी की लिस्टिंग को धोखाधड़ी या फ़िशिंग के लिए हेरफेर कर सकते हैं।.
• CVSS: 5.4 (मध्यम)। खुले उम्मीदवार पंजीकरण या खराब निगरानी वाली साइटों के लिए वास्तविक दुनिया का प्रभाव काफी बढ़ जाता है।.

कौन जोखिम में है

• WP JobHunt ≤ 7.6 चलाने वाली साइटें।.
• साइटें जो सार्वजनिक उम्मीदवार पंजीकरण की अनुमति देती हैं।.
• साइटें जहां उम्मीदवार खातों का पुन: उपयोग किया जाता है या पासवर्ड स्वच्छता कमजोर होती है।.
• कस्टम भूमिका मैपिंग या प्लगइन कस्टमाइजेशन के साथ मल्टीसाइट सेटअप।.

यदि आप कई साइटों का प्रबंधन करते हैं, तो सार्वजनिक पंजीकरण और उच्च ट्रैफ़िक वाली साइटों को प्राथमिकता दें।.

तात्कालिक क्रियाएँ (क्रमबद्ध)

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

सुरक्षित पुनरुत्पादन (शोषण कोड के बिना तकनीकी सारांश)

जिम्मेदार प्रकटीकरण रक्षकों को उच्च-स्तरीय पुनरुत्पादन विवरण समझने के लिए प्रोत्साहित करता है। दोष तब प्रकट होता है जब प्लगइन कोड अनुरोधों को संसाधित करता है (admin-ajax.php, कस्टम AJAX रूट, या REST API एंडपॉइंट्स के माध्यम से) और वर्तमान उपयोगकर्ता की क्षमताओं या भूमिका की पुष्टि किए बिना विशेषाधिकार प्राप्त क्रियाएँ निष्पादित करता है।.

सामान्य समस्याग्रस्त पैटर्न:

• एक AJAX क्रिया हैंडलर केवल is_user_logged_in() या उपयोगकर्ता आईडी की जांच करता है, लेकिन current_user_can() या एक कस्टम क्षमता की नहीं।.
• REST एंडपॉइंट्स को एक permission_callback के साथ पंजीकृत किया गया है जो किसी भी प्रमाणित उपयोगकर्ता के लिए सत्य लौटाता है या कोई permission_callback नहीं है।.
• कोड में धारणाएँ कि “उम्मीदवार” बिना सर्वर-साइड प्रवर्तन के कुछ संसाधनों को परिवर्तित नहीं कर सकता।.

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

पहचान: लॉग और डेटाबेस में क्या देखना है

तेज़ ट्रायज जोखिम को कम करता है और शोषण का पता लगाने में मदद करता है।.

ए. वेब सर्वर / एक्सेस लॉग

• उम्मीदवार खातों के रूप में प्रमाणित admin-ajax.php या प्लगइन-विशिष्ट एंडपॉइंट्स पर अचानक या पुनरावृत्त POST अनुरोध।.
• संदिग्ध पैरामीटर संयोजनों (जैसे, फ्रंट-एंड उम्मीदवार पृष्ठों से उत्पन्न job_create, job_update, user_update नामक क्रियाएँ) वाले अनुरोध।.
• कई आईपी जो जल्दी से उम्मीदवार खाते बना रहे हैं और फिर उन एंडपॉइंट्स को कॉल कर रहे हैं।.

बी. वर्डप्रेस गतिविधि और डेटाबेस संकेतक

• खुलासे की तारीख के बाद बनाए गए नए व्यवस्थापक उपयोगकर्ता - wp_users.user_registered की जांच करें।.
• उपयोगकर्ता मेटा में परिवर्तन जहां भूमिका या क्षमताएँ अपडेट की गई थीं (wp_usermeta meta_key = ‘wp_capabilities’)।.
• असामान्य सामग्री या रीडायरेक्ट यूआरएल के साथ नए या संशोधित नौकरी लिस्टिंग।.
• नए या संशोधित फ़ाइलें - फ़ाइल सिस्टम पर फ़ाइल संशोधन समय को स्कैन करें।.

ट्रायज के लिए नमूना SQL क्वेरी:

-- New admin users created recently
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered >= '2025-10-01'
AND ID IN (
  SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
);

-- Check for candidate role escalations
SELECT user_id, meta_key, meta_value, umeta_id
FROM wp_usermeta
WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%candidate%'
AND user_id IN (
  SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%' 
);

सी. वर्डप्रेस डिबग और प्लगइन लॉग

• WP लॉगिंग को अस्थायी रूप से सक्षम करें: wp-config.php में add define(‘WP_DEBUG’, true); define(‘WP_DEBUG_LOG’, true); जोड़ें। लॉग wp-content/debug.log में लिखे जाएंगे।.
• विफल या अप्रत्याशित अनुमति जांच और संदिग्ध प्लगइन गतिविधियों की खोज करें।.

WAF और वर्चुअल पैच: तत्काल सुरक्षा जो आप लागू कर सकते हैं

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

महत्वपूर्ण: उन नियमों को लागू न करें जो आवश्यक उम्मीदवार कार्यप्रवाह को तोड़ते हैं। ब्लॉक करने से पहले 24-48 घंटों के लिए लॉग-केवल मोड की सिफारिश की जाती है।.

ए. विशेषाधिकार बढ़ाने वाले POST अनुरोधों को ब्लॉक करें

उन एंडपॉइंट्स पर admin-ajax.php या REST पर POST को ब्लॉक करें जहां क्रिया पैरामीटर फ्रंट-एंड संदर्भों या निम्न-विशेषाधिकार संदर्भों से उत्पन्न नौकरी प्रबंधन क्रियाओं से मेल खाते हैं।.

उदाहरण ModSecurity-शैली का नियम (छद्म; अपने WAF सिंटैक्स के अनुसार अनुकूलित करें):

# संदिग्ध admin-ajax क्रियाओं को फ्रंट-एंड से उत्पन्न होने से ब्लॉक करें (वर्चुअल पैच)"

बी. REST एंडपॉइंट एक्सेस पैटर्न को ब्लॉक करें

यदि प्लगइन /wp-json/wp-jobhunt/ या समान के तहत REST रूट्स को उजागर करता है, तो पैच होने तक लिखने के संचालन (POST/PUT/DELETE) को प्रतिबंधित करने के लिए नियम जोड़ें या अतिरिक्त सत्यापन की आवश्यकता करें।.

उदाहरण Nginx + Lua अवधारणा (छद्म):

-- यदि अनुरोध /wp-json/wp-jobhunt/ पर है और विधि POST/PUT/DELETE है, तो एक मान्य व्यवस्थापक कुकी की आवश्यकता है

C. खाता निर्माण और संदिग्ध एंडपॉइंट्स पर दर-सीमा

• प्रति IP प्रति घंटे पंजीकरण की सीमा (जैसे, प्रति घंटे 3)।.
• डेटा को संशोधित करने वाले प्लगइन एंडपॉइंट्स पर कॉल को थ्रॉटल करें।.

D. संदिग्ध पैरामीटर पैटर्न को ब्लॉक करें

उन अनुरोधों की निगरानी करें या उन्हें ब्लॉक करें जिनमें केवल व्यवस्थापक के लिए फ़ील्ड जैसे role=administrator, क्षमता स्ट्रिंग, या उपयोगकर्ता मेटा कुंजी शामिल हैं जो फ्रंट-एंड संदर्भों से प्रस्तुत की जा रही हैं।.

E. केवल व्यवस्थापक-के लिए APIs के लिए IP अनुमति सूचियाँ

यदि व्यवस्थापक सुविधाएँ केवल निजी IPs से उपयोग की जाती हैं, तो उन एंडपॉइंट्स तक पहुँच को IP अनुमति सूची के साथ प्रतिबंधित करें।.

F. सुरक्षित तैनाती मार्गदर्शन

नए नियमों को पहचान मोड में कम से कम 24 घंटे चलाएँ, लॉग की समीक्षा करें, फिर जब विश्वास हो तो ब्लॉकिंग पर जाएँ। एक रोलबैक योजना बनाए रखें।.

वर्डप्रेस-स्तरीय मुआवजा नियंत्रण (लागू करें यदि अपग्रेड तुरंत संभव नहीं है)

1. सार्वजनिक पंजीकरण को अस्थायी रूप से निष्क्रिय करें

   डैशबोर्ड: सेटिंग्स → सामान्य → “कोई भी पंजीकरण कर सकता है” को अनचेक करें। या पैच होने तक पंजीकरण को ब्लॉक करने के लिए एक फ़िल्टर जोड़ें।.

2. उम्मीदवार भूमिका क्षमताओं को मजबूत करें

   पहले स्टेजिंग पर एक mu-plugin जोड़ें ताकि खतरनाक क्षमताओं को हटा सकें:

   <?php;
   

3. प्लगइन फ्रंट-एंड क्रियाओं को अस्थायी रूप से निष्क्रिय करें

   यदि प्लगइन सार्वजनिक उपयोग के लिए गैर-आवश्यक व्यवस्थापक-ajax हैंडलर्स को पंजीकृत करता है, तो उन क्रियाओं को एक mu-plugin में हटा दें या फ़िल्टर करें जब तक कि आप विक्रेता पैच लागू नहीं कर सकते।.

4. संवेदनशील AJAX क्रियाओं के लिए मजबूत जांच की आवश्यकता है

   जहां व्यावहारिक हो, संवेदनशील admin-ajax क्रियाओं के लिए एक कस्टम हेडर, नॉनस, या क्षमता जांच की आवश्यकता है। वैध फ्रंट-एंड व्यवहार को तोड़ने से बचने के लिए सावधानी से परीक्षण करें।.

5. प्लगइन PHP फ़ाइलों की सुरक्षा करें

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

   /wp-content/plugins/wp-jobhunt/includes/ के लिए # उदाहरण .htaccess
   

निगरानी और शिकार टिप्स (पैच के बाद)

• पैचिंग के बाद कम से कम दो सप्ताह तक दैनिक उपयोगकर्ता निर्माण और भूमिका परिवर्तनों की निगरानी करें।.
• फ़ाइल अखंडता स्कैन चलाएं: कोड की तुलना विक्रेता द्वारा प्रदान की गई प्रतियों से करें।.
• वेबशेल संकेतकों की खोज करें: असामान्य base64, eval(), preg_replace के साथ /e, अपलोड पर फ़ाइल लेखन, आदि।.
• नए जोड़े गए कार्यों के लिए अनुसूचित कार्यों (wp-cron) की जांच करें।.
• हाल ही में संशोधित पोस्ट/पृष्ठों को निर्यात करें और इंजेक्टेड सामग्री या रीडायरेक्ट के लिए निरीक्षण करें।.

उपयोगी SQL:

-- हाल ही में संशोधित अटैचमेंट की खोज करें;

सर्वर-साइड खोज उदाहरण:

grep -R --include="*.php" -n --color -E "(base64_decode|eval\(|system\(|passthru\(|exec\(|shell_exec\()" /var/www/html

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

1. साइट को अलग करें (रखरखाव मोड या यदि गंभीर हो तो ऑफ़लाइन ले जाएं)।.
2. फोरेंसिक्स के लिए लॉग और डेटाबेस स्नैपशॉट को संरक्षित करें।.
3. सभी व्यवस्थापक और उच्च-विशेषाधिकार पासवर्ड को घुमाएं और सत्रों को अमान्य करें। उदाहरण (WP-CLI): wp user session destroy.
4. किसी भी नए व्यवस्थापक उपयोगकर्ताओं की जांच करें और उन्हें हटा दें जिन्हें आपने नहीं बनाया।.
5. उपलब्ध होने पर एक ज्ञात-अच्छे बैकअप से पुनर्स्थापित करें।.
6. मैलवेयर/बैकडोर हटाएं, फिर कोर, थीम और प्लगइन्स को नवीनतम में अपडेट करें।.
7. API कुंजी, टोकन और फ़ाइलों या डेटाबेस में संग्रहीत किसी भी क्रेडेंशियल को घुमाएं।.
8. एक पोस्ट-मॉर्टम करें: मूल कारण, प्रभाव का दायरा, और निवारक उपाय।.

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

उदाहरण WAF नियम पैटर्न - सामान्य प्लेटफार्मों के लिए अनुवादित

पठनीय पैटर्न जो आपकी सुरक्षा टीम अपने WAF के लिए अनुकूलित कर सकती है:

1. सामान्य संदर्भों से संदिग्ध admin-ajax क्रियाओं को ब्लॉक करें

   पैटर्न: admin-ajax.php?action=(job_create|job_update|user_elevate)

   शर्तें: विधि POST; मान्य व्यवस्थापक संदर्भ या नॉनस हेडर की कमी; UA/IP विसंगति स्कोरिंग।.

2. पंजीकरण अंत बिंदु को थ्रॉटल करें

   पैटर्न: wp-login.php?action=register या /wp-json/wp/v2/users यदि उपयोग किया गया। क्रिया: प्रति IP प्रति घंटे ~3 पंजीकरणों के लिए दर-सीमा।.

3. पैच होने तक REST लिखने के अंत बिंदुओं को ब्लॉक करें

   पैटर्न: ^/wp-json/(wp-jobhunt|wp-jobhunt/v1)/.*$ विधियाँ: POST, PUT, DELETE। क्रिया: ब्लॉक करें या अतिरिक्त सत्यापन की आवश्यकता करें।.

चेकलिस्ट: साइट मालिकों / व्यवस्थापकों के लिए चरण-दर-चरण

1. प्लगइन संस्करण की पुष्टि करें। यदि ≤ 7.6, तो इसे संवेदनशील मानें।.
2. साइट का बैकअप लें (फाइलें + डेटाबेस)।.
3. यदि संभव हो तो तुरंत प्लगइन को 7.7 में अपग्रेड करें।.
4. यदि आप अपग्रेड नहीं कर सकते हैं, तो प्लगइन को अक्षम करें या WAF वर्चुअल पैच लागू करें।.
5. उम्मीदवार भूमिका की क्षमताओं को मजबूत करें और यदि आवश्यक न हो तो पंजीकरण को अक्षम करें।.
6. निगरानी और स्कैनिंग (फाइल अखंडता, मैलवेयर जांच) सेट करें।.
7. उपयोगकर्ताओं और हाल के साइट परिवर्तनों का ऑडिट करें।.
8. व्यवस्थापक क्रेडेंशियल्स को घुमाएं और सत्रों को अमान्य करें।.
9. कम से कम 30 दिनों के लिए सर्वर और एप्लिकेशन लॉग को ध्यान से मॉनिटर करें।.
10. यदि संदिग्ध गतिविधि पाई जाती है, तो अलग करें और ऊपर दिए गए घटना प्रतिक्रिया चरणों का पालन करें।.

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

प्रश्न: क्या हमलावरों को इसका लाभ उठाने के लिए एक खाता चाहिए?

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

प्रश्न: क्या कोई उपलब्ध पैच है?

उत्तर: हाँ। विक्रेता ने WP JobHunt 7.7 जारी किया है जो प्राधिकरण जांच को ठीक करता है। तुरंत अपग्रेड करें।.

प्रश्न: क्या एक फ़ायरवॉल इसे पूरी तरह से ब्लॉक कर सकता है?

उत्तर: एक WAF कमजोर बिंदुओं को वर्चुअल-पैच करके और ज्ञात शोषण ट्रैफ़िक पैटर्न को ब्लॉक करके जोखिम को कम कर सकता है, लेकिन यह एक शमन है - आधिकारिक पैच का विकल्प नहीं।.

प्रश्न: क्या प्लगइन को निष्क्रिय करने से मेरी साइट टूट जाएगी?

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

हांगकांग के सुरक्षा विशेषज्ञ से समापन नोट्स

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

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

संदर्भ और अतिरिक्त पठन

• CVE-2025-7374 (सार्वजनिक रिकॉर्ड)
• प्लगइन विक्रेता रिलीज नोट्स - 7.7 में अपग्रेड करें
• OWASP शीर्ष 10: पहचान और प्रमाणीकरण विफलताएँ