exploit-garbage/0day-rubbishएआई युग में भेद्यता प्रकटीकरण को फिर से परिभाषित करना। हम शोषण योग्य 0days का थोक निर्माण करते हैं और उन्हें सीधे प्रकट करते हैं, घटना-संचालित दबाव का उपयोग करके विक्रेता सुरक्षा मानकों को ऊपर उठाने और क्षेत्र को आगे बढ़ाने के लिए।
# 0day Rubbish > **AI युग में 0day कमज़ोरियाँ कचरा बन गई हैं।** [](./LICENSE) [](https://0day-rubbish.com/blog) [](https://0day-rubbish.com/blog) [](https://0day-rubbish.com/blog) [](https://0day-rubbish.com) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://github.com/Exploit-Garbage/0day-Rubbish/discussions) [](https://github.com/Exploit-Garbage/0day-Rubbish/commits) **🌐 आधिकारिक वेबसाइट**: <https://0day-rubbish.com/blog> --- ## 🎯 यह क्यों मौजूद है पारंपरिक कमज़ोरी प्रकटीकरण (vulnerability disclosure) टूट चुका है। यह धीमा, नौकरशाही से भरा और अप्रभावी है। AI युग में, हम बड़े पैमाने पर 0day का सामूहिक उत्पादन कर सकते हैं—जिससे व्यक्तिगत कमज़ोरियाँ कम मूल्यवान हो जाती हैं, लेकिन सीधे प्रकट किए जाने पर अधिक प्रभावशाली होती हैं। हमारा मानना है कि **इवेंट-ड्रिवन सुरक्षा हार्डनिंग** सबसे प्रभावी दृष्टिकोण है: केवल तभी जब विक्रेताओं को वास्तविक, शोषण-योग्य खतरों का सामना करना पड़ता है, वे सुधारों को प्राथमिकता देते हैं। ## 🔄 हमारी प्रकटीकरण प्रक्रिया ### चरण 1: AI खोज हमारे स्वचालित AI सिस्टम वास्तविक दुनिया के सॉफ़्टवेयर में लगातार कमज़ोरियों को स्कैन करते हैं, पैटर्न विश्लेषण, फ़ज़िंग और बुद्धिमान कोड समीक्षा के माध्यम से संभावित 0-day की पहचान करते हैं। ### चरण 2: सत्यापन और PoC विकास प्रत्येक खोज का मैन्युअल सत्यापन किया जाता है। हम शोषण-क्षमता की पुष्टि और वास्तविक दुनिया के प्रभाव का आकलन करने के लिए कार्यशील प्रूफ़-ऑफ़-कॉन्सेप्ट एक्सप्लॉइट विकसित करते हैं। ### चरण 3: आवधिक सार्वजनिक प्रकटीकरण हर सप्ताह — सोमवार या मंगलवार — हम सत्यापित, शोषण-योग्य 0-day कमज़ोरियों का एक नया बैच प्रकट करते हैं जिन्हें हमने खोजा और मान्य किया है: - पूर्ण तकनीकी विश्लेषण और मूल कारण - कार्यशील PoC एक्सप्लॉइट कोड - प्रभावित संस्करण और सिस्टम - प्रभाव आकलन - अनुशंसित शमन उपाय कोई देरी नहीं। कोई नौकरशाही नहीं। केवल तथ्य। **सभी विक्रेताओं से**: हम आशा करते हैं कि हैकर्स द्वारा इन कमज़ोरियों का शोषण करने से पहले आप सुधार पूरे कर लेंगे। ## ⚡ मूल सिद्धांत - **केवल वास्तविक दुनिया का प्रभाव**: हम केवल उन कमज़ोरियों का खुलासा करते हैं जो वास्तविक उपयोगकर्ता आधार वाले वास्तविक दुनिया के सिस्टम को प्रभावित करती हैं - **कोई बेकार लक्ष्य नहीं**: गैर-शोषण-योग्य कमज़ोरियाँ या नगण्य उपयोगकर्ता अपनाने वाले डिवाइस बाहर रखे गए हैं—वे शून्य मूल्य वाला कचरा हैं - **प्रोटोकॉल से अधिक गति**: प्रत्यक्ष प्रकटीकरण पारंपरिक चैनलों की तुलना में तेज़ कार्रवाई को बढ़ावा देता है - **दावों से अधिक प्रमाण**: प्रत्येक प्रकटीकरण में कार्यशील एक्सप्लॉइट शामिल हैं - **मात्रा से अधिक प्रभाव**: उच्च-गंभीरता, व्यापक रूप से तैनात कमज़ोरियों पर ध्यान केंद्रित करें - **पारदर्शिता**: पूर्ण तकनीकी विवरण, कोई छिपा एजेंडा नहीं - **गैर-लाभकारी**: वित्तीय लाभ से नहीं, बल्कि सुरक्षा अनुसंधान के जुनून से प्रेरित ## 🤝 सहयोग हम इनके साथ साझेदारी करते हैं: - स्वचालित सुरक्षा अनुसंधान को आगे बढ़ाने वाले शीर्ष AI मॉडल प्रदाता - AI-संचालित खोज का पता लगाने वाले सुरक्षा शोधकर्ता ## 🤖 उपयोग किए गए AI मॉडल हमारी स्वचालित कमज़ोरी खोज अग्रणी AI प्रदाताओं के अत्याधुनिक बड़े भाषा मॉडल का लाभ उठाती है: - **Anthropic (Claude)** - गहन सुरक्षा पैटर्न पहचान और तर्क - **OpenAI** - उन्नत तर्क और कोड विश्लेषण - **DeepSeek** - विशेष कमज़ोरी पहचान - **Z.ai (GLM)** - लंबे-संदर्भ वाला कोड विश्लेषण - **Moonshot (Kimi)** - लंबे-संदर्भ वाला सुरक्षा विश्लेषण --- ## 📋 प्रकट की गई कमज़ोरियाँ एक AI-संचालित अनुसंधान प्रक्रिया (मल्टी-LLM एन्सेम्बल: Claude, OpenAI, DeepSeek, GLM, Kimi) वास्तविक दुनिया के एंटरप्राइज़ सॉफ़्टवेयर में 0-day खोजती है। नीचे दी गई प्रत्येक सलाह में एक **पूर्ण मूल-कारण विश्लेषण** के साथ-साथ एक **कार्यशील, पुनरुत्पादनीय एक्सप्लॉइट स्क्रिप्ट** शामिल है — कोई केवल-पहचान वाली रिपोर्ट नहीं, कोई रोका गया विवरण नहीं। ### नवीनतम बैच — बैच 16 (6 सलाह) *छह निष्कर्ष जिनमें से प्रत्येक को सिद्ध करने के लिए ऑडिटर के अपने ही उपकरणों की आवश्यकता पड़ी, और जिनमें से कोई भी उससे अधिक दावा नहीं करता जितना उपकरणों ने दिखाया: एक PHP एंडपॉइंट के विरुद्ध एक अनाम अपलोड युग्म जो कभी अपने 2007-युग के प्रमाणीकरण मॉडल से आगे नहीं बढ़ा; एक रूटिंग डेमॉन का डायग्नोस्टिक्स एंडपॉइंट जिसने अपने ही होस्टनेम वैलिडेटर को उलट दिया; एक कंज़्यूमर राउटर जिसका SOAP ऐप-इंस्टॉल फ़ील्ड एक शेल बन गया; और एक औद्योगिक सेलुलर राउटर की शेल-निर्मित कॉन्फ़िगरेशन सतह में तीन अलग-अलग प्रवेश बिंदु। छह में से चार कच्चे स्रोत रिकॉर्ड के सुझाव से कम आंकड़ा प्रकाशित करते हैं, और उनमें से प्रत्येक डाउनग्रेड अपने अंकगणित के साथ उस स्कोर के बगल में मुद्रित है जिसे वह सुधारता है।* | # | उत्पाद | प्रभावित संस्करण | CVSS | वर्ग | सलाह और PoC | |---|---------|------------------|------|-------|-----------------| | 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | LAN-साइड प्रबंधन प्लेन पर SOAP InstallApp क्रिया `apName` आर्ग्युमेंट पर एक `rm -rf` शेल कमांड बनाती है; एक `$(...)` प्रतिस्थापन कमांड शब्द के हल होने से पहले रूट-कॉन्फ़िगर किए गए वेब स्टैक तक पहुँच जाता है | [InstallApp apName → शेल कमांड प्रतिस्थापन](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) | | 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | एक सादा `copy()` अपलोड एंडपॉइंट जिसमें न कोई सत्र, न कोई एक्सटेंशन गेट और न कोई पथ जाँच है, जो उस वेब-रूट लैंडिंग पैटर्न को जारी रखता है जिसे विक्रेता की बंद की गई श्रृंखला ने प्रसिद्ध बनाया था; एक एकल अनाम अनुरोध युग्म एक निष्पादन योग्य पृष्ठ लिखता है और उसे वापस प्राप्त करता है | [upload.php → वेब-रूट राइट → वेब-साइड कोड निष्पादन](https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce) | | 3 | Raritan PX3 PDU G4 | फ़र्मवेयर 4.3.14 | **8.8** \* | एक डायग्नोस्टिक्स `ping`/`traceroute` हैंडलर जिसका होस्टनेम वैलिडेटर अपनी ही रिटर्न जाँच को उलट देता है, हर सामान्य प्रमाणीकृत सत्र द्वारा पहुँच योग्य, जबकि `netstat` में एक केवल-व्यवस्थापक विशेषता है जो डायग्नोस्टिक्स युग्म में अनुपस्थित है | [diag ping → रिटर्न-वैल्यू उलटाव → शेल इंजेक्शन](https://0day-rubbish.com/blog/raritan-px3-pdu-g4-diag-ping-traceroute-command-injection) | | 4 | Moxa MAR-2000 FWR_MAR2000 V1.0 Build 15010909 | V1.0 Build 15010909 | **7.2** \* | प्रबंधन UI की प्रोग्राम तालिका अपने `argument` फ़ील्ड को सीधे उपयोगकर्ता-प्रोग्राम लॉन्चर की कमांड लाइन में पास करती है | [Executer argument → प्रोग्राम-लॉन्च इंजेक्शन](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) | | 5 | Moxa MAR-2000 (वही उत्पाद, वही बैच) | V1.0 Build 15010909 | **7.2** \* | पाँच अलग-अलग `ipsec.py` हैंडलर टनल-एड्रेस फ़ील्ड से आने वाले हमलावर टेक्स्ट को लेकर रूट-प्रबंधन कमांड में शेल आउट करते हैं; एक उत्पाद के निष्कर्ष कभी बैचों में विभाजित नहीं होते | [टनल एड्रेस → रूट-प्रबंधन शेल](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) | | 6 | Moxa MAR-2000 (वही उत्पाद, वही बैच) | V1.0 Build 15010909 | **7.2** \* | एक परिदृश्य इंजन समय-समय पर एक सहेजी गई `ping` शर्त का पुनर्मूल्यांकन करता है, और थ्रेड प्रत्येक पास पर शेल कमांड को पुनः बनाता है, इसलिए एक संग्रहीत पेलोड बिना हमलावर द्वारा कोई भी अनुरोध दोबारा भेजे सक्रिय हो जाता है | [scenario ping → स्वतः-निष्पादन थ्रेड](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) | \* सभी छह एक से अधिक रीडिंग प्रकाशित करते हैं। प्रत्येक सलाह उन रीडिंग्स को अपने साथ रखती है जिन्हें उसने अस्वीकार किया या सशर्त बनाया, उस एक के बगल में जिसका वह समर्थन करती है, प्रत्येक अपने स्वयं के वेक्टर और अंकगणित के साथ: > - **निष्कर्ष 1** — **6.8**, `AV:A/PR:H` पर प्रकाशित: कोई भी शिप किया गया आर्टिफ़ैक्ट WAN-साइड एक्सपोज़र का प्रमाण नहीं देता, और यह क्रिया एडमिन टियर की है, इसलिए भोली 8.8-और-नेटवर्क्ड व्याख्या के दोनों हिस्से आर्टिफ़ैक्ट जाँचों में गिर गए, और स्रोत रिकॉर्ड का अपना 8.8 अंदर PR:L वेरिएंट के रूप में उसके अंकगणित के साथ दिखाया गया है, शीर्षक के रूप में नहीं। 7.2 पर `AV:N` उन डिप्लॉयमेंट्स के लिए लेबल किया गया सशर्त है जिनका प्रबंधन प्लेन जानबूझकर उजागर किया गया है। > - **निष्कर्ष 2** — `PR:N` पर **9.8**। एक एकल अनाम अनुरोध युग्म; वेब टियर जो कुछ भी लिखा गया है उसे फिर से परोसता है। निष्पादन रेप्लिकेशन एनवायरनमेंट के वेब सर्विस अकाउंट के रूप में होता है और ठीक उसी प्रकार रिपोर्ट किया गया है: डिवाइस-साइड सर्विस पहचान को कभी मापा नहीं गया और उसका दावा नहीं किया गया है। 10.0 पर `S:C` अंकगणित के साथ मुद्रित है और अस्वीकृत है; `AV:A` 8.8 प्रबंधन-VLAN आइसोलेशन के लिए लेबल किया गया सशर्त है; एक डिवाइस-पहचान-अज्ञात चेतावनी सारांश में प्रमुखता से मुद्रित होती है और फ़ाइल-नाम और टेक्स्ट में दोहराई जाती है: इस निष्कर्ष के शीर्षक, स्लग या मुख्य भाग में कहीं भी "root" या "system" का दावा नहीं रखा गया है। विक्रेता की बंद की गई लाइन में फ़ैमिली-मॉडल अपलोड वंशावली को इस सलाहकार-श्रृंखला के घरेलू नियम के अनुसार, बिना किसी पहचानकर्ता के एक पैटर्न के रूप में वर्णित किया गया है। > - **निष्कर्ष 3** — `PR:L` पर **8.8**: शिप किया गया `netstat` बनाम डायग्नोस्टिक्स विशेषता विषमता वह आर्टिफ़ैक्ट है जो सिद्ध करता है कि कोई भी सामान्य सत्र इच्छित प्रिंसिपल वर्ग है; फ़ैक्टरी-डिफ़ॉल्ट अकाउंट युग्म को एक अलग निकटवर्ती कमज़ोरी के रूप में उसकी अपनी सशर्त `PR:N` 9.8 व्याख्या के साथ प्रकट किया गया है, कभी भी इस निष्कर्ष के वेक्टर के रूप में नहीं। 7.2 पर `PR:H` मुद्रित है और अस्वीकृत है। > - **निष्कर्ष 4-6** — तीनों **7.2**, `PR:H` पर, इस सुधार के साथ मुद्रित कि स्रोत रिकॉर्ड का 8.8 संशोधित 881-संबंध फ़ैमिली नियम के अंतर्गत `PR:L` अंकगणित है, जिसे साथ में अस्वीकृत-वेरिएंट अंकगणित के रूप में दिखाया गया है। तीन फ़ैक्टरी-डिफ़ॉल्ट क्रेडेंशियल सशर्तताएँ (प्रत्येक 9.8, यदि अपरिवर्तित) लेबल की गई हैं, कभी शीर्षक नहीं बनाई गईं, और `S:C` 9.1 तीनों के लिए मुद्रित है और अस्वीकृत है। तीनों में यह ईमानदार नकारात्मक परिणाम है कि scenario-ping सिंक में एक सेमीकोलन पेलोड विफल होता है और मूल्यांकन करने वाले थ्रेड को अवरुद्ध करता है, इसलिए कार्यशील रूप (`$(...)`, newline) परीक्षण के साथ मुद्रित होते हैं। > - **सत्यापन सीमा, एकरूपता से कथित** — इस बैच में प्रत्येक सैंडबॉक्स मार्कर `uid=0` उस रेप्लिकेशन एनवायरनमेंट का गुण है जिसका उपयोग इसे परीक्षण करने के लिए किया गया था, और जहाँ कोई शिप किया गया इमेज अपने स्वयं के वेब स्टैक को root के रूप में कॉन्फ़िगर करता है, वह इन-इमेज तथ्य है जो उसी प्रकार मुद्रित है। कोई भी निष्कर्ष मैट्रिक्स-दावा डिवाइस-साइड पहचान का नहीं करता, और इस बैच में कहीं भी कोई लाइव-डिवाइस दावा नहीं किया गया है: तीन निष्कर्षों का परीक्षण `sink-level replication on an isolated cloud-hosted sandbox` द्वारा किया गया, एक (Crystal Server) का अपने स्वयं के VM इमेज के भीतर एक एंड-टू-एंड HTTP श्रृंखला द्वारा, एक (PX3) का इमेज से इंस्ट्रक्शन-लेवल पर और सिंक के कमांड-लेवल रेप्लिकेशन द्वारा (कोई एंड टू एंड नहीं; RPC→cfgd→हार्डवेयर श्रृंखला एमुलेशन के अंतर्गत पूरी नहीं होगी), और एक (RAX120) का इंस्ट्रक्शन-लेवल रिक्वेस्ट-पाथ डिसअसेम्बली के साथ-साथ तीन परस्पर स्वतंत्र मार्करों और एक बिनाइन कंट्रोल के लिए native-gcc सिंक रेप्लिकेशन द्वारा। > - **Root और पहचान दावे, एक-एक करके सत्यापित**: प्रकाशित 9.8 (`निष्कर्ष 2`) स्पष्ट रूप से root या system का दावा नहीं करता; प्रकाशित `निष्कर्ष 4-6` स्लग के दावे "shell-injected into the management stack" पर रुक जाते हैं, जिसमें रेप्लिकेशन सैंडबॉक्स पहचान को `uid=0` पंक्तियों के स्रोत के रूप में प्रकट किया गया है; RAX120 निष्कर्ष के स्लग और इनलाइन दावे ही बैच में एकमात्र हैं जो root शब्द रखते हैं, और इसके दोनों एंकर इन-इमेज lighttpd `User root` कॉन्फ़िगरेशन के साथ-साथ तीन शून्य-id मार्कर और एक कंट्रोल हैं, कभी कोई लाइव डिवाइस नहीं। **कुल योग**: 6 सलाहकार · 4 उत्पाद · 4 विक्रेता संगठन (NETGEAR, NUUO, Raritan/Legrand, Moxa), जिनमें MAR-2000 श्रृंखला उनमें से तीन को ले जाती है क्योंकि एक उत्पाद के योग्य निष्कर्षों को कभी भी बैचों में विभाजित नहीं किया जाता · 1 अनप्रमाणित श्रृंखला · 5 प्रमाणित श्रृंखलाएँ, जिनमें से चार स्पष्ट रूप से एडमिन-क्लास सत्र की आवश्यकता रखती हैं और एक किसी भी सामान्य सत्र की। एक एकल 6.8 प्रसिद्ध-ब्रांड स्लॉट की हेडलाइन रखता है, और यह जानबूझकर बैच की सबसे कम नाटकीय संख्या है: `AV` और `PR` दोनों उस स्तर तक गिर गए जो शिप किए गए आर्टिफैक्ट्स ने सिद्ध किया, न कि वह जो भोली-मॉडल टेम्पलेट सुझाता है, और प्रकाशित `Totals` यह स्पष्ट रूप से कहते हैं। छह में से चार कच्चे स्रोत रिकॉर्ड द्वारा सुझाए गए से कम से कम एक आंकड़ा प्रकाशित करते हैं — एक अन-प्रमाणित WAN पक्ष दो बार, एक गलत-दर्ज PR टियर चार बार — और उनमें से प्रत्येक डाउनग्रेड वहाँ मुद्रित है जहाँ पाठक उसे देखेगा, अस्वीकृत अंकगणित, वेक्टर, तर्क और सुधार इतिहास के साथ जीवित स्कोर के बगल में। **उपकरणों ने वास्तव में क्या दिखाया** — इसलिए कहा गया क्योंकि बैच की विश्वसनीयता ठीक इसी पर टिकी है: - **दो श्रृंखलाएँ शुरू से अंत तक, चार सिंक तक।** निष्कर्ष 2 ने विक्रेता की अपनी VM इमेज के विरुद्ध एक पूर्ण अनाम HTTP अनुरोध जोड़ी चलाई और लिखित पृष्ठ के निष्पादन की पुष्टि की; निष्कर्ष 3 के `diag` हैंडलर को जारी फर्मवेयर से निर्देश-स्तर पर सत्यापित किया गया, साथ ही तीन पेलोड आकारों के कमांड-स्तर इंजेक्शन के साथ एक बेनाइन नियंत्रण; निष्कर्ष 4-6 को फर्मवेयर-स्रोत विश्लेषण के साथ-साथ प्रत्येक सटीक सिंक निर्माण के native-gcc शेल प्रतिकृति द्वारा सत्यापित किया गया, जिसमें मार्कर और बेनाइन नियंत्रण शामिल थे; निष्कर्ष 1 को डिसअसेम्बली में अनुरोध-पथ पंक्ति पर सत्यापित किया गया और फिर तीन स्वतंत्र मार्करों के साथ-साथ एक बेनाइन नियंत्रण के लिए native-gcc सिंक प्रतिकृति द्वारा। किसी भी गैर-लाइव निष्कर्ष के लिए कोई एंड-टू-एंड दावा नहीं किया गया है, और प्रत्येक के लिए बैच की README पंक्ति स्पष्ट शब्दों में "disassembly" या "replication" कहती है। - **वैंटेज पॉइंट, एकरूपता से:** इस बैच के किसी भी निष्कर्ष में अनुरोध या निष्पादन कभी भी किसी अविश्वसनीय नेटवर्क सीमा को पार नहीं किया। जहाँ कोई निष्कर्ष प्रतिकृति वातावरण से व्यापक दायरा का दावा करता है, वह दावा एक शिप किए गए आर्टिफैक्ट पर टिका है — एक इन-इमेज बाइंडिंग या इन-इमेज वेब-स्टैक कॉन्फ़िगरेशन — और उन्हीं शब्दों में ऐसा कहता है। - **हमारे अपने हार्नेस ने क्या प्रदान किया** — क्योंकि हमारे द्वारा बनाई गई स्थिति उत्पाद का डिफ़ॉल्ट नहीं है: प्रतिकृति होस्ट वातावरण (सैंडबॉक्स खाता पहचान को होस्ट की संपत्ति के रूप में मापा गया, फिर निष्कर्षों के दावों में प्रतिबिंबित किया गया कि डिवाइस पक्ष पर क्या दावा नहीं किया गया है); वे बेनाइन नियंत्रण जो किसी निष्कर्ष को दुर्घटना से अलग करते हैं; एकल-उपयोग क्लोजर मार्कर (एक एकतरफ़ा विंडो) जहाँ कोई प्रवेश बिंदु पहले उपयोग के बाद बंद हो जाता है। *प्रत्येक पिछला बैच और उसके सलाहकार [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) के अंतर्गत सूचीबद्ध हैं।* *प्रत्येक पिछला बैच और उसके सलाहकार [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases) के अंतर्गत सूचीबद्ध हैं।* --- ## 🔁 एक चल रही श्रृंखला — साप्ताहिक प्रकटीकरण --- [Read more](https://github.com/exploit-garbage/0day-rubbish)
