एजेएक्स सर्च लाइट (≤ 4.13.1) — अनधिकृत जानकारी के कारण अनधिकृत मूलभूत जानकारी का खुलासा (CVE-2025-7956)

एक हांगकांग सुरक्षा सलाहकार के रूप में जो वर्डप्रेस जोखिम कमी में विशेषज्ञता रखता है, मैंने एजेएक्स सर्च लाइट (CVE-2025-7956) के हालिया खुलासे की समीक्षा की और इस व्यावहारिक, गैर-शोषणात्मक विश्लेषण को तैयार किया। कमजोर हैंडलर (asl_query) को बिना अनुमति के बुलाया जा सकता था, जिससे अनधिकृत ग्राहक मूलभूत खोज परिणाम प्राप्त कर सकते थे। विक्रेता ने संस्करण 4.13.2 में समस्या को ठीक किया।.

कार्यकारी सारांश — क्या हुआ और किसे परवाह करनी चाहिए

• कमजोरियों: एजेएक्स सर्च लाइट प्लगइन के एजेएक्स हैंडलर (asl_query) में अनुपस्थित प्राधिकरण ने अनधिकृत HTTP अनुरोधों को मूलभूत साइट डेटा लौटाने की अनुमति दी।.
• प्रभावित संस्करण: एजेएक्स सर्च लाइट ≤ 4.13.1
• में ठीक किया गया: 4.13.2
• CVE: CVE-2025-7956
• गंभीरता: कम (CVSS 5.3) — मुख्य रूप से जानकारी का खुलासा; सीधे खाता अधिग्रहण या RCE नहीं, लेकिन अन्वेषण के लिए उपयोगी।.
• आवश्यक विशेषाधिकार: अनधिकृत (लॉगिन की आवश्यकता नहीं)
• तात्कालिक कार्रवाई: प्लगइन को 4.13.2 या बाद के संस्करण में अपडेट करें। यदि तत्काल अपडेट संभव नहीं है, तो एंडपॉइंट को प्रतिबंधित करें या वर्चुअल-पैच करें और लॉग को निकटता से मॉनिटर करें।.

यह क्यों महत्वपूर्ण है — “मूलभूत जानकारी के खुलासे” के पीछे का वास्तविक जोखिम”

“मूलभूत जानकारी” के रूप में लेबल किया गया, खुलासा किया गया डेटा फिर भी हमलावरों को अन्वेषण के दौरान सहायता कर सकता है:

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

तकनीकी विश्लेषण — दोष क्या है और यह कैसे प्रकट होता है

उच्च स्तर का सारांश:

• एजेएक्स सर्च लाइट एक एजेएक्स क्रिया हैंडलर (asl_query) पंजीकृत करता है जो खोज क्वेरी करता है और परिणाम (शीर्षक, स्निपेट, आईडी) लौटाता है।.
• हैंडलर को सार्वजनिक एजेएक्स एंडपॉइंट (/wp-admin/admin-ajax.php) के माध्यम से बिना क्षमता जांच या नॉनस सत्यापन के बुलाया जा सकता था।.
• अनधिकृत उपयोगकर्ता या बॉट उचित पैरामीटर के साथ अनुरोध भेज सकते हैं और परिणाम प्राप्त कर सकते हैं।.

हमलावर क्या देखता है

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

सामान्य अनुरोध पैटर्न (गैर-शोषणकारी)

अनुरोध GET या POST होते हैं /wp-admin/admin-ajax.php के साथ action=asl_query और खोज शब्द और पृष्ठांकन के लिए अतिरिक्त पैरामीटर।.

यह एक पहुंच नियंत्रण विफलता क्यों थी

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

व्यवहार को ठीक किया गया (जो 4.13.2 पुनर्स्थापित करता है)

• लेखक ने अनधिकृत अनुरोधों को विस्तृत परिणाम लौटाने से पहले प्राधिकरण जांच (नॉनस या क्षमता) जोड़ी।.
• प्लगइन ने अनधिकृत कॉलर्स को लौटाए गए मेटाडेटा को भी कम किया हो सकता है।.

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

इन संकेतकों के लिए पहुंच और अनुप्रयोग लॉग की जांच करें:

1. अनुरोध admin-ajax.php जिसमें action=asl_query.
   उदाहरण: /wp-admin/admin-ajax.php?action=asl_query&asl_search=...
2. विभिन्न खोज स्ट्रिंग्स के साथ एकल आईपी से बार-बार अनुरोध (गुणात्मक अन्वेषण व्यवहार)।.
3. छोटे समय विंडो में उच्च मात्रा में अनुरोध (जन स्कैनिंग)।.
4. अप्रत्याशित 200 प्रतिक्रियाएँ जो शीर्षक, आईडी या अंश शामिल करने वाले JSON या HTML लौटाती हैं।.

खोज सुझाव:

• केंद्रीय लॉगिंग (ELK/Graylog): के लिए खोजें "admin-ajax.php" और "asl_query".
• एकल सर्वर पर:

  grep -i "admin-ajax.php" /var/log/nginx/access.log | grep "asl_query"

• जांचें wp-content/debug.log AJAX हैंडलरों के चारों ओर प्लगइन त्रुटियों के लिए।.

तात्कालिक शमन कदम (प्राथमिकता क्रम)

1. प्लगइन को 4.13.2 या बाद के संस्करण में अपडेट करें — विक्रेता ने एक सुधार प्रकाशित किया; अपडेट करना सही समाधान है। पहले स्टेजिंग पर परीक्षण करें।.
2. यदि आप तुरंत अपडेट नहीं कर सकते: WAF या सर्वर फ़िल्टरिंग के माध्यम से आभासी पैच — अनुरोधों को अवरुद्ध करें या दर-सीमा निर्धारित करें /wp-admin/admin-ajax.php जो शामिल हैं action=asl_query अप्रमाणित स्रोतों से।.
3. यदि प्लगइन गैर-आवश्यक है तो अस्थायी रूप से Ajax Search Lite को निष्क्रिय करें — पैच होने तक निष्क्रिय करें।.
4. निगरानी और अलर्ट: अनुरोधों के लिए लॉग अलर्ट बनाएं admin-ajax.php?action=asl_query.
5. AJAX एंडपॉइंट्स को मजबूत करें: सार्वजनिक AJAX के माध्यम से कौन सी क्रियाएँ अनुमति दी गई हैं, इसे सीमित करें; नॉनसेस की आवश्यकता करें या अनुमति जांच के साथ REST एंडपॉइंट्स पर कार्यक्षमता स्थानांतरित करें।.
6. न्यूनतम जानकारी सिद्धांत लागू करें: प्लगइन को अप्रमाणित उपयोगकर्ताओं को लौटाई गई जानकारी को सीमित करने के लिए कॉन्फ़िगर करें (आईडी, पूर्ण अंश से बचें)।.

अनुशंसित WAF / आभासी पैच नियम (पैटर्न और तर्क)

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

1) प्लगइन क्रिया के लिए बिना प्रमाणीकरण वाले admin-ajax कॉल को ब्लॉक करें

वैचारिक नियम:

• यदि URI मेल खाता है /wp-admin/admin-ajax.php
• और पैरामीटर क्रिया बराबर है asl_query
• और अनुरोध में एक मान्य लॉगिन कुकी या मान्यता प्राप्त WP nonce शामिल नहीं है
• तो ब्लॉक करें या 403 लौटाएं।.

वैचारिक ModSecurity उदाहरण (पढ़ने योग्य रूप):

SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "phase:1,chain,deny,status:403,msg:'बिना प्रमाणीकरण वाले asl_query को ब्लॉक करें'"

2) अनुरोधों की दर-सीमा / थ्रॉटल करें

यदि action=asl_query और स्रोत IP एक सीमा को पार करता है (उदाहरण के लिए, 10 अनुरोध/मिनट), थ्रॉटल करें या ब्लॉक करें। यह स्वचालित गणना को सीमित करता है।.

3) संदिग्ध हेडर पैटर्न को ब्लॉक करें

कई स्कैनर खाली या अजीब User-Agent और Referer हेडर भेजते हैं। वैध उपयोग के खिलाफ मान्यकरण के बाद, खाली रेफरर या ज्ञात खराब UA पैटर्न के साथ admin-ajax कॉल को ब्लॉक करने पर विचार करें।.

4) संवेदनशील क्षेत्रों को हटाने के लिए प्रतिक्रिया शरीर को फिर से लिखें

यदि ब्लॉक करना संभव नहीं है, तो बिना प्रमाणीकरण वाले अनुरोधों के लिए IDs/अंशों को हटाने वाली प्रतिक्रिया फिर से लिखना जानकारी के रिसाव को कम कर सकता है। इसके लिए एक WAF की आवश्यकता होती है जो प्रतिक्रिया शरीर के रूपांतरण का समर्थन करता है।.

5) फ्रंट-एंड फॉर्म के लिए Origin/Referer की आवश्यकता है

यदि आपकी खोज केवल आपके फ्रंटेंड पृष्ठों से शुरू होती है, तो एक मेल खाने वाला Origin या Referer हेडर की आवश्यकता है। सतर्क रहें - कुछ वैध क्लाइंट ये हेडर नहीं भेजते हैं।.

ये उपाय क्यों मदद करते हैं: वे परिधि गणना को रोकते हैं, पैचिंग के लिए समय खरीदते हैं, और स्वचालित स्कैनिंग शोर को कम करते हैं।.

पहचान संकेत — अलर्ट बनाने के लिए उपयोगी लॉग पैटर्न

• चेतावनी: admin-ajax.php?action=asl_query गैर-स्वीकृत आईपी से देखा गया → गंभीरता: मध्यम।.
• चेतावनी: >25 विभिन्न asl_query एक ही आईपी से 10 मिनट के भीतर अनुरोध → गंभीरता: उच्च।.
• चेतावनी: प्रतिक्रिया आकार > 1KB के लिए admin-ajax.php?action=asl_query प्रमाणीकरण रहित स्रोत से → संदिग्ध जानकारी लीक।.
• चेतावनी: नए UA स्कैनिंग पैटर्न हिट कर रहे हैं /wp-admin/* एंडपॉइंट्स → समीक्षा करें।.

जहां संभव हो, कम से कम 90 दिनों के लिए लॉग बनाए रखें — पहचान से पहले शोषण हो सकता है।.

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

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

AJAX हैंडलर्स के लिए दीर्घकालिक मजबूत रणनीतियाँ

• हमेशा सार्वजनिक AJAX एंडपॉइंट्स के लिए नॉन्स को मान्य करें जो सामान्य सार्वजनिक सामग्री से परे कुछ भी लौटाते हैं।.
• बिना प्रमाणीकरण वाले कॉल के लिए लौटाए गए डेटा को सीमित करें - केवल न्यूनतम फ़ील्ड लौटाएं।.
• जहाँ उपयुक्त हो, भूमिका/क्षमता जांच का उपयोग करें।.
• व्यापक रूप से खुले admin-ajax मार्गों के बजाय स्पष्ट अनुमति जांच और नॉन्स के साथ REST API एंडपॉइंट्स को प्राथमिकता दें।.
• प्लगइन स्वच्छता: प्लगइनों को अपडेट रखें, अप्रयुक्त प्लगइनों/थीमों को हटा दें, और प्रासंगिक भेद्यता फ़ीड्स की सदस्यता लें।.
• प्रति-साइट WAF नीतियों को लागू करें: बारीक अनुमति सूचियाँ/अस्वीकृति सूचियाँ और शून्य-दिन विंडो के लिए आभासी पैचिंग।.

प्रबंधित WAF मार्गदर्शन (सामान्य)

यदि आप एक प्रबंधित WAF या होस्ट-स्तरीय फ़ायरवॉल का उपयोग करते हैं, तो अपने प्रदाता से अनुरोध करें कि वे नियम लागू करें जो विशेष रूप से बिना प्रमाणीकरण वाले कॉल को अवरुद्ध या थ्रॉटल करें। admin-ajax.php?action=asl_query. एक संदर्भात्मक दृष्टिकोण - एकल IP से विभिन्न खोज शर्तों की बड़ी संख्या को थ्रॉटल करना - कुंद अवरोधन के बजाय प्राथमिकता दी जाती है, ताकि वैध उपयोगकर्ताओं को बाधित करने से बचा जा सके।.

व्यावहारिक सुरक्षित उदाहरण (चरण-दर-चरण)

1. स्टेजिंग: स्टेजिंग पर Ajax Search Lite को 4.13.2 में अपडेट करें और खोज कार्यक्षमता को मान्य करें।.
2. उत्पादन: रखरखाव की योजना बनाएं और 4.13.2 में अपडेट करें।.
3. यदि आप अपडेट नहीं कर सकते: एक WAF या सर्वर नियम लागू करें जो अनुरोधों को अवरुद्ध करता है जहाँ URI में शामिल है admin-ajax.php, पैरामीटर क्रिया==asl_query और कोई wordpress_logged_in कुकी मौजूद नहीं है। दर सीमा जोड़ें (जैसे, प्रति IP प्रति मिनट 5 बिना प्रमाणीकरण वाले अनुरोध)।.
4. 1. लॉग निगरानी: 2. के लिए अलर्ट बनाएं action=asl_query 3. और संचालन कर्मचारियों को सूचित करें।.
5. 4. हटाना: 5. यदि प्लगइन की आवश्यकता नहीं है, तो निष्क्रिय करें और अनइंस्टॉल करें।.
6. 6. फॉलो-अप: 7. साइट को फिर से स्कैन करें और विसंगतियों के लिए एक्सेस लॉग की समीक्षा करें।.

8. सामान्य प्रश्न और उत्तर

9. प्रश्न: क्या मेरी सामग्री अब इस समस्या के कारण सार्वजनिक है?

10. उत्तर: इस सुरक्षा दोष ने बिना प्रमाणीकरण के खोज कॉल को वह सब कुछ लौटाने की अनुमति दी जो प्लगइन को उजागर करने के लिए कॉन्फ़िगर किया गया था। यदि इसमें शीर्षक, आईडी या अंश शामिल थे, तो उन्हें एकत्र किया जा सकता था। यह स्वचालित रूप से निजी पोस्ट को सार्वजनिक नहीं बनाता, लेकिन यह आगे की जांच के लिए उपयोगी जानकारी प्रकट कर सकता है। अपने लॉग की जांच करें।.

11. प्रश्न: क्या CVSS स्कोर 5.3 सटीक है?

12. उत्तर: CVSS एक आधार रेखा है। यह मुख्य रूप से गैर-संवेदनशील सामग्री को उजागर करने के कारण अलग-थलग में कम गंभीरता है। संदर्भ महत्वपूर्ण है - अन्य मुद्दों के साथ मिलकर यह समग्र जोखिम को बढ़ा सकता है।.

13. प्रश्न: क्या मैं admin-ajax.php को पूरी तरह से ब्लॉक कर सकता हूँ?

14. उत्तर: कई थीम और प्लगइन फ्रंट-एंड कार्यक्षमता के लिए admin-ajax.php पर निर्भर करते हैं। इसे पूरी तरह से ब्लॉक करना सुविधाओं को तोड़ सकता है। विशिष्ट क्रियाओं को ब्लॉक करना (जैसे, asl_query15. ) या दर सीमाएँ लागू करना सामान्यतः अधिक सुरक्षित है।.

16. प्रश्न: मैं कई क्लाइंट साइटों की मेज़बानी करता हूँ - एक स्केलेबल समाधान क्या है?

17. उत्तर: सभी साइटों को अपडेट होने तक कार्रवाई को ब्लॉक या थ्रॉटल करने के लिए CDN/होस्ट स्तर पर एक परिधीय नियम लागू करें। यह कई साइटों में जोखिम को जल्दी सामान्य करता है। asl_query 18. समझौते के संकेत (IoCs) - क्या देखना है.

19. एक्सेस लाइनों में शामिल हैं

• उन लाइनों तक पहुँचें जिनमें admin-ajax.php?action=asl_query.
• admin-ajax.php 1. प्लगइन के लिए विशिष्ट पैरामीटर के साथ अनुरोध (जैसे, 2. asl_search, 3. asl_per_page).
• 4. ट्रैफ़िक में स्पाइक्स admin-ajax.php 5. एकल IP से।.
• 6. समान IP रेंज से दर्जनों विभिन्न खोज स्ट्रिंग के साथ दोहराए गए प्रयास।.
• 7. प्रतिक्रिया पेलोड में पोस्ट आईडी या स्लग शामिल हैं जहां ऐसा डेटा निजी होना चाहिए।.

8. उपसंहार - समय पर पैचिंग और परिधीय नियंत्रण क्यों महत्वपूर्ण हैं

9. वर्डप्रेस साइटें कई तृतीय-पक्ष प्लगइनों पर निर्भर करती हैं; यहां तक कि अच्छी तरह से बनाए गए प्रोजेक्ट भी कभी-कभी अपेक्षा से अधिक उजागर होते हैं। एक दो-तरफा रणनीति जोखिम को कम करती है:

• 10. जब विक्रेता अपडेट उपलब्ध हों तो जल्दी पैच करें।.
• 11. साइटों में पैचिंग पूरी करते समय एक्सपोज़र को कम करने के लिए परिधीय सुरक्षा (WAF/होस्ट नियम, दर सीमाएँ) लागू करें।.

12. समापन सिफारिशें (त्वरित चेकलिस्ट)

• 13. तुरंत Ajax Search Lite को 4.13.2 में अपडेट करें।.
• 14. यदि अपडेट करना तुरंत संभव नहीं है, तो अनधिकृत asl_query 15. कॉल को ब्लॉक करने के लिए नियम लागू करें और दर सीमाएँ लागू करें।.
• 16. कॉल के लिए एक्सेस लॉग की निगरानी करें और अलर्ट सेट करें। admin-ajax.php 17. अप्रयुक्त प्लगइनों को हटा दें और पर निर्भरता को सीमित करें.
• 18. जहां व्यावहारिक हो। admin-ajax.php जहाँ व्यावहारिक हो।.

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