यह अंतर सुरक्षा की दृष्टि से निर्णायक था। GitHub shell command चलने से पहले इस expression को expand करता है। इसलिए यदि कोई issue title single quote डालकर निर्धारित quoted string से बाहर निकल जाए, तो वह अपनी shell commands जोड़ सकता था। बाद में sed से value को sanitize करने की कोशिश इस जोखिम को नहीं रोक सकती थी, क्योंकि तब तक shell interpretation हो चुकी थी।

issues: opened trigger भी इस input को भरोसेमंद नहीं बनाता था। सार्वजनिक रिपॉजिटरी में issue खोल सकने वाला कोई भी उपयोगकर्ता title नियंत्रित कर सकता था। केवल issue activity तक सीमित event guard यह सुनिश्चित नहीं करता कि title सुरक्षित है; attacker-controlled data फिर भी shell interpolation तक पहुंच रहा था।

कमिट में “Copilot Autofix powered by AI” को co-author के रूप में श्रेय दिया गया था और AI-सहायता वाली समीक्षा ने समस्या को नहीं पकड़ा। हालांकि, उपलब्ध साक्ष्य यह तय नहीं करते कि Copilot ने असुरक्षित बदलाव खुद बनाया था या मानव द्वारा लिखे गए बदलाव की समीक्षा करते हुए vulnerability को मिस किया। इसलिए सटीक निष्कर्ष यह है कि Copilot इस बदलाव से जुड़ा था और injection को पहचान नहीं सका—यह नहीं कि model authorship निर्णायक रूप से सिद्ध हो गई है।

Red Agent ने खामी कैसे खोजी और exploit किया

Wiz का Red Agent offensive security के लिए बनाया गया autonomous AI agent है। इसने Snowflake के सार्वजनिक GitHub संगठन को scan करते हुए ऐसे CI/CD patterns खोजे जिनमें अविश्वसनीय input shell commands के भीतर जा रहा था। Agent ने पहचाना कि jira_issue.yml में public issue title को run: block तक पहुंचाया जा रहा है और विशेष रूप से तैयार किया गया title GitHub-hosted Actions runner पर arbitrary command execution करा सकता है।

23 जून 2026 को—vulnerable बदलाव merge होने के ठीक पांच दिन बाद—Red Agent ने Snowflake के HackerOne कार्यक्रम के अंतर्गत एक crafted issue खोला। उसके title ने shell string से बाहर निकलकर workflow को ऐसा command चलाने पर मजबूर किया, जो Jira credentials को proof of concept के लिए नियंत्रित out-of-band callback पर भेजता था।

यह किसी अनधिकृत हमलावर की घुसपैठ नहीं, बल्कि Snowflake की अनुमति के तहत किया गया sanctioned security test था। फिर भी तकनीकी finding वास्तविक थी: सार्वजनिक issue खोलना उस workflow step तक पहुंचने के लिए पर्याप्त था जो आंतरिक credentials संभाल रहा था, और इससे सामान्य issue creation command execution में बदल सकती थी।

किस तरह की पहुंच उजागर हुई

प्रभावित workflow के पास Snowflake के internal Jira configuration की जानकारी थी, जिसमें Jira URL, user email और API token शामिल थे। बरामद token qa@snowflake.net से जुड़ा था। Wiz ने इसका इस्तेमाल internal Jira portal में authenticate करने और संभावित exposure का आकलन करने के लिए किया।

रिपोर्टिंग के अनुसार इस token से engineering, security compliance और bug-bounty activity से जुड़े Jira projects में read access उपलब्ध थी। उपलब्ध साक्ष्य token की पूरी permission set, पहुंच सकने वाले हर record या देखे गए data की निश्चित सूची नहीं देते। इसलिए समर्थित निष्कर्ष इतना है कि token ने संवेदनशील internal Jira content तक पहुंच दी; Snowflake के authorization records के बिना इसे Snowflake के सभी systems तक unrestricted access कहना सही नहीं होगा।

महत्वपूर्ण बात यह है कि प्रभावित asset सार्वजनिक रिपॉजिटरी की CI/CD automation थी। किसी प्रभावित released Snowflake Connector for .NET version की सूचना नहीं दी गई, क्योंकि flaw connector के runtime code में नहीं बल्कि GitHub Actions workflow में था।

Snowflake ने क्या कदम उठाए

Wiz ने 23 जून को vulnerability report की। Snowflake ने उसी दिन workflow को remediate किया और अगले दिन exposed Jira credential rotate किया।

इसके बाद Snowflake ने audit logs की समीक्षा की और निष्कर्ष निकाला कि exposure window के दौरान Wiz ही एकमात्र actor था। Wiz ने भी कहा कि उसने proof-of-concept के दौरान हासिल किया गया data सुरक्षित रूप से delete कर दिया।

किसी unauthorized third-party access, CVE assignment या प्रभावित connector release की सूचना नहीं दी गई। ये तथ्य confirmed impact की सीमा बताते हैं, लेकिन मूल workflow design को सुरक्षित नहीं बनाते। सार्वजनिक issue title को ऐसे workflow में shell command का हिस्सा नहीं बनना चाहिए था, जो internal credentials संभालता हो।

CI/CD टीमों के लिए मुख्य सबक

यह घटना Snowflake और Copilot से आगे की समस्या दिखाती है। GitHub expressions—जैसे issue title, pull-request title, branch name और comment—जब भी shell command में प्रवेश करें, उन्हें hostile input मानना चाहिए।

सुरक्षित workflow design के लिए:

• Untrusted values को सीधे run: script में interpolate करने के बजाय environment variables के जरिए पास करें।
• Shell strings जोड़कर JSON बनाने के बजाय jq जैसे structured tools का उपयोग करें।
• Shell boundary पर उचित quoting और validation करें।
• जहां संभव हो, attacker-controlled content process करने वाले steps से credentials को अलग रखें।
• AI-generated security changes की समीक्षा उतनी ही सावधानी से करें जितनी किसी मानव द्वारा लिखे गए code की।

इस मामले में automation ने दोनों दिशाओं में गति दिखाई: एक AI-सहायता वाला coding workflow खतरनाक CI/CD बदलाव को नहीं पकड़ सका, जबकि दूसरा autonomous offensive agent उसे कुछ ही दिनों में खोजकर validate करने में सफल रहा। AI सुरक्षा समीक्षा और testing को तेज कर सकता है, लेकिन स्वतंत्र मानवीय समीक्षा का विकल्प नहीं है।

यह अंतर सुरक्षा की दृष्टि से निर्णायक था। GitHub shell command चलने से पहले इस expression को expand करता है। इसलिए यदि कोई issue title single quote डालकर निर्धारित quoted string से बाहर निकल जाए, तो वह अपनी shell commands जोड़ सकता था। बाद में sed से value को sanitize करने की कोशिश इस जोखिम को नहीं रोक सकती थी, क्योंकि तब तक shell interpretation हो चुकी थी।

issues: opened trigger भी इस input को भरोसेमंद नहीं बनाता था। सार्वजनिक रिपॉजिटरी में issue खोल सकने वाला कोई भी उपयोगकर्ता title नियंत्रित कर सकता था। केवल issue activity तक सीमित event guard यह सुनिश्चित नहीं करता कि title सुरक्षित है; attacker-controlled data फिर भी shell interpolation तक पहुंच रहा था।

कमिट में “Copilot Autofix powered by AI” को co-author के रूप में श्रेय दिया गया था और AI-सहायता वाली समीक्षा ने समस्या को नहीं पकड़ा। हालांकि, उपलब्ध साक्ष्य यह तय नहीं करते कि Copilot ने असुरक्षित बदलाव खुद बनाया था या मानव द्वारा लिखे गए बदलाव की समीक्षा करते हुए vulnerability को मिस किया। इसलिए सटीक निष्कर्ष यह है कि Copilot इस बदलाव से जुड़ा था और injection को पहचान नहीं सका—यह नहीं कि model authorship निर्णायक रूप से सिद्ध हो गई है।

Red Agent ने खामी कैसे खोजी और exploit किया

Wiz का Red Agent offensive security के लिए बनाया गया autonomous AI agent है। इसने Snowflake के सार्वजनिक GitHub संगठन को scan करते हुए ऐसे CI/CD patterns खोजे जिनमें अविश्वसनीय input shell commands के भीतर जा रहा था। Agent ने पहचाना कि jira_issue.yml में public issue title को run: block तक पहुंचाया जा रहा है और विशेष रूप से तैयार किया गया title GitHub-hosted Actions runner पर arbitrary command execution करा सकता है।

23 जून 2026 को—vulnerable बदलाव merge होने के ठीक पांच दिन बाद—Red Agent ने Snowflake के HackerOne कार्यक्रम के अंतर्गत एक crafted issue खोला। उसके title ने shell string से बाहर निकलकर workflow को ऐसा command चलाने पर मजबूर किया, जो Jira credentials को proof of concept के लिए नियंत्रित out-of-band callback पर भेजता था।

यह किसी अनधिकृत हमलावर की घुसपैठ नहीं, बल्कि Snowflake की अनुमति के तहत किया गया sanctioned security test था। फिर भी तकनीकी finding वास्तविक थी: सार्वजनिक issue खोलना उस workflow step तक पहुंचने के लिए पर्याप्त था जो आंतरिक credentials संभाल रहा था, और इससे सामान्य issue creation command execution में बदल सकती थी।

किस तरह की पहुंच उजागर हुई

प्रभावित workflow के पास Snowflake के internal Jira configuration की जानकारी थी, जिसमें Jira URL, user email और API token शामिल थे। बरामद token qa@snowflake.net से जुड़ा था। Wiz ने इसका इस्तेमाल internal Jira portal में authenticate करने और संभावित exposure का आकलन करने के लिए किया।

रिपोर्टिंग के अनुसार इस token से engineering, security compliance और bug-bounty activity से जुड़े Jira projects में read access उपलब्ध थी। उपलब्ध साक्ष्य token की पूरी permission set, पहुंच सकने वाले हर record या देखे गए data की निश्चित सूची नहीं देते। इसलिए समर्थित निष्कर्ष इतना है कि token ने संवेदनशील internal Jira content तक पहुंच दी; Snowflake के authorization records के बिना इसे Snowflake के सभी systems तक unrestricted access कहना सही नहीं होगा।

महत्वपूर्ण बात यह है कि प्रभावित asset सार्वजनिक रिपॉजिटरी की CI/CD automation थी। किसी प्रभावित released Snowflake Connector for .NET version की सूचना नहीं दी गई, क्योंकि flaw connector के runtime code में नहीं बल्कि GitHub Actions workflow में था।

Snowflake ने क्या कदम उठाए

Wiz ने 23 जून को vulnerability report की। Snowflake ने उसी दिन workflow को remediate किया और अगले दिन exposed Jira credential rotate किया।

इसके बाद Snowflake ने audit logs की समीक्षा की और निष्कर्ष निकाला कि exposure window के दौरान Wiz ही एकमात्र actor था। Wiz ने भी कहा कि उसने proof-of-concept के दौरान हासिल किया गया data सुरक्षित रूप से delete कर दिया।

किसी unauthorized third-party access, CVE assignment या प्रभावित connector release की सूचना नहीं दी गई। ये तथ्य confirmed impact की सीमा बताते हैं, लेकिन मूल workflow design को सुरक्षित नहीं बनाते। सार्वजनिक issue title को ऐसे workflow में shell command का हिस्सा नहीं बनना चाहिए था, जो internal credentials संभालता हो।

CI/CD टीमों के लिए मुख्य सबक

यह घटना Snowflake और Copilot से आगे की समस्या दिखाती है। GitHub expressions—जैसे issue title, pull-request title, branch name और comment—जब भी shell command में प्रवेश करें, उन्हें hostile input मानना चाहिए।

सुरक्षित workflow design के लिए:

• Untrusted values को सीधे run: script में interpolate करने के बजाय environment variables के जरिए पास करें।
• Shell strings जोड़कर JSON बनाने के बजाय jq जैसे structured tools का उपयोग करें।
• Shell boundary पर उचित quoting और validation करें।
• जहां संभव हो, attacker-controlled content process करने वाले steps से credentials को अलग रखें।
• AI-generated security changes की समीक्षा उतनी ही सावधानी से करें जितनी किसी मानव द्वारा लिखे गए code की।

इस मामले में automation ने दोनों दिशाओं में गति दिखाई: एक AI-सहायता वाला coding workflow खतरनाक CI/CD बदलाव को नहीं पकड़ सका, जबकि दूसरा autonomous offensive agent उसे कुछ ही दिनों में खोजकर validate करने में सफल रहा। AI सुरक्षा समीक्षा और testing को तेज कर सकता है, लेकिन स्वतंत्र मानवीय समीक्षा का विकल्प नहीं है।