왜 Google Antigravity는 건축적 카드 하우스인가: 70개 이상의 취약점 및 대규모 차단
Source: Dev.to
보안 감사를 “불가능”하다고 부른 구글 이야기
2026년 2월 11일, 나는 **Google Antigravity IDE (v1.107.0)**에 대한 포괄적인 보안 감사를 Google VRP에 제출했다. 이 감사를 통해 70개 이상의 취약점이 발견되었으며, 이는 개발자의 머신을 누구에게든 열려 있는 문처럼 만든다.
구글의 반응? “수정이 불가능함.”
오늘날까지 이어지는 403 Forbidden 및 400 Bad Request 오류가 대량으로 발생하고 있다. 구글은 구조적 결함을 해결하기보다 “사용자를 고치기” 위해, 즉 차단함으로써 문제를 회피한 것으로 보인다.
성능 역설: RAM 욕심
- 메모리 누수 – 세션이 오래 실행될수록 RAM 사용량이 급증한다.
- 성능 저하 – 몇 시간 작업 후 성능이 크게 떨어져 자주 재시작해야 한다.
보안과 최적화가 “개발 속도”라는 명목 아래 희생된 듯하며, 결과적으로 빠르지도 안전하지도 않은 제품이 되었다.
기술 심층 분석: 보안 “체”
A. WMI를 통한 CSRF 토큰 유출 (마스터 키)
취약점
시스템의 어떤 프로세스든(관리자 권한이 없어도) 다른 프로세스의 명령줄을 읽을 수 있다.
공격
간단한 WMI 쿼리로 토큰을 즉시 확인한다:
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match "csrf_token" }영향
사용자가 코드를 한 줄도 입력하기 전에 인증 계층 전체가 손상된다.
B. ACL이 없는 네임드 파이프 (열린 문)
취약점
IDE가 생성하는 네임드 파이프에 접근 제어 목록(ACL)이 설정되지 않는다.
공격
WMI 유출을 통해 토큰을 입수한 뒤, 공격자는 파이프에 직접 연결해 확장 서버에 명령을 전송할 수 있다. 이는 IDE 인터페이스를 완전히 우회한다.
C. “왕관 보석” 탈취
- SSH 키 및 Git 설정
- 클라우드 토큰 – AWS, Azure, GCP 자격 증명
- 마스터 DPAPI 키와 Chrome 세션 쿠키
이러한 민감한 자산은 토큰에 접근한 로컬 프로세스라면 누구든지 수집할 수 있다.
“불가능”이라는 반응
“공격자가 이미 로컬 접근 권한을 가지고 있기 때문에 이를 보안 버그로 추적하지 않는다.”
2026년 현재 이 사고방식은 위험하다. 단일 악성 npm 또는 pip 패키지가 로컬 코드를 실행할 수 있는 공급망 공격 시대에 IDE는 놀이터가 아니라 요새여야 한다. IDE가 다른 로컬 프로세스로부터 자격 증명을 보호하지 못한다면 가장 기본적인 보안 역할을 실패한 것이다.
기술 부채에서 대량 차단까지
403 및 400 오류는 단순한 기술적 결함이 아니다; 이는 부실한 제품의 여파를 잠재우려는 기업의 소리다. 연구자와 파워 유저가 차단당하는 이유는, 주력 AI IDE가 구조적으로 결함이 있다는 사실을 인정하는 것보다 차단하는 것이 비용 효율적이기 때문이다.
결론: 계산 면역이 필요하다
최근 차단 물결에 영향을 받았거나 “로컬 접근” 보안 논쟁에 대한 의견이 있다면 댓글로 자유롭게 토론해 주세요.
전체 기술 보고서 및 PoC는 내 GitHub Gist에서 확인할 수 있다.