보안 회사 Wiz가 8월 17일 공개한 조사에 따르면, Snowflake의 공개 GitHub 저장소에 있던 CI/CD 워크플로 코드가 이슈 제목 하나로 내부 Jira 자격증명을 빼낼 수 있는 취약점을 갖고 있었다. GitHub의 자동 보안 스캔(Advanced Security)은 이 코드를 분석하고도 취약점을 잡아내지 못했고, 취약점이 살아있던 5일 사이 Wiz의 자율 보안 에이전트 "Red Agent"가 이를 찾아내 실제로 뚫었다. Wiz는 처음 이 사고를 "AI가 생성한 GitHub Copilot Autofix가 Snowflake의 Jira 침해를 허용했다"는 제목으로 발표했지만, 같은 날 저녁 The Hacker News의 커밋 기록 역추적과 GitHub의 반박을 거치며 그 핵심 주장은 수정됐다.
이슈 제목 하나가 셸 명령으로 바뀌는 워크플로였다
문제가 된 것은 snowflakedb/snowflake-connector-net 저장소의 jira_issue.yml 워크플로다. 이 파일은 누구나 이슈를 열면 실행되도록 설정돼 있었고, 이슈 제목을 그대로 셸 스크립트에 끼워 넣었다. 6월 18일 병합된 PR #1218은 기존에 있던 env: 변수와 jq --arg로 안전하게 값을 다루던 코드를 지우고, 대신 TITLE=$(echo '${{ github.event.issue.title }}' | sed ...) 형태로 GitHub의 값 치환 결과를 셸 문자열에 직접 넣는 코드로 바꿔놓았다. 이렇게 하면 이슈 제목에 홑따옴표 하나만 넣어도 echo '...' 문자열 밖으로 빠져나가 임의 명령을 실행할 수 있다.
보호 조건처럼 보였지만 사실은 항상 통과하는 게이트였다
이 워크플로에는 안전장치처럼 보이는 조건문도 있었다. if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')라는 조건인데, 이슈 이벤트에서는 github.event.pull_request가 항상 존재하지 않는(null) 값이다. GitHub는 존재하지 않는 속성을 참조하면 빈 문자열로 취급하기 때문에, 이 비교는 항상 참으로 평가되고 어떤 GitHub 계정으로 이슈를 열어도 게이트를 그대로 통과했다. GitHub는 이런 패턴의 위험성을 2025년 7월 문서로 이미 경고한 바 있다.
에이전트가 스스로 오류를 진단하고 공격을 고쳐 뚫었다
Wiz의 Red Agent는 자사가 운영하는 HackerOne 취약점 신고 프로그램을 통해 Snowflake의 GitHub 조직을 스캔하다가 이 워크플로를 발견했다. 처음 시도한 공격 페이로드는 주석 기호 #로 나머지 줄을 지우려 했는데, 이 기호가 TITLE=$(...)의 닫는 괄호까지 삼켜버려 셸 문법 오류가 났다. Red Agent는 여기서 멈추지 않고 오류를 스스로 분석해 ; echo '로 셸 구문을 다시 닫는 방식으로 페이로드를 고쳤고, 몇 초 뒤 자신이 준비한 외부 콜백 서버에서 base64로 인코딩된 Jira 자격증명을 실제로 받았다. 사람이 개입한 흔적은 없었다.
이 토큰으로 snowflakecomputing.atlassian.net에 로그인하면 Snowflake의 엔지니어링, 보안 컴플라이언스, 버그바운티 추적 프로젝트를 읽을 수 있었다.
Snowflake는 신고 당일 막았다
Wiz는 6월 23일 HackerOne으로 이 취약점을 신고했고(리포트 #3819931), Snowflake는 같은 날 PR #1402로 안전한 env:+jq --arg 패턴을 복원해 패치했다. 노출된 Jira 토큰은 다음 날인 6월 24일 회전됐다. Snowflake는 감사 로그를 분석해 노출 기간 5일 동안의 모든 이상 쿼리가 Wiz의 테스트 IP와 일치했으며 제3자의 무단 접근은 없었다고 밝혔다. Snowflake는 성명에서 "신고는 2026년 6월 23일 접수됐고 즉시 조사·정정됐으며, 조사 결과 무단 접근의 증거는 발견되지 않았다"고 말했다.
"AI가 취약점을 만들었다"는 주장, 하루도 못 가 흔들렸다
Wiz는 처음 공개한 글에서 이 취약점을 만든 코드 변경을 GitHub Copilot Autofix의 결과로 지목했다. 근거는 6월 18일 취약점을 병합한 스쿼시 커밋 4a1b8ce의 공동 작성자 목록에 "Copilot Autofix powered by AI"가 들어 있다는 점이었다. 그러나 The Hacker News가 이 커밋 아래의 개별 커밋들을 직접 확인한 결과, Copilot이 공동 서명한 커밋 6d0e2fa는 같은 PR 안의 다른 파일인 jira_close.yml을 고친 것이었고, 실제로 취약점을 만든 jira_issue.yml 리팩터링은 2025년 8월 25일에 올라온 별도 커밋 094038e였다. 이 커밋은 GitHub 기록상 Snowflake의 사람 엔지니어(sfc-gh-hpathak) 계정으로 작성됐다. 스쿼시 병합 과정에서 PR에 참여한 모든 커밋의 공동 작성자 표시가 하나로 합쳐지면서, 서로 다른 파일을 고친 서명이 한 커밋에 뒤섞인 것이다.
GitHub는 자체 검토 후 취약점을 만든 코드 변경에 Copilot Autofix가 관여하지 않았으며, 사람이 작성한 코드라고 반박했다. Wiz는 같은 날 19시 57분(UTC)에 원문을 수정해 "Copilot은 병합된 PR과 코드 변경을 검토하고 결정적 취약점을 알아채지 못한 채 문제 없음으로 표시한 공동 작성자였다. 코드 변경 자체가 AI의 도움을 받았는지는 불확실하다"고 고쳐 썼다. 이 정정을 처음 그대로 인용해 보도했던 The Register는 이후 제목을 "AI가 코드를 깼다"에서 "AI가 이를 잡아내지 못했다"로 바꾸고, 정정 사유를 기사 끝에 명시했다.
확실한 실패는 다른 곳에 있었다
누가 취약한 코드를 썼는지와 무관하게, 확인된 사실은 GitHub Advanced Security의 자동 스캔이 병합된 PR의 최종본과 문제가 된 워크플로를 분석했음에도 이 인젝션을 잡아내지 못했다는 점이다. 하커뉴스 댓글에서는 오픈소스 정적 분석 도구 zizmor의 관리자가 이 취약점 패턴을 자신의 도구가 잡아낼 수 있다고 확인했고, 다른 개발자는 GitHub Actions에서 존재하지 않는 이벤트 속성이 조용히 빈 문자열로 평가되는 동작 자체가 "스푸키 액션"이라며 비슷한 사고를 자신의 코드베이스에서도 겪었다고 밝혔다. AI가 취약한 코드를 직접 만들었는지는 논쟁거리로 남았지만, 코드 리뷰 도구가 이런 패턴을 잡아내야 한다는 점과, 자율 에이전트가 사람 없이 오류를 스스로 진단해 공격을 완성하는 데 며칠이면 충분하다는 점은 이번 사고에서 그대로 확인됐다.
출처: Wiz Research, "Red Agent Exploits Snowflake Vuln Missed by Github Copilot", 2026-08-17