3 सितंबर 2026 को जमा सुरक्षा शोध में HookPry ने पहले सुरक्षित दिखने वाले AI एजेंट प्लगइन के बाद के अपडेट में जीवनचक्र हुक बदलकर मेजबान पर अनधिकृत आदेश चलाए। मूल arXiv प्रीप्रिंट के अनुसार, 1,000 आरंभ-से-अंत प्रयोगों में सभी सात जाँचे गए एजेंट ढाँचे कम-से-कम एक बार प्रभावित हुए और किसी एक ढाँचे की सफलता दर 92.5% तक पहुँची।
4 सितंबर को प्रकाशित ArXivSignals के शोध-सार में भी इसी आपूर्ति-श्रृंखला रास्ते और सात प्रभावित ढाँचों का उल्लेख है। मुख्य जोखिम यह है कि दुर्भावनापूर्ण आदेश मॉडल से चुनवाना जरूरी नहीं: सत्र शुरू होने, औजार बुलाए जाने या फाइल बदलने जैसी घटना पर एजेंट ढाँचा पंजीकृत हुक को मॉडल के निर्णय-पथ से बाहर चला सकता है।
सुरक्षित स्थापना के बाद अपडेट ने निष्पादन अधिकार बदले
HookPry का हमला चार कड़ियों में आगे बढ़ता है: सामान्य काम करने वाले प्लगइन की खोज, उसके सुरक्षित संस्करण की स्थापना, उसी पहचान के अंतर्गत बदला हुआ अपडेट और किसी उपयुक्त घटना पर नए हुक का निष्पादन। प्लगइन का नाम तथा सार्वजनिक पहचान स्थिर रह सकते हैं, जबकि अपडेट उसके विन्यास में नया शेल आदेश जोड़ देता है या पुराना आदेश बदल देता है।
शोध के खतरा-मॉडल में हमलावर प्लगइन की मेटाडेटा, संस्करण और जीवनचक्र-हुक विन्यास नियंत्रित करता है। उसके पास उपयोगकर्ता की मशीन या भंडार की पहले से पहुँच नहीं होती; वह स्थापना के लिए मजबूर नहीं कर सकता, घटना स्वयं नहीं चला सकता और सैंडबॉक्स से निकलने की खामी पर निर्भर नहीं है। प्रभाव तभी बनता है जब उपयोगकर्ता अपडेट अपनाए, संबंधित घटना घटे और हुक प्रक्रिया को पर्याप्त अधिकार मिले।
इसी सीमा में शीर्षक का “भरोसेमंद अपडेट” उस अपडेट रास्ते को दर्शाता है जिसे पहले स्वीकृत प्लगइन पहचान के कारण दोबारा पर्याप्त जाँच नहीं मिलती। शोध हर प्लगइन अपडेट को दुर्भावनापूर्ण नहीं बताता; वह दिखाता है कि पुरानी स्वीकृति को बदले हुए हुक-अधिकारों की स्वीकृति मानना खतरनाक हो सकता है।
सातों ढाँचे प्रयोग में प्रभावित हुए, हर स्थापना नहीं
शोधकर्ताओं ने सात एजेंट ढाँचों और पाँच LLM पृष्ठभागों के 25 संयोजनों में दस हमलावर उद्देश्यों का परीक्षण किया। कुल प्रयोगों में 77% ने बाहरी सत्यापन से पुष्ट प्रभाव पैदा किया; सर्वोच्च प्रति-ढाँचा दर Hermes में 92.5% रही। उद्देश्यों में प्रमाण-पत्र जुटाना, डेटा बाहर भेजना, संगणना संसाधन हथियाना, स्रोत फाइल बदलना, स्थायित्व बनाना और अधिकार बढ़ाना शामिल थे।
यह मॉडल की सामान्य उत्तर-निर्माण विफलता नहीं थी। मॉडल कभी घटना पैदा करने वाली गतिविधि में शामिल हो सकता है, लेकिन घटना मिलने के बाद पंजीकृत आदेश को जोड़ने और उप-प्रक्रिया शुरू करने का निर्णय ढाँचे का होता है। इसलिए प्रॉम्प्ट छनाई, मॉडल का इनकार या मॉडल द्वारा चुने गए औजारों की पुष्टि उस आदेश को नहीं रोकती जिसे मॉडल ने देखा या चुना ही नहीं।
“सातों ढाँचे टूटे” का अर्थ केवल जाँचे गए विन्यासों में कम-से-कम एक सत्यापित समझौता है। प्रयोग अस्थायी परिवेश और कृत्रिम फाइलों पर हुए; उन्होंने सभी प्रचालन तंत्रों, शेल, नेटवर्क स्थितियों, उद्यम नीतियों या भावी संस्करणों को नहीं परखा। अध्ययन यह भी नहीं मापता कि वास्तविक उपयोगकर्ता दुर्भावनापूर्ण प्लगइन या उसका अपडेट कितनी बार अपनाएँगे।
स्थिर स्कैन ने लगभग आधी दुर्भावनापूर्ण सामग्री छोड़ दी
रक्षा-जाँच में 40 दुर्भावनापूर्ण और 40 सामान्य कृत्रिम कलाकृतियाँ थीं। Microsoft Defender ने 40 में से किसी दुर्भावनापूर्ण नमूने को नहीं पहचाना; HookPolicy ने 20 और पाँच नियमों वाले Semgrep विन्यास ने 19 पकड़े। तीनों के संयुक्त परिणाम में भी 19 दुर्भावनापूर्ण कलाकृतियाँ छूट गईं, यानी चूक दर 47.5% रही।
AI Polix के 6 सितंबर के तकनीकी आकलन ने स्पष्ट किया कि ये आँकड़े लेखकों द्वारा बताए गए हैं और उनका स्वतंत्र पुनरुत्पादन अभी उपलब्ध नहीं है। जाँच में गतिशील विश्लेषण या विशेष वाणिज्यिक आपूर्ति-श्रृंखला सुरक्षा उत्पाद भी शामिल नहीं थे, इसलिए परिणाम को हर अंत-बिंदु सुरक्षा साधन पर सार्वभौमिक फैसला नहीं माना जा सकता।
फिर भी प्रयोग स्थिर स्कैनिंग की संरचनात्मक सीमा दिखाता है। जीवनचक्र हुक परीक्षण, प्रारूपण या फाइल-जाँच जैसे वैध आदेश भी चलाते हैं; केवल आदेश मौजूद होना हमेशा दुर्भावना सिद्ध नहीं करता। इसीलिए किसी पैकेज को स्कैन में साफ पाना उसे व्यापक निष्पादन अधिकार देने के बराबर सुरक्षा निर्णय नहीं है।
अपडेट नीति को हुक-अधिकार तक बाँधना होगा
विकास और सुरक्षा दलों के लिए व्यावहारिक निष्कर्ष है कि हुक विन्यास को साधारण मेटाडेटा नहीं, निष्पादन योग्य सामग्री माना जाए। निम्न जाँचें शोध के खतरा-मॉडल को वास्तविक प्लगइन कार्यप्रवाह के नियंत्रण में बदलती हैं:
संस्करण और अखंडता स्थिर करें: उत्पादन में स्वीकृत संस्करण या क्रिप्टोग्राफिक हैश बाँधें। नया संस्करण पहले पृथक परिवेश में जाँचें और सुरक्षा सुधार रोकने से बचने के लिए पिन किए गए संस्करण की नियमित समीक्षा रखें।
हुक-अंतर दिखाएँ: पुराने और नए संस्करण के घटना नाम, आदेश, स्क्रिप्ट पथ, पर्यावरण चर, नेटवर्क गंतव्य और स्थापना-पश्चात क्रियाओं का अर्थपूर्ण अंतर निकालें। नया हुक या बढ़ा अधिकार अलग पुनः स्वीकृति माँगे।
न्यूनतम अधिकार दें: हुक प्रक्रिया से स्थायी प्रमाण-पत्र, अनावश्यक परियोजना निर्देशिकाएँ और व्यापक नेटवर्क पहुँच हटाएँ। लिखने योग्य क्षेत्र तथा बाहर जाने वाले संपर्क वास्तविक जरूरत तक सीमित रखें।
अलग रनर इस्तेमाल करें: हुक को डेवलपर की मुख्य पहचान के बजाय पृथक कंटेनर, आभासी मशीन या कम-अधिकार सेवा खाते में चलाएँ। उत्पादन रहस्य और संवेदनशील भंडार वहाँ अपने-आप उपलब्ध न हों।
निष्पादन का लेखा रखें: प्लगइन संस्करण, विन्यास हैश, घटना, चला हुआ प्रोग्राम, प्रक्रिया की पहचान और नेटवर्क गतिविधि दर्ज करें। जाँच केवल मॉडल की बातचीत पर निर्भर नहीं रहनी चाहिए।
अभी यह शोध परिणाम है, व्यापक हमला-अभियान नहीं
उपलब्ध साक्ष्य HookPry को नियंत्रित प्रयोगों में सफल हमला-ढाँचा सिद्ध करते हैं, वास्तविक दुनिया में बड़े पैमाने पर चल रहा अभियान नहीं। लेखकों ने प्रभावित ढाँचा-विक्रेताओं को निष्कर्ष भेजने और उत्तर की प्रतीक्षा करने की बात कही है; सार्वजनिक सामग्री में किसी व्यापक शोषण या सभी विक्रेताओं द्वारा सुधार जारी करने की पुष्टि नहीं है।
अगला निर्णायक संकेत स्वतंत्र पुनरुत्पादन और विक्रेता-स्तरीय बदलाव होंगे: क्या बदले हुक को अलग अनुमति मिलेगी, क्या प्लगइन हस्ताक्षर वास्तविक विन्यास से बाँधा जाएगा और क्या हुक कम-अधिकार पृथक प्रक्रिया में चलेगा। तब तक प्रॉम्प्ट सुरक्षा को पूर्ण सीमा मानना इस हमला-पथ के उस हिस्से को अनदेखा करता है जहाँ आदेश का चयन मॉडल नहीं, जीवनचक्र विन्यास करता है।
