कार्यकारी सारांश
19 मई 2026 को NPM पैकेज “सिल्लीटैवर्न” (≤ 1.17.0) को प्रभावित करने वाली उच्च-गंभीरता वाली सर्वर साइड अनुरोध धोखाधड़ी (SSRF) की कमजोरी प्रकाशित की गई (CVE-2026-46372, GHSA-qg89-qwwh-5f3j)। यह समस्या एक अव्यवस्थित baseUrl पैरामीटर से उत्पन्न होती है जो SearXNG खोज प्रॉक्सी एकीकरण द्वारा उपयोग की जाती है। एक हमलावर इस दोष का दुरुपयोग करके प्रभावित सर्वर को हमलावर-नियंत्रित या आंतरिक पते पर HTTP अनुरोध करने के लिए मजबूर कर सकता है, जिससे संभावित रूप से क्रेडेंशियल्स, मेटाडेटा एंडपॉइंट्स, आंतरिक सेवाओं का खुलासा हो सकता है, या आगे की पार्श्व गति को सक्षम किया जा सकता है। पैकेज को संस्करण 1.18.0 में पैच किया गया था। यदि आप किसी भी सेवा को चलाते हैं जो सिल्लीटैवर्न पर निर्भर करती है या रिवर्स प्रॉक्सी कार्यक्षमता को उजागर करती है, तो इसे तत्काल समझें।.

यह वर्डप्रेस साइट मालिकों के लिए क्यों महत्वपूर्ण है

हालांकि यह कमजोरी एक NPM पैकेज में है, आधुनिक वर्डप्रेस साइटें अक्सर अन्य सेवाओं (Node.js माइक्रोसर्विसेज, चैट फ्रंटेंड, स्वयं-होस्टेड सहायक, आदि) के साथ बुनियादी ढांचे को साझा करती हैं। जब कई सेवाएं एक ही होस्ट, नेटवर्क, या क्रेडेंशियल्स को साझा करती हैं, तो एक घटक में SSRF को उस आंतरिक संसाधनों तक पहुंचने के लिए हथियार बनाया जा सकता है जिन पर वर्डप्रेस एप्लिकेशन या इसके प्रशासक निर्भर करते हैं।.

• साझा होस्टिंग: वर्डप्रेस उसी VM या कंटेनर पर हो सकता है जैसे अन्य सॉफ़्टवेयर जो Node पैकेज का उपयोग करता है।.
• मिश्रित स्टैक्स: टीमें मिश्रित-प्रौद्योगिकी उपकरण चलाती हैं जो एक घटक के समझौता होने पर एक पिवट के रूप में उपयोग किए जा सकते हैं।.
• SSRF जोखिम: कोई भी घटक जो एक इनपुट की ओर से आउटबाउंड HTTP(S) अनुरोध करता है, उसे आंतरिक एंडपॉइंट्स जैसे मेटाडेटा सेवाओं, प्रबंधन APIs, या स्थानीय प्रशासन इंटरफेस को क्वेरी करने के लिए धोखा दिया जा सकता है।.

SSRF उच्च-प्रभाव है क्योंकि हमलावर अनुरोध लक्ष्य को नियंत्रित करता है; परिणामों में क्रेडेंशियल चोरी से लेकर क्लाउड या निजी नेटवर्क के भीतर पार्श्व गति तक शामिल हैं।.

तकनीकी पृष्ठभूमि — क्या हुआ

सिल्लीटैवर्न कुछ सुविधाओं के लिए SearXNG को खोज प्रॉक्सी के रूप में उपयोग करता है। कमजोर रिलीज़ (≤ 1.17.0) में baseUrl कॉन्फ़िगरेशन मान को मान्य नहीं किया गया था। इससे एक हमलावर को आपूर्ति या हेरफेर करने की अनुमति मिली baseUrl ताकि एप्लिकेशन हमलावर द्वारा चुने गए मनमाने URLs पर अनुरोध जारी करे।.

प्रमुख विशेषताएँ:

• वर्ग: सर्वर साइड अनुरोध धोखाधड़ी (SSRF)।.
• मूल कारण: URL/कॉन्फ़िगरेशन पैरामीटर का अपर्याप्त मान्यकरण (baseUrl).
• प्रभाव: सर्वर को आंतरिक IPs, क्लाउड मेटाडेटा एंडपॉइंट्स (जैसे, 169.254.169.254), या किसी भी पहुंच योग्य होस्ट के लिए अनुरोध करने के लिए प्रेरित किया जा सकता है।.
• पैच: sillytavern v1.18.0 में हमलावर-नियंत्रित को रोकने के लिए मान्यता और प्रतिबंध शामिल हैं baseUrl मान।.

संदर्भ: CVE-2026-46372, GHSA-qg89-qwwh-5f3j।.

संभावित शोषण परिदृश्य (उच्च स्तर)

जोखिम को समझने के लिए प्रतिनिधि हमले (कोई शोषण कोड प्रदान नहीं किया गया):

• क्लाउड मेटाडेटा प्राप्त करें: क्रेडेंशियल या टोकन प्राप्त करने के लिए मेटाडेटा एंडपॉइंट्स का अनुरोध करना (जैसे, AWS IMDS पर 169.254.169.254)।.
• आंतरिक प्रशासन इंटरफेस तक पहुंच: लोकलहोस्ट या आंतरिक उपनेट्स से बंधी प्रबंधन एपीआई तक पहुंच।.
• पोर्ट स्कैनिंग / खोज: आंतरिक आईपी रेंज और सेवाओं को मैप करने के लिए कमजोर मेज़बान का उपयोग करें।.
• नेटवर्क नियंत्रणों को बायपास करें: पीड़ित सर्वर को इंटरनेट से अवरुद्ध अनुरोध करने दें।.
• डेटा एक्सफिल्ट्रेशन: आंतरिक डिबग एंडपॉइंट्स का क्वेरी करें और हमलावर-नियंत्रित एंडपॉइंट पर संवेदनशील डेटा लौटाएं।.

शोषण प्रयासों का पता लगाने के लिए कैसे

पहचान के लिए वेब ट्रैफ़िक और आउटबाउंड गतिविधि का सहसंबंध आवश्यक है। देखें:

• वेब सर्वर लॉग: ऐसे अनुरोध जिनमें पैरामीटर जैसे baseUrl, प्रॉक्सी, यूआरएल, लक्ष्य. लंबे, एन्कोडेड, या क्रेडेंशियल-समाहित मान संदिग्ध हैं।.
• एप्लिकेशन लॉग: आउटबाउंड अनुरोधों के लिए लॉग की गई गंतव्य पते; आउटबाउंड अनुरोध आवृत्ति में वृद्धि।.
• आउटबाउंड नेटवर्क/इग्रेस लॉग: वेब प्रक्रिया से 169.254.169.254, 127.0.0.1, RFC1918 रेंज, या IPv6 लिंक-लोकल पते के लिए कनेक्शन।.
• DNS लॉग: यादृच्छिक उपडोमेन या असामान्य समाधान पैटर्न के लिए क्वेरी।.
• WAF लॉग: संदिग्ध को रोकने वाले नियम baseUrl मान या निजी आईपी पैटर्न।.
• प्रक्रिया व्यवहार: PHP/Node रनटाइम से नेटवर्क कॉल करने वाली नई या अप्रत्याशित प्रक्रियाएँ, या CPU/DNS स्पाइक्स।.

सामान्य व्यवहार के लिए आधार रेखाएँ स्थापित करें ताकि विचलनों का अधिक विश्वसनीयता से पता लगाया जा सके।.

तात्कालिक कदम — अगले कुछ घंटों में क्या करना है

1. सॉफ़्टवेयर पैच करें

   यदि आप SillyTavern या sillytavern पर निर्भर सेवाएँ चला रहे हैं, तो तुरंत v1.18.0 पर अपडेट करें। यह सही समाधान है।.

2. यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो वर्चुअल पैच

   दुर्भावनापूर्ण उपयोग का पता लगाने और रोकने के लिए WAF नियम लागू करें baseUrl और उन एंडपॉइंट्स तक सार्वजनिक पहुंच को सीमित करें जो प्रॉक्सी URLs स्वीकार करते हैं।.

3. आउटगोइंग कनेक्शनों को सीमित करें

   होस्ट ईग्रेस नियम (क्लाउड सुरक्षा समूह, फ़ायरवॉल, iptables) लागू करें ताकि अनुमत गंतव्यों को छोड़कर आउटबाउंड ट्रैफ़िक को अस्वीकार किया जा सके। न्यूनतम, क्लाउड मेटाडेटा एंडपॉइंट्स (169.254.169.254) और आंतरिक प्रबंधन नेटवर्क तक पहुंच को ब्लॉक करें।.

4. क्वारंटाइन करें और जांच करें

   यदि संकेत मौजूद हैं, तो प्रभावित होस्ट को अलग करें, लॉग को संरक्षित करें, और क्रेडेंशियल चोरी या स्थिरता के संकेतों की खोज करें।.

5. क्रेडेंशियल और रहस्यों को घुमाएँ (यदि आवश्यक हो)

   यदि मेटाडेटा या व्यवस्थापक APIs को क्वेरी किया गया हो, तो API कुंजियाँ और सेवा क्रेडेंशियल्स को घुमाएँ।.

6. फॉलो-ऑन क्रियाओं की निगरानी करें

   नए खातों, परिवर्तित कॉन्फ़िगरेशन, संशोधित फ़ाइलों, या अनुसूचित कार्यों पर नज़र रखें जो फॉलो-अप गतिविधि का संकेत देते हैं।.

WAF शमन और उदाहरण नियम

1. नीचे सामान्य SSRF पैटर्न का पता लगाने और अवरुद्ध करने के लिए व्यावहारिक ModSecurity-शैली के उदाहरण दिए गए हैं। उत्पादन से पहले इन्हें स्टेजिंग में परीक्षण करें; अपने वातावरण के अनुसार अनुकूलित करें।.

2. 1) निजी IPs या मेटाडेटा एंडपॉइंट्स का संदर्भ देने वाले अनुरोधों को अवरुद्ध करें baseUrl 3. # निजी IPs या मेटाडेटा एंडपॉइंट्स को शामिल करने वाले baseUrl पैरामीटर की जांच करें

SecRule ARGS_NAMES|ARGS "@rx (?i)^(baseurl|base_url|proxy_url|target_url)$" "phase:2,pass,id:100001,log,ctl:ruleRemoveById=981172"
    

SecRule ARGS:baseUrl|ARGS:base_url|ARGS:proxy_url|ARGS:target_url \n "@rx (?i)(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.169\.254|fe80:|::1)" \n "phase:2,deny,status:403,msg:'संभावित SSRF अवरुद्ध - baseUrl में अवैध लक्ष्य',id:100002,log" उन अनुरोधों को अस्वीकार करें जहां baseUrl 5. उद्देश्य:.

6. लोकलहोस्ट, RFC1918 पते, AWS मेटाडेटा, या IPv6 लिंक-लोकल पते की ओर इशारा करता है।

7. 2) एम्बेडेड क्रेडेंशियल्स या संदिग्ध प्रोटोकॉल के साथ URLs को अस्वीकार करें"
    

8. # बेसिक ऑथ क्रेडेंशियल्स या खतरनाक प्रोटोकॉल के साथ URLs को अवरुद्ध करें

SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n    "phase:2,deny,status:403,msg:"संभावित SSRF अवरुद्ध - क्रेडेंशियल्स या असुरक्षित स्कीम मिली',id:100003,log"
    

9. 3) बार-बार प्रॉक्सी अनुरोधों की दर सीमित करें या अवरुद्ध करें.

10. # दर सीमित करने का उदाहरण (संकल्पना)

SecRule REQUEST_URI "@contains /proxy" "phase:1,pass,nolog,exec:/usr/local/bin/check_rate_limit.sh".

नोट: 11. स्वचालित शोषण प्रयासों को कम करने के लिए एक दर-सीमित करने वाले के साथ एकीकृत करें।.

12. 4) निजी पते को हल करने वाले DNS लुकअप को अवरुद्ध करें

13. यदि आपका WAF या प्रॉक्सी बाहरी जांच का समर्थन करता है, तो प्रदान किए गए होस्टनाम को हल करें और जब यह निजी IPs पर हल होता है तो अवरुद्ध करें। यह DNS दौड़ की स्थितियों से बचने के लिए सावधानीपूर्वक कार्यान्वयन की आवश्यकता है।

• 14. ये रक्षात्मक पैटर्न हैं। ये जोखिम को कम करते हैं लेकिन कमजोर पैकेज को पैच करने के लिए प्रतिस्थापित नहीं करते हैं। 15. डेवलपर्स के लिए हार्डनिंग मार्गदर्शन (कोड में सुधार).
• 16. बाहरी URLs या प्रॉक्सी कॉन्फ़िगरेशन को स्वीकार करने वाले डेवलपर्स को इन प्रथाओं को अपनाना चाहिए: 17. अनुमति सूची होस्ट: http 8. और https जहाँ उपयुक्त हो।.
• मेज़बान सत्यापन लागू करें: मेज़बान घटक को पार्स और मान्य करें; निजी रेंज में IP को अस्वीकार करें।.
• अंतर्निहित क्रेडेंशियल्स को रोकें: उन URLs की अनुमति न दें जिनमें शामिल हैं उपयोगकर्ता:पास@होस्ट.
• हल करें और मान्य करें: यदि होस्टनाम की अनुमति है, तो उन्हें हल करें और यदि परिणामस्वरूप IP निजी हैं तो अस्वीकार करें। एक सुरक्षित समाधानकर्ता का उपयोग करें और दौड़ की स्थितियों पर विचार करें।.
• टाइमआउट और सीमाएँ: लंबे समय तक चलने वाले अनुरोधों से बचने के लिए अनुरोध टाइमआउट और अधिकतम रीडायरेक्ट सेट करें।.
• कॉन्फ़िगरेशन को संवेदनशील के रूप में मानें: सख्त मान्यता के बिना रनटाइम कॉन्फ़िगरेशन के रूप में उपयोगकर्ता द्वारा प्रदान किए गए मानों का सीधे उपयोग न करें।.

ये वे प्रकार के उपाय हैं जो SillyTavern के रखरखावकर्ताओं ने v1.18.0 में लागू किए।.

मेज़बान और नेटवर्क स्तर की सुरक्षा

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

नेटवर्क नियंत्रण यह सीमित करते हैं कि SSRF क्या पहुँच सकता है भले ही एप्लिकेशन एक अवधि के लिए कमजोर बना रहे।.

घटना प्रतिक्रिया चेकलिस्ट (व्यावहारिक कदम)

1. साक्ष्य को संरक्षित करें

   वेब, एप्लिकेशन, फ़ायरवॉल, DNS, और नेटवर्क लॉग कैप्चर करें। सुनिश्चित करें कि लॉग ओवरराइट नहीं होते।.

2. सीमित करें

   कमजोर विशेषता को अक्षम करें या मेज़बान को IP प्रतिबंधों के पीछे रखें। यदि आवश्यक हो तो अस्थायी रूप से सार्वजनिक पहुंच हटा दें।.

3. पैच

   sillytavern को v1.18.0 में अपडेट करें या विक्रेता द्वारा अनुशंसित सुधार लागू करें।.

4. 1. विश्लेषण करें

   संदिग्ध के लिए पहुंच लॉग की जांच करें baseUrl मान और मेज़बान से आउटगोइंग कनेक्शनों और DNS क्वेरी की जांच करें।.

5. रहस्यों को घुमाएँ

   यदि मेटाडेटा या क्रेडेंशियल्स उजागर हो गए हैं, तो API कुंजी और टोकन को घुमाएं।.

6. स्कैन और साफ करें

   पोस्ट-एक्सप्लॉइट कलाकृतियों का पता लगाने के लिए मैलवेयर स्कैन और अखंडता जांच चलाएं।.

7. पुनर्स्थापित करें और निगरानी करें

   केवल यह पुष्टि करने के बाद सामान्य संचालन फिर से शुरू करें कि सिस्टम साफ है। कम से कम 30 दिनों तक निगरानी बढ़ाएं।.

8. रिपोर्ट

   अपनी घटना प्रतिक्रिया नीति या नियामक दायित्वों के अनुसार अपनी सुरक्षा टीम, होस्टिंग प्रदाता या ग्राहकों को सूचित करें।.

खोजने के लिए पहचान और लॉग उदाहरण

लॉग खोजने या अपने होस्टिंग प्रदाता के साथ समन्वय करते समय इन संकेतकों का उपयोग करें:

• पैरामीटर के साथ अनुरोध: ?baseUrl=, ?proxy=, ?target=, POST/JSON निकाय जिसमें शामिल हैं baseUrl या proxy_url.
• पैरामीटर मान जिसमें शामिल हैं: 169.254.169.254, 127.0.0.1, लोकलहोस्ट, 10., 172.16.–172.31., 192.168., fe80:, ::1, या @ वर्ण (संलग्न क्रेडेंशियल्स)।.
• आपके वेब सर्वर IP से निजी रेंज में आउटबाउंड अनुरोधों में वृद्धि।.
• WAF लॉग जो SSRF पैटर्न के लिए सिग्नेचर ट्रिगर्स दिखा रहे हैं।.

अपडेट करना अभी भी सबसे महत्वपूर्ण कदम क्यों है

WAF नियम और आउटबाउंड फ़िल्टरिंग मुआवज़ा नियंत्रण हैं। वे जोखिम को कम करते हैं लेकिन अंतर्निहित कमजोरियों को समाप्त नहीं करते। सही सुधार यह है कि sillytavern को v1.18.0 में अपडेट करें, जो मूल कारण को ठीक करता है। वर्चुअल पैच विफल हो सकते हैं यदि हमलावर पेलोड को संशोधित करते हैं या यदि वैध उपयोग के मामले नियमों को बायपास करते हैं।.

सुरक्षित कॉन्फ़िगरेशन चेकलिस्ट (सारांश)

• sillytavern को v1.18.0 (या बाद में) में अपडेट करें।.
• WAF नियमों को ब्लॉक करने के लिए लागू करें baseUrl निजी रेंज, मेटाडेटा आईपी, और एम्बेडेड क्रेडेंशियल्स की ओर इशारा करना।.
• वेब प्रक्रियाओं के लिए आउटबाउंड नेटवर्क एक्सेस को प्रतिबंधित करें; एप्लिकेशन प्रक्रियाओं से क्लाउड मेटाडेटा एंडपॉइंट्स को ब्लॉक करें।.
• अन्य उपयोगकर्ता-प्रदत्त URL पैरामीटर के लिए एप्लिकेशन कोड की समीक्षा करें और तदनुसार मजबूत करें।.
• संदिग्ध प्रॉक्सी उपयोग के लिए लॉग की निगरानी करें और असामान्य आउटबाउंड कनेक्शनों के लिए अलर्ट लागू करें।.
• यदि मेटाडेटा या आंतरिक एंडपॉइंट्स तक पहुंच हो सकती है तो क्रेडेंशियल्स को घुमाएं।.
• यदि शोषण का संदेह है तो पूर्ण जांच और मैलवेयर स्कैन करें।.

अंतिम विचार

SSRF कमजोरियाँ विशेष रूप से खतरनाक होती हैं क्योंकि वे एक हमलावर को आपकी अपनी अवसंरचना का उपयोग एक पहचान और हमले के प्लेटफ़ॉर्म के रूप में करने की अनुमति देती हैं। उन वर्डप्रेस ऑपरेटरों के लिए जो Node.js सेवाओं या मिश्रित वातावरण के साथ अवसंरचना साझा करते हैं, यह SillyTavern SSRF एक अनुस्मारक है कि:

• 12. तुरंत पैच करें।.
• अपडेट करते समय WAFs का अस्थायी वर्चुअल पैच के रूप में उपयोग करें।.
• आउटबाउंड नियमों और नेटवर्क विभाजन को मजबूत करें।.
• लॉग की निगरानी करें और प्रतिक्रिया देने के लिए तैयार रहें।.

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