최고 등급의 위험이 해소되었습니다.
구글이 마침내 CVSS 10.0의 치명적인 취약점을 해결했습니다. 해당 취약점은 Gemini CLI 도구, 구체적으로 @google/gemini-cli npm 패키지와 google-github-actions/run-gemini-cli GitHub Actions 워크플로우에 영향을 미쳤습니다. 단순한 버그 수준이 아닙니다. 공격자가 에이전트 샌드박스가 초기화되기도 전에 호스트 시스템에서 임의의 명령을 직접 실행하여 보안 조치를 우회할 수 있는 경로가 열릴 수 있었던 겁니다. Novee Security가 이 문제를 처음 지적했는데, 권한이 없는 외부 공격자가 악성 콘텐츠를 Gemini 설정으로 로드하도록 유도하여 명령 실행을 트리거할 수 있다는 설명입니다. 이는 CLI 버전 0.39.1 및 0.40.0-preview.3 이전 버전과 GitHub Action 버전 0.1.22 이전에 영향을 미쳤습니다.
핵심 문제는 무엇이었을까요? 이전 버전에서는 CI 환경(헤드리스 모드라고 부릅니다)에서 실행되는 Gemini CLI가 작업 폴더를 자동 신뢰했습니다. 즉, 별도의 허락 없이 설정과 환경 변수를 로드했다는 뜻이죠. 이는 사용자 제출 풀 리퀘스트를 검토하는 CI 워크플로우 같은 시나리오에서 잠재적으로 재앙이 될 수 있었습니다. 만약 공격자가 신뢰할 수 없는 폴더에 특수하게 조작된 설정을 심어 놓는다면, CI/CD 파이프라인을 공급망 공격의 발판으로 악용할 수 있었습니다. 명시적인 맥락 없이 암묵적인 신뢰에 과도하게 의존한 전형적인 사례입니다.
구글의 이번 패치로 설정 파일을 읽기 전에 폴더를 명시적으로 신뢰해야 하도록 변경되었습니다. 사용자에게는 두 가지 경로를 제시하고 있습니다. 협업자로부터 신뢰할 수 있는 입력으로 워크플로우가 실행된다면 GEMINI_TRUST_WORKSPACE: 'true'를 설정하라고 합니다. 만약 신뢰할 수 없는 입력을 처리한다면, 구글의 워크플로우 강화 가이드라인을 따르고 환경 변수를 설정하도록 권장합니다. 또한 --yolo 모드에서 도구 허용 목록 검증을 강화하여, 프롬프트 인젝션을 통해 허용 목록을 우회하여 신뢰할 수 없는 입력이 코드 실행으로 이어지는 시나리오를 차단했습니다. 이 변경으로 인해 이전 동작에 의존했던 일부 워크플로우가 중단될 수 있으며, 도구 허용 목록 업데이트가 필요하게 될 수 있습니다.
Cursor의 코드 실행 난제
이뿐만이 아닙니다. Gemini CLI 취약점 공개와 함께 AI 기반 IDE인 Cursor에서도 높은 심각도의 취약점 소식이 전해졌습니다. 2.5 버전 이전(CVE-2026-26268, CVSS 8.1)에 Cursor는 .git 설정을 통한 샌드박스 탈출 문제를 겪었습니다. 이 취약점을 이용하면 악의적인 에이전트가 베어 리포지토리 내에 악성 Git 훅을 설정할 수 있었습니다. 해당 컨텍스트에서 커밋 작업이 이루어질 때마다 이 훅이 트리거되어 사용자 상호작용 없이 임의의 코드가 실행되었습니다. 공개된 리포지토리를 클론해서 Cursor에서 열고 ‘코드베이스 설명’을 요청했는데, AI 에이전트가 악성 Git 훅으로 자동 이동하면서 여러분의 기기가 감염되는 상황을 상상해보세요. 이는 AI 에이전트가 완전히 통제하지 못하는 리포지토리에서 Git 작업을 수행할 때 발생하는 근본적인 문제점을 시사합니다.
“근본 원인은 Cursor의 핵심 제품 로직에 있는 결함이 아니라, Git 기능 상호작용의 결과이며, AI 에이전트가 통제하지 못하는 리포지토리 내에서 Git 작업을 자동으로 실행하는 순간 악용될 수 있게 됩니다.”
개발자에게 왜 중요한가?
이 문제는 단순히 구글이나 Cursor만의 문제가 아닙니다. 개발 파이프라인에서 AI 지원 도구를 활용하는 모든 개발자와 조직에게 보내는 강력한 경고입니다. 이러한 도구들이 CI/CD와 같은 복잡한 워크플로우에 쉽게 통합되면서 새로운 공격 표면이 생성됩니다. 특히 외부 입력을 처리하는 자동화된 파이프라인에서 리포지토리 내용을 자동으로 신뢰하는 것은 곧 악용될 준비가 된 취약점입니다. AI 개발 도구 시장은 폭발적으로 성장하고 있으며, 이러한 도구들이 더 강력해지고 통합될수록 보안에 미치는 잠재적 영향력(긍정적, 부정적 모두)은 기하급수적으로 커집니다. 이곳의 혁신 속도는 보안 강화 속도를 종종 앞서며, 이러한 사고들은 고통스러운 추격전의 결과입니다.
역사적으로 npm이나 PyPI와 같은 패키지 관리자의 부상에서도 유사한 패턴을 보였습니다. 개발을 단순화하는 각 혁신은 보안 우선 접근 방식으로 관리되지 않으면 광범위한 침해의 잠재적 벡터를 도입합니다. Gemini CLI와 Cursor의 취약점은 이러한 지속적인 사이버 보안 과제의 최신 사례일 뿐입니다. 개발 프로세스에서 자동화와 AI 통합을 향한 움직임은 이러한 도구들이 기본 시스템 및 외부 데이터 소스와 어떻게 상호 작용하는지에 대한 경계심의 비례적인 증가를 요구합니다. 코드 실행이 관련된 한, 신뢰는 당연한 것이 아니라 얻어져야 합니다.
널리 사용되는 Gemini CLI와 같은 도구에서 CVSS 10.0의 취약점이 존재한다는 사실(특정 모드에 국한되더라도)은 우려스럽습니다. 특히 AI가 점점 더 적극적인 역할을 하는 상황에서 소프트웨어 공급망 보안을 위한 지속적인 노력을 강조합니다. 개발자는 자신의 환경 내에서 이러한 AI 에이전트에게 부여되는 권한과 신뢰 수준에 대해 극도로 주의해야 합니다. 이것은 새로운 보안 영역이며, 과거 취약점으로부터 배운 교훈이 그 어느 때보다 중요합니다.
🧬 관련 인사이트
- 더 보기: 영국 사이버 위원회, Associate Cyber Pro 타이틀 론칭 [기술 격차 해소?]
- 더 보기: [2026] 마이크로소프트 4월 패치 화요일: 167개 취약점, 제로데이 2건 수정
자주 묻는 질문
Gemini CLI 취약점을 통해 공격자는 무엇을 할 수 있나요?
공격자가 악성 설정 파일을 로드하도록 도구를 속여 샌드박스 보안을 우회하고 호스트 시스템에서 임의 명령을 실행할 수 있게 합니다.
Cursor 취약점은 어떻게 작동하나요?
Git의 기능 상호작용, 특히 리포지토리 내의 악성 Git 훅을 악용하여 AI 에이전트가 Git 작업을 수행할 때 코드 실행을 달성합니다.
헤드리스 모드에서 Gemini CLI를 사용하지 않으면 영향을 받나요?
구글에 따르면 Gemini CLI 취약점은 헤드리스 모드에서 도구를 사용하는 워크플로우에 국한됩니다. 하지만 항상 주의를 기울이는 것이 좋습니다.
