Vercel 보안 침해 분석 — Context.ai OAuth 탈취로 배포 파이프라인까지 뚫렸다

들어가며

2026년 4월 19일, Vercel이 내부 시스템에 대한 무단 접근을 공식 확인했다. 단순 자격증명 탈취가 아니었다. 공격자는 Vercel 직원들이 쓰던 제3자 AI 도구를 통해 진입한 뒤, 환경 변수 → Linear·GitHub 통합 → 배포 파이프라인 순서로 접근 범위를 단계적으로 확장했다.

Vercel은 이 공격자를 "고도로 정교하다"고 평가했다. Vercel 시스템 구조를 사전에 파악하고 있었고, 각 단계의 실행 속도가 매우 빨랐다는 이유에서다. 현재 Mandiant를 투입해 조사 중이며, 법 집행기관에도 신고됐다.

공격 체인: Context.ai에서 배포 파이프라인까지

공격의 출발점은 Vercel의 코드나 인프라가 아니라, 직원들이 사용하던 AI 도구였다.

flowchart TD
    A["Context.ai\n(AI 에이전트 플랫폼)"] -->|"Google Workspace OAuth 앱 침해"| B["Vercel 직원\nGoogle Workspace 계정 장악"]
    B -->|"내부 시스템 접근"| C["비민감 환경 변수 열거\n(API 키 · RPC 엔드포인트)"]
    C -->|"권한 확장"| D["Linear · GitHub 통합 침투"]
    D -->|"탈취"| E["NPM 토큰 · GitHub 토큰\n빌드 파이프라인 접근"]

Context.ai는 기업 워크플로우를 위한 AI 에이전트 플랫폼이다. Google Workspace OAuth 앱을 통해 직원 계정에 접근 권한을 갖는 구조로 운영된다. 공격자는 이 플랫폼 자체를 침해해 Vercel 직원의 Google Workspace 계정을 장악했다. 이후 해당 계정에서 Vercel 내부 환경으로 이동하며 "민감하지 않음(non-sensitive)"으로 분류된 환경 변수를 열거했고, 거기서 획득한 정보를 발판으로 Linear와 GitHub 통합 시스템까지 침투해 배포 파이프라인 레벨의 자격증명을 탈취했다.

Vercel 측 분석에 따르면 이 침해는 Context.ai 하나에 국한된 공격이 아니었다. 같은 OAuth 앱을 통해 수백 개 조직, 수백 명의 사용자가 동시에 위험에 노출됐다.

OAuth 공급망 공격이 위험한 이유

이번 공격 경로가 위험한 이유는 기존 공급망 공격과 근본적으로 다른 진입점을 사용했기 때문이다.

기존 공급망 공격의 진입점은 npm 패키지, GitHub Actions 워크플로우, CI/CD 스크립트였다. 개발자가 직접 코드를 검토하거나 버전을 고정할 수 있는 지점이었다. 반면 이번엔 "생산성 도구"로 무비판적으로 도입된 AI 서비스가 진입점이 됐다. 대부분의 조직에서 AI 도구는 보안 검토 없이 "일단 써보자"는 분위기로 도입되는 경우가 많다.

Google Workspace OAuth 앱은 한 번 승인하면 해당 계정의 이메일, 캘린더, 드라이브, 도구별 토큰에 광범위하게 접근할 수 있다. 이 권한이 제3자 서비스의 서버에 저장된다는 것 자체가 위험 표면이다. Context.ai 서버가 침해되는 순간, 해당 앱에 권한을 부여한 모든 조직의 계정이 동시에 공격자의 손에 들어간다.

유출된 것과 보호된 것

Vercel은 "민감(sensitive)" 분류 환경 변수에는 접근이 없었다고 밝혔다.

BreachForums에서 ShinyHunters를 사칭한 위협 행위자가 $200만(BTC 기준 $50만부터 협상 가능)에 데이터를 판매 중이라고 주장했다. 단, 실제 ShinyHunters 그룹은 BleepingComputer에 "이 사건과 관련 없다"고 부인했다. 모방범이거나 느슨하게 제휴된 개인일 가능성이 높다.

Vercel의 공식 대응

침해를 인지한 즉시 Vercel은 다음과 같이 대응했다.

CEO Guillermo Rauch는 UTC 기준 2026년 4월 20일 04

암호화폐·Web3 프로젝트에 미치는 영향

Vercel을 배포 플랫폼으로 사용하는 Web3 프로젝트는 이번 침해의 잠재적 피해 범위 안에 있다.

지갑, DEX 프론트엔드, DeFi 대시보드를 Vercel에 호스팅하는 경우, 배포 파이프라인이 손상됐을 때 사용자가 정상 도메인에서 악의적으로 변조된 코드를 내려받는 시나리오가 가능하다. DNS 수준의 공격과 달리 호스팅 레이어 침해는 도메인이 그대로 유지되기 때문에 사용자가 눈치채기 어렵다.

"민감하지 않음"으로 분류된 환경 변수에 API 키, 프라이빗 RPC 엔드포인트, 지갑 관련 시크릿을 보관하는 프로젝트는 즉시 점검이 필요하다. 블록체인과 스마트 컨트랙트 자체는 이번 침해에 영향을 받지 않는다.

지금 당장 해야 할 조치

영향 여부가 불확실하다면 다음 순서로 점검한다.

1. 활동 로그 검토: 4월 17~19일 구간의 Vercel 계정 접근 로그를 확인한다.
2. 자격증명 전면 교체: 모든 환경 변수, NPM 토큰, GitHub 토큰, API 키를 새로 발급한다.
3. 민감도 재분류: "민감하지 않음"으로 표시된 변수를 재검토한다. API 키나 RPC 엔드포인트가 포함돼 있다면 즉시 "민감"으로 올린다.
4. 최근 배포 이력 점검: 의도하지 않은 코드 변경이 배포됐는지 확인한다.
5. Deployment Protection 설정 확인: 프로덕션 배포에 대한 접근 제어가 적절히 설정돼 있는지 확인한다.
6. 제3자 도구 전수 점검: CI/CD 파이프라인과 Google Workspace에 OAuth 권한을 가진 모든 제3자 앱을 목록화하고, 미사용 앱은 즉시 권한을 해제한다.

AI 도구 공급망의 새로운 현실

이번 사건이 보여주는 핵심은 단순하다. 정교한 공격자는 당신의 코드를 공격하지 않는다. 당신이 신뢰하는 도구를 공격한다.

AI 서비스 도입 속도가 보안 검토 속도를 앞질렀다. 많은 조직에서 AI 도구는 "일단 써보자"는 방식으로 도입되고, Google Workspace OAuth 승인은 클릭 몇 번으로 끝난다. 한번 부여된 OAuth 권한은 해당 서비스가 살아있는 한 유효하다. 그 서비스가 침해되면 권한도 같이 넘어간다.

조직이 갖춰야 할 최소한의 방어선은 다음과 같다.

• AI 도구 도입 전 OAuth 요청 권한 목록을 명시적으로 검토한다.
• 승인된 Google Workspace OAuth 앱을 주기적으로 감사하고 미사용 앱은 해제한다.
• 공급망 사고에 대비한 환경 변수 교체 절차를 미리 수립해둔다.

Vercel의 IPO 일정이 예정돼 있던 시점에 발생한 이번 침해는, AI 도구 공급망 보안이 더 이상 선택 사항이 아니라는 점을 업계 전반에 각인시켰다.

참고자료

• Vercel April 2026 security incident — Vercel Knowledge Base
• Vercel confirms breach as hackers claim to be selling stolen data — BleepingComputer
• Cloud Dev platform breach tied to compromised AI tool — Cryptopolitan
• Vercel Security Breach Raises Concerns for Crypto Projects — BeInCrypto
• Vercel confirms security incident as hackers claim to sell internal access — CyberInsider
• Vercel April 2026 security incident — Hacker News