Quasa
QUASA ऐप का उपयोग करें
आज ही Web3 क्रिप्टो फ्रीलांसिंग के अग्रणी मंच से जुड़ें!
खोलें
प्रौद्योगिकी

Kiro की पुरानी खामी अब सामने—दो क्रियाओं के बाद रहस्य बाहर जा सकते थे

|लेखक: QUASA संपादकीय टीम|5 मिनट पढ़ने का समय| 2
Kiro की पुरानी खामी अब सामने—दो क्रियाओं के बाद रहस्य बाहर जा सकते थे

Mindgard के 27 अगस्त 2026 के तकनीकी विवरण में Kiro IDE 0.7.45 पर एक पुराने डेटा-बहिर्गमन मार्ग का खुलासा हुआ: दुर्भावनापूर्ण कार्यक्षेत्र खोलने और एजेंट को संदेश भेजने के बाद परियोजना में छिपे निर्देश स्थानीय संवेदनशील जानकारी को बाहरी छोर तक पहुंचा सकते थे। शोधकर्ताओं ने Windows पर इसे विश्वसनीय और अविश्वसनीय, दोनों कार्यक्षेत्रों में पुनरुत्पादित किया था।

यह अगस्त में मिली नई, असुधारी शून्य-दिवसीय खामी नहीं है। The Hacker News की 27 अगस्त की रिपोर्ट में Amazon के प्रवक्ता के हवाले से बताया गया कि समस्या 15 जनवरी के Kiro IDE अद्यतन में दूर कर दी गई थी और सुधार 0.8.140 में शामिल था। अगस्त का समाचार पहले गोपनीय रखे गए तकनीकी रास्ते के सार्वजनिक होने का है, न कि उस समय नवीनतम संस्करण में उसके सक्रिय मिलने का।

खोज, सुधार और खुलासे की तारीखें अलग हैं

Kiro IDE खामी की दिसंबर खोज, जनवरी सुधार और 27 अगस्त सार्वजनिक खुलासे की अलग समयरेखा

इस मामले में तीन घटनाओं को अलग रखना जरूरी है। दूसरा बहिर्गमन मार्ग 11 दिसंबर 2025 को खोजा और सौंपा गया, 13 दिसंबर को HackerOne ने उसे Amazon तक पहुंचाया और शोध की समयरेखा में 26 जनवरी 2026 को सत्यापन तथा सुधार दर्ज है। सार्वजनिक तकनीकी विवरण 27 अगस्त को आया, जब सुधार को उपलब्ध हुए लगभग सात महीने बीत चुके थे।

सुधार की तारीख पर दोनों सार्वजनिक विवरणों की भाषा पूरी तरह समान नहीं है। शोध की समयरेखा 26 जनवरी को सुधार जारी होने की तारीख बताती है, जबकि Amazon का बयान 15 जनवरी के अद्यतन को समस्या दूर करने वाला संस्करण कहता है। दोनों इस केंद्रीय तथ्य पर सहमत हैं कि सुधार Kiro IDE 0.8.140 में था और अगस्त के सार्वजनिक खुलासे से काफी पहले उपलब्ध हो चुका था।

दो उपयोगकर्ता क्रियाओं से कड़ी कैसे शुरू होती थी

Kiro IDE में कार्यक्षेत्र खुलने और संदेश भेजने के बाद परीक्षण रहस्य का बाहरी अनुरोध में पहुंचना

हमला अपने आप केवल परियोजना डाउनलोड होने से शुरू नहीं होता था। उपयोगकर्ता को तैयार की गई .code-workspace फ़ाइल को “File → Open Workspace From File” विकल्प से खोलना पड़ता था; सामान्य फ़ोल्डर खोलना प्रदर्शित प्रक्रिया का हिस्सा नहीं था। इसके बाद Kiro एजेंट को कोई संदेश भेजना दूसरी आवश्यक क्रिया थी।

संदेश में दुर्भावनापूर्ण निर्देश लिखना या छिपी फ़ाइल का उल्लेख करना जरूरी नहीं था। परियोजना के भीतर .stuff निर्देशिका में रखी index.md फ़ाइल और उसके पथ का नाम एजेंट को निर्देश पढ़ने के लिए प्रभावित करते थे। इस तरह प्रॉम्प्ट इंजेक्शन उपयोगकर्ता के दिखाई देने वाले संदेश से नहीं, हमलावर के नियंत्रण वाली रिपॉज़िटरी सामग्री से आता था।

प्रमाण-अवधारणा में परियोजना की .env फ़ाइल के भीतर स्वच्छ OPENAI_API_KEY परीक्षण मान रखा गया था। छिपे निर्देश एजेंट से उस मान को पढ़ने, .code-workspace विन्यास में kiroAgent.powersRecommendationUrl के XXX स्थानधारक की जगह लिखने और Kiro Powers का विन्यास कार्य चलाने को कहते थे। IDE ने बदले हुए बाहरी URL को प्राप्त किया और परीक्षण मान अनुरोध की क्वेरी में दिखाई दिया।

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

अविश्वसनीय कार्यक्षेत्र ने प्रदर्शित रास्ता नहीं रोका

विश्वसनीयता की दोनों स्थितियों में समान व्यवहार मिलना इस खुलासे का महत्वपूर्ण हिस्सा है। केवल कार्यक्षेत्र को अविश्वसनीय चिह्नित करना उस समय इस कड़ी को रोकने के लिए पर्याप्त नहीं था, क्योंकि परियोजना सामग्री फिर भी एजेंट के निर्णय और Kiro Powers से जुड़े विन्यास को प्रभावित कर सकी।

इसका अर्थ यह नहीं कि प्रत्येक Kiro परियोजना जानकारी भेज सकती थी। हमलावर को विशेष कार्यक्षेत्र फ़ाइल, तैयार निर्देश, बदला जा सकने वाला URL और नियंत्रित बाहरी छोर वाली परियोजना बनानी पड़ती थी। उपयोगकर्ता की दोनों क्रियाएं भी आवश्यक थीं, लेकिन प्राप्त परियोजना खोलना और उसके बारे में एजेंट से बात करना विकास कार्यप्रवाह में असामान्य व्यवहार नहीं है।

सार्वजनिक प्रमाण में वास्तविक उपयोगकर्ता की चोरी हुई साख के बजाय स्वच्छ परीक्षण मान इस्तेमाल किया गया था। उपलब्ध विवरण बड़े पैमाने पर सक्रिय दुरुपयोग, मौजूदा 1.0.x निर्माण पर सफल बहिर्गमन या प्रत्येक प्रयास के सफल होने का प्रमाण नहीं देता। शीर्षक में “जा सकते थे” इसलिए संभावित और प्रदर्शित प्रभाव बताता है, निश्चित सार्वभौमिक परिणाम नहीं।

कौन-सा संस्करण सुरक्षित सीमा के आगे है

Kiro IDE 0.7.45, सुधरे 0.8.140 और नए 1.0.395 संस्करणों की जांच

इस विशेष रिपोर्ट के लिए सुधार सीमा Kiro IDE 0.8.140 है। स्थापित निर्माण इससे पुराना है तो वह बताए गए सुधार से पहले का संस्करण है; 0.8.140 या उससे नया निर्माण सुधार को शामिल करता है। केवल 0.x या 1.x जैसी मुख्य शाखा देखने के बजाय पूरा संस्करण क्रमांक जांचना जरूरी है।

Kiro की आधिकारिक डाउनलोड सूची 31 अगस्त 2026 को IDE 1.0.395 को नवीनतम निर्माण दिखाती है और 1.0.337 को भी पुराने उपलब्ध निर्माणों में दर्ज करती है। इस कारण 27 अगस्त की शुरुआती रिपोर्ट में नवीनतम कहा गया 1.0.337 अब वर्तमान निर्माण नहीं है; दोनों 1.0.x संस्करण फिर भी 0.8.140 की सुधार सीमा से आगे हैं।

फिलहाल क्या स्थापित तथ्य हैं

सार्वजनिक परीक्षण Kiro IDE 0.7.45 और Windows तक सीमित था। उसमें दुर्भावनापूर्ण कार्यक्षेत्र फ़ाइल खोलना तथा एजेंट को संदेश भेजना जरूरी था, और व्यवहार विश्वसनीय तथा अविश्वसनीय दोनों कार्यक्षेत्रों में दोहराया गया। सुधार 0.8.140 में शामिल किया गया था।

नवीनतम उपलब्ध शाखा उस सीमा से काफी आगे है और प्रकाशित शोध ने मौजूदा 1.0.x निर्माण पर उसी रास्ते के सफल होने का दावा नहीं किया। इसलिए 27 अगस्त का सही संदर्भ एक पुरानी, पहले सुधारी जा चुकी समस्या का तकनीकी खुलासा है; स्थिति तभी बदलेगी जब किसी नए निर्माण पर उसी या अलग बहिर्गमन मार्ग का स्वतंत्र तकनीकी प्रमाण सामने आए।

यह भी पढ़ें:

साझा करें:

हमारे न्यूज़लेटर की सदस्यता लें

Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।

0