एक AI सुरक्षा एजेंट ने Snowflake में सेंध लगाई। Copilot वाली कहानी शोर थी

जून में एक AI एजेंट Snowflake के आंतरिक Jira तक पहुँच गया, और लगभग हर जगह जिस हिस्से को मुख्य कहानी बनाया गया वह गलत हिस्सा था। कहानी के पहले संस्करण में कहा गया कि असुरक्षित कोड GitHub Copilot ने लिखा था, AI द्वारा AI को विषाक्त करने की सुविधाजनक कथा। वह संस्करण कुछ घंटों ही चला। Wiz ने उसी दिन अपना खुलासा सुधारा, GitHub लेखक वाली बात से साफ़ असहमत है, और सुधार के बाद जो बचता है वह अधिक अजीब और अधिक उपयोगी है: एक स्वायत्त एजेंट ने जीवित खामी खोजी, उसका शोषण लिखा, अपनी विफल पेलोड को खुद डीबग किया और काम करने वाले क्रेडेंशियल निकाल लिए, शुरू से अंत तक, जबकि उसी कोड पर पारंपरिक स्कैनर कुछ नहीं देख पाए। आपका समय इसी कहानी पर लगना चाहिए।

मुख्य बातें - Wiz के Red Agent, एक स्वायत्त आक्रामक सुरक्षा एजेंट, ने Snowflake की सार्वजनिक snowflake-connector-net रिपॉजिटरी के GitHub Actions कार्यप्रवाह में स्क्रिप्ट इंजेक्शन खोजा और Jira टोकन चुराने के लिए उसका शोषण किया। खोज से क्रेडेंशियल बाहर निकालने तक किसी मानव ने कीबोर्ड नहीं छुआ। - खामी 18 जून 2026 को लाइव हुई और 23 जून को Snowflake के HackerOne कार्यक्रम के जरिए खोजी, शोषित और रिपोर्ट की गई। Snowflake ने उसी दिन पैच किया और उसके ऑडिट लॉग दिखाते हैं कि उस अवधि में Wiz अकेला अभिनेता था। - शुरुआती दावा कि Copilot ने बग लिखा था कुछ घंटों में वापस ले लिया गया। असुरक्षित पैटर्न मानव-लिखित बदलाव में था; Copilot Autofix का दस्तावेज़ित योगदान दूसरी फ़ाइल में था, और सह-लेखक लेबल स्क्वैश-मर्ज का परिणाम था। - GitHub Advanced Security ने उसी असुरक्षित संशोधन को स्कैन किया और चूक गया। पैटर्न-मिलान स्कैनर ने वही कोड देखा जिस पर एजेंट ने तर्क किया, और उनमें से केवल एक ने उसे समझा। - वास्तव में एजेंटिक हिस्सा संकीर्ण लेकिन वास्तविक था: विफल शोषण का निदान और उसे फिर लिखना। बाकी भाषा मॉडल के भीतर अच्छा स्वचालन था।

क्या हुआ

समयरेखा, पूरी तरह Wiz के खुलासे और उस पर Snowflake की प्रतिक्रिया से:

• 18 जून 2026। PR #1218 को Snowflake की सार्वजनिक .NET कनेक्टर रिपॉजिटरी snowflakedb/snowflake-connector-net में मर्ज किया गया। यह jira_issue.yml नाम का कार्यप्रवाह फिर लिखता है, जो किसी के GitHub मुद्दा खोलने पर अपने-आप Jira टिकट बनाता है। नया संस्करण सुरक्षित पैटर्न, यानी मुद्दे के शीर्षक को परिवेश चर से jq --arg में देना, हटाकर शीर्षक को सीधे शेल run: ब्लॉक में जोड़ देता है।

• 23 जून। Snowflake के HackerOne बग बाउंटी कार्यक्रम के तहत GitHub संगठन स्कैन करते समय Wiz का स्वायत्त सुरक्षा शोध एजेंट Red Agent कार्यप्रवाह को इंजेक्ट किए जा सकने योग्य चिन्हित करता है। वह शोषण बनाता है, चलाता है, अपनी पेलोड में शेल सिंटैक्स त्रुटि से टकराता है, त्रुटि का निदान करता है, पेलोड फिर लिखता है और दूसरी कोशिश में सफल हो जाता है। Azure-होस्टेड GitHub Actions रनर Wiz के लिसनर को सेवा खाते से जुड़ा base64-एन्कोडेड Jira API टोकन भेजता है। Wiz उसी दिन HackerOne से रिपोर्ट करता है।

• 23 जून, उसी दिन। Snowflake सुरक्षित पैटर्न वापस लाकर कार्यप्रवाह पैच करता है।

• 24 जून। Jira टोकन रद्द और घुमाया जाता है। Snowflake की ऑडिट-लॉग समीक्षा पाँच दिन की खुली अवधि में Wiz के अलावा किसी और की पहुँच नहीं पाती। Wiz कहता है उसने अवधारणा-प्रमाण का डेटा मिटा दिया।

• 17 अगस्त। Wiz Research में खतरा-अनावरण के प्रमुख Gal Nagli का लेख प्रकाशित होता है, और उसी दिन 19:57 UTC पर अपडेट करके स्पष्ट किया जाता है कि Copilot एक सह-लेखक था जिसने मर्ज किए PR को जाँचा और ठीक बताया था, और यह स्पष्ट नहीं कि असुरक्षित बदलाव में AI सहायता थी भी या नहीं।

टोकन Snowflake के आंतरिक Jira में पठन पहुँच रखता था: इंजीनियरिंग, सुरक्षा अनुपालन और बग बाउंटी कार्यक्रम स्वयं। किसी ग्राहक डेटा को नहीं छुआ गया, और जारी कनेक्टर कभी प्रभावित नहीं हुआ।

Wiz Research के खुलासे के अनुसार 23 जून 2026 को Wiz के स्वायत्त Red Agent ने Snowflake की snowflake-connector-net रिपॉजिटरी के GitHub Actions कार्यप्रवाह में स्क्रिप्ट इंजेक्शन खोजा और शोषित किया, जिससे इंजीनियरिंग, सुरक्षा अनुपालन और बग बाउंटी परियोजनाओं के पठन पहुँच वाला Jira टोकन बाहर निकला, खामी लाइव होने के पाँच दिन बाद और बिना मानव सहभागिता के। Snowflake ने उसी दिन पैच किया और अपने ऑडिट लॉग में किसी तीसरे पक्ष की पहुँच नहीं पाई।

अनुमति शृंखला, एक-एक कड़ी

यह शोषण इस बात का साफ़ पाठ है कि CI पाइपलाइन चुपचाप कितना भरोसा रखती है। देखिए कि एक गढ़ा हुआ मुद्दा-शीर्षक कहाँ तक पहुँच सका:

1. ट्रिगर। कार्यप्रवाह issues: opened पर चलता था, यानी दुनिया का कोई भी GitHub खाता मुद्दा खोलकर इसे चला सकता था। तकनीकी कवरेज के अनुसार पहुँच सीमित करने के लिए बनाई गई शर्तीय जाँच मुद्दा खुलने की घटनाओं पर हमेशा सत्य होती थी।

2. इंजेक्शन। नए कोड ने TITLE=$(echo '${{ github.event.issue.title }}' | sed ...) किया। GitHub शेल चलने से पहले ${{ }} टेम्पलेट फैलाता है, इसलिए sed एस्केपिंग बहुत देर से आती है। शीर्षक में एक एकल उद्धरण स्ट्रिंग बंद कर देता है और बाकी शीर्षक शेल के रूप में चलता है।

3. परिवेश। अब कमांड GitHub Actions रनर में चल रहे हैं, जो डिज़ाइन के अनुसार क्रेडेंशियल से भरी मशीन है। इसमें सेवा खाता का Jira API टोकन था, क्योंकि Jira टिकट बनाना ही कार्यप्रवाह का काम था।

4. बाहर निकालना। पेलोड ने टोकन को base64 में एन्कोड किया और बैंड से बाहर कॉलबैक से Wiz के लिसनर को भेज दिया, इसलिए कार्यप्रवाह लॉग में कुछ संदिग्ध दिखाई नहीं दिया।

5. इनाम। टोकन ने Snowflake के आंतरिक Atlassian परिवेश में इंजीनियरिंग, सुरक्षा अनुपालन और बग बाउंटी परियोजनाओं पर पठन पहुँच के साथ प्रमाणीकरण किया।

उस शृंखला की हर कड़ी सामान्य, मंजूर, उबाऊ आधारभूत संरचना है: सार्वजनिक रिपॉजिटरी, अपना काम करता कार्यप्रवाह, काम के लिए जरूरी अनुमति वाला सेवा खाता। भेद्यता कोई एक गलत कॉन्फ़िगरेशन नहीं थी; वह संयोजन था। कार्यप्रवाह का प्रभाव क्षेत्र वह सब है जहाँ उसका रनर पहुँच सकता है, और रनर अक्सर टीम की याद से कहीं अधिक जगह पहुँच सकते हैं। यही तर्क मैं ग्राहकों के एजेंट शासन सवाल में करता हूँ: सवाल यह नहीं कि एजेंट क्या है, बल्कि वह क्या छू सकता है।

शोषण ने वैध भरोसे की पाँच परतें जोड़ीं: बिना प्रमाणीकरण GitHub मुद्दा ने कार्यप्रवाह चलाया, एकल-उद्धरण इंजेक्शन शेल से बाहर निकली, रनर के परिवेश में Jira सेवा-खाता टोकन था, बैंड से बाहर कॉलबैक ने उसे बाहर भेजा, और टोकन ने Snowflake के आंतरिक Jira में पठन पहुँच खोली। Wiz के लेख के अनुसार GitHub टेम्पलेट विस्तार शेल एस्केपिंग से पहले होता है, इसीलिए स्वच्छीकरण देर से पहुँचा।

क्या एजेंटिक था और क्या नहीं

यहाँ सटीक रहना चाहता हूँ, क्योंकि "AI एजेंट ने Snowflake हैक किया" दो आलसी व्याख्याओं को आमंत्रित करता है: यह केवल बेहतर विपणन वाला स्कैनर था, या Skynet खुल गया है। विवरण के सामने दोनों टिकते नहीं।

अंदर मॉडल वाला सामान्य स्वचालन। स्कैनिंग और चिन्हित करना। Red Agent की CI/CD क्षमता GitHub संगठनों में ऐसी कार्यप्रवाह फ़ाइलें खोजती है जो अविश्वसनीय इनपुट को run: ब्लॉक में अंतःस्थापित करती हैं। यह अच्छी तरह समझी जाने वाली भेद्यता श्रेणी है जिसका रूप पहचाना जा सकता है, और jira_issue.yml को चिन्हित करना वह काम है जिसे अच्छी स्थिर नियम संभवतः कर सकती है। लक्ष्य चुनना, कार्यप्रवाह पढ़ना, उसे शोषण योग्य मानना: कुशल, लेकिन Wiz पहले से जो निरंतर आक्रमण-सतह प्रबंधन बेचता है उसके काफी करीब।

वास्तव में एजेंटिक। शोषण लूप। एजेंट की पहली पेलोड ने टिप्पणी वर्ण इस्तेमाल किया जिससे शेल सिंटैक्स टूट गया और प्रयास विफल हुआ। उसने आई bash त्रुटि पढ़ी, समझा कि पेलोड क्यों विकृत थी, उसे स्क्रिप्ट सही तरह बंद करने के लिए फिर लिखा, और दूसरी कोशिश में सफल हुआ। फिर उसने सत्यापित किया कि चुराया टोकन वास्तव में Snowflake के Jira पर काम करता है और आकलन किया कि वह कहाँ तक पहुँच सकता है। अपने ही हमले की नई रनटाइम विफलता का निदान करना और बिना प्रॉम्प्ट के अनुकूल होना हस्ताक्षर मिलान नहीं है। यही लूप, कोशिश, देखना, सुधारना, एजेंट को स्कैनर से अलग करता है, और यही लूप मैंने सामान्य रूप से एजेंटिक आर्किटेक्चर में लिखा है। इसे Fortune 500 लक्ष्य के खिलाफ, बिना निगरानी, आक्रामक रूप में चलते देखना ध्यान देने योग्य पहली घटना है।

एजेंट बिल्कुल नहीं। दायरा, नैतिकता और खुलासा। Red Agent Snowflake के HackerOne कार्यक्रम के भीतर चला, ऐसा सैंडबॉक्स जिसे Wiz के मानव ने चुना और अधिकृत किया। स्वायत्तता वास्तविक थी लेकिन सीमित, स्वीकृत और निगरानी में, और रक्षकों के लिए मैं ठीक यही बात रेखांकित करूँगा। Wiz ने मार्च में Red Agent लॉन्च किया और जुलाई के अंत में सामान्य उपलब्ध कराया, आंशिक रूप से Anthropic के Claude Opus पर बनाया गया। यह क्षमता अब ऐसा उत्पाद है जिसे कोई भी सुरक्षा टीम किराए पर ले सकती है, इसलिए इस लूप का आक्रामक संस्करण बहुत आम होने वाला है।

Wiz के खुलासे के अनुसार Red Agent की स्कैनिंग और प्राथमिक छँटाई मॉडल के भीतर स्वचालन थी; एजेंटिक केंद्र शोषण लूप था: पहली पेलोड शेल सिंटैक्स त्रुटि पर विफल हुई तो एजेंट ने bash विफलता का निदान किया, पेलोड फिर लिखी, दूसरी कोशिश में सफल हुआ, फिर टोकन सत्यापित किया और उसका प्रभाव क्षेत्र समझा, बिना मानव मदद के।

Copilot वाली पंक्ति सबसे कम दिलचस्प हिस्सा है

पहले शीर्षकों ने कहा Copilot ने बग लिखा। रिकॉर्ड कुछ और कहता है। PR #1218 में Copilot Autofix का दस्तावेज़ित योगदान अलग फ़ाइल jira_close.yml में दूसरा सुधार था। असुरक्षित अंतःस्थापन एक नामित Snowflake इंजीनियर के कमिट में था, और GitHub ने पत्रकारों को बताया कि उसकी आंतरिक समीक्षा में Copilot Autofix ने उन पंक्तियों को न लिखा, न समीक्षा की। मर्ज किए PR पर "Copilot द्वारा सह-लेखित" लेबल स्क्वैश मर्ज के साथ ट्रेलर खिंच आने का परिणाम था। Wiz ने उसी दिन पोस्ट सुधारी; The Register ने कहानी में सुधार किया। CSO से Wiz CTO Ami Luttwak की टिप्पणी ईमानदार निष्कर्ष है: जब हर PR पर कई एजेंट चलते हैं, तो "सिर्फ PR के सह-लेखकों को देखना पर्याप्त नहीं" यह तय करने के लिए कि किसने क्या लिखा।

दो बातें एक साथ सच हो सकती हैं। GitHub Advanced Security, जो Copilot Autofix इस्तेमाल करता है, ने उस PR का अंतिम संशोधन, असुरक्षित कार्यप्रवाह सहित, स्कैन किया और इंजेक्शन नहीं चिन्हित की; यह Wiz के विवरण में है और GitHub ने इसका खंडन नहीं किया। और यह खास दावा कि Copilot ने खामी लिखी, समर्थित नहीं है। AI-सहायित समीक्षा ने उस कोड में गंभीर बग छोड़ा जिसे उसने ठीक बताया। यह AI समीक्षा की सीमाओं पर वास्तविक कहानी है; बस AI द्वारा बग लिखने की कहानी नहीं है, और दोनों को मिलाना उन लोगों की कोई मदद नहीं करता जो तय कर रहे हैं कि अपने PR पर AI समीक्षा पर कितना भरोसा करें।

Wiz ने शुरू में संकेत दिया कि Copilot ने असुरक्षित कोड लिखने में मदद की, फिर उसी दिन स्पष्ट किया कि Copilot Autofix का दस्तावेज़ित योगदान उसी PR की दूसरी फ़ाइल में था और सह-लेखक लेबल स्क्वैश-मर्ज आर्टिफैक्ट था। GitHub कहता है कि दोषपूर्ण पुनर्गठन मानव इंजीनियर ने लिखा और Copilot ने उसकी समीक्षा कभी नहीं की। जिस पर विवाद नहीं: GitHub Advanced Security ने असुरक्षित संस्करण स्कैन किया और कुछ नहीं चिन्हित किया, Wiz की अपडेट पोस्ट और CSO की रिपोर्ट के अनुसार।

अभी क्या करें

यदि आप रहस्यों वाले GitHub Actions चलाते हैं, तो इस सप्ताह:

1. अपने कार्यप्रवाह में ${{ github.event.* }} को run: ब्लॉक के भीतर खोजें। मुद्दों के शीर्षक, PR शीर्षक, शाखा नाम या टिप्पणियों का पाठ शेल में अंतःस्थापित करना पूरी तरह इंजेक्ट किया जा सकता है। मान को env: चर में ले जाएँ और सही उद्धरण के साथ दें, या jq --arg से पार्स करें। Snowflake ने यही पैटर्न वापस लगाया।

2. अपने रनर को क्रेडेंशियल भंडार मानें। कार्यप्रवाह टोकन को न्यूनतम दायरे तक सीमित करें, लंबे समय वाले सेवा-खाता टोकनों के बजाय अल्पजीवी OIDC क्रेडेंशियल पसंद करें, और अविश्वसनीय घटनाओं, issues, pull_request_target, टिप्पणियों से ट्रिगर होने वाले कार्यप्रवाह को इंटरनेट-सामना करने वाला कोड मानें।

3. AI समीक्षा को अंतिम रक्षा पंक्ति न बनाएं। GitHub का अपना स्कैनर इसी कोड को देखकर पास कर गया। जाँच की परतें रखें, और ऐसे कार्यप्रवाह पर संदेह करें जहाँ समीक्षा, लेखन और स्कैनिंग सभी एक विक्रेता के मॉडल को सौंपे गए हों।

4. पाँच दिन की खिड़की को धीमा मानना शुरू करें। एजेंट इस रिपॉजिटरी के शून्य ज्ञान से एक सप्ताह से कम में काम करने वाले क्रेडेंशियल तक पहुँच गया। यदि आपकी प्रकटीकरण प्रक्रिया हमलावर के टिके रहने का समय महीनों में मानती है, तो धारणा बदलें, और क्रेडेंशियल रोटेशन रनबुक रखें जिसे Snowflake की तरह उसी दिन चला सकें।

अक्सर पूछे जाने वाले सवाल

क्या GitHub Copilot ने Snowflake की भेद्यता लिखी?

मौजूदा साक्ष्य पर नहीं। Copilot Autofix मर्ज किए PR में सह-लेखक था, लेकिन उसका दस्तावेज़ित बदलाव दूसरी फ़ाइल में था, लेबल स्क्वैश मर्ज का आर्टिफैक्ट था, और GitHub कहता है असुरक्षित कोड मानव इंजीनियर ने लिखा। जो सच है: GitHub Advanced Security ने असुरक्षित संस्करण स्कैन किया और इंजेक्शन चूक गया।

Wiz एजेंट Snowflake के Jira में कैसे पहुँचा?

उसने ऐसा कार्यप्रवाह पाया जो मुद्दों के शीर्षक को सीधे शेल स्क्रिप्ट में अंतःस्थापित करता था। गढ़े हुए शीर्षक वाला मुद्दा खोलने से रनर पर मनमाना कमांड चला, जहाँ Jira सेवा-खाता टोकन था। एजेंट ने बैंड से बाहर कॉलबैक से टोकन बाहर निकाला और आंतरिक Jira परियोजनाएँ पढ़ने के लिए इस्तेमाल किया। Snowflake ने रिपोर्ट वाले दिन कार्यप्रवाह पैच किया और अगले दिन टोकन घुमाया।

क्या यह वास्तविक हमला था?

यह अधिकृत हमला था। Red Agent Snowflake के HackerOne बग बाउंटी कार्यक्रम के तहत चला, Wiz ने तुरंत खुलासा किया, और Snowflake के ऑडिट लॉग ने पुष्टि की कि खामी लाइव रहने के पाँच दिनों में Wiz अकेला अभिनेता था। किसी ग्राहक डेटा तक पहुँच नहीं हुई। लेकिन यही तकनीक अनधिकृत एजेंट के लिए भी बिल्कुल उसी तरह काम करती है, और यही मुद्दा है।

AI सुरक्षा एजेंटों के लिए इसका क्या मतलब है?

आक्रामक एजेंट रक्षात्मक एजेंटों से आगे हैं। एक स्वायत्त एजेंट ने वास्तविक खामी जारी होने के कुछ दिनों में खोजी, शोषण की और उसका दायरा समझा, जबकि उसी कोड का स्वचालित स्कैनर कुछ नहीं देख पाया। रक्षकों को एजेंट-गति वाली खोज को नई आधाररेखा मानना चाहिए और यह मानना चाहिए कि इंटरनेट से ट्रिगर होने वाली हर चीज़ उसी गति से जाँची जाएगी।

निष्कर्ष

Copilot का नाटक हटाइए और दो तथ्य बचते हैं। एक पारंपरिक, महँगा सुरक्षा स्कैनर इस कोड की समीक्षा कर उसे ठीक बताकर निकल गया। एक स्वायत्त एजेंट ने वही कोड पढ़ा, हथियार बनाने जितना समझा, और रास्ते में अपनी गलतियाँ खुद सुधारीं। "मर्ज" से "मशीन द्वारा शोषण" तक पाँच दिन का अंतर वह संख्या है जिसे सुरक्षा टीमों को घूरना चाहिए, क्योंकि आक्रामक एजेंट अब शोध प्रदर्शन नहीं, उत्पाद हैं, और वे सप्ताहांत नहीं लेते। Copilot को श्रेय देने वाली पंक्ति अगले महीने तक भुला दी जाएगी। क्षमता नहीं।

यदि आप यह तय कर रहे हैं कि अपनी पाइपलाइनों में आक्रामक या रक्षात्मक एजेंटों को कितनी स्वायत्तता देनी है, तो यह वह बातचीत है जो मैं ग्राहकों के साथ नियमित रूप से करता हूँ। संपर्क करें।

स्रोत

• Wiz Research (Gal Nagli), "Wiz Red Agent ने GitHub Copilot-सहायित PR की खामी के जरिए Snowflake के आंतरिक Jira तक रास्ता खोजा": https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (प्रकाशित 2026-08-17, अपडेट 2026-08-17 19:57 UTC, देखा 2026-08-29)

• Wiz, "Wiz Red Agent का परिचय: AI-संचालित हमलावर": https://www.wiz.io/blog/introducing-the-wiz-red-agent (प्रकाशित 2026-03-23, देखा 2026-08-29)

• Cybersecurity News, "AI एजेंट ने Snowflake GitHub कार्यप्रवाह में सेंध लगाई": https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (प्रकाशित 2026-08-20, देखा 2026-08-29)

• CSO Online, "Snowflake की खामी AI जाँच से बच निकली, दूसरे AI ने उसका शोषण किया": https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (प्रकाशित 2026-08-19, देखा 2026-08-29)

• Infosecurity Magazine, "Wiz AI एजेंट ने Snowflake GitHub रिपॉजिटरी में गंभीर खामी खोजी": https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (प्रकाशित 2026-08-18, देखा 2026-08-29)

• daily.dev (The Next Web से), "GitHub ने Wiz के उस दावे को चुनौती दी कि Copilot Autofix ने Snowflake की खामी लिखी": https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (प्रकाशित 2026-08-18, देखा 2026-08-29)

• snowflakedb/snowflake-connector-net रिपॉजिटरी: https://github.com/snowflakedb/snowflake-connector-net (देखा 2026-08-29)