Vercel 해킹 사건 — OAuth 공급망 공격으로 환경변수 '기본값 OFF'의 대가를 치르다

• Vercel이 2026년 4월 19일 OAuth 공급망 공격으로 내부 시스템이 뚫렸다고 공식 공개함 — CEO 기요르모 라우시(Guillermo Rauch)가 X에 상세 쓰레드로 인정
  • 공격 시작은 2026년 2월. Context.ai 직원 PC가 Lumma Stealer(인포스틸러) 감염 — 놀랍게도 Roblox 게임 익스플로잇 스크립트를 받다가 당함 (Hudson Rock, CyberScoop 보도)
  • Context.ai는 Vercel 직원이 승인했던 Google Workspace OAuth 앱. 이게 공격자에게 넘어가면서 Vercel 직원 Workspace 계정 → 내부 시스템 → 고객 환경변수 순으로 도미노식 타격
  • 공격자가 시스템에 머문 기간(dwell time) 약 2개월. 초기 보도에서는 22개월이라고 나갔다가 정정됨

핵심 설계 문제 — "sensitive" 플래그가 기본값 OFF

• Vercel 환경변수에는 sensitive 플래그가 있는데, 켜야만 저장 시 암호화되고 조회가 제한됨. 근데 기본값이 꺼져 있음
  • 즉 개발자가 DATABASE_URL, AWS_SECRET_ACCESS_KEY, STRIPE_SECRET_KEY 넣을 때 의식적으로 플래그 안 켜면 내부 접근 권한만 있어도 평문으로 보임
  • 보안 컨트롤을 "매 시크릿마다 수동 옵트인"으로 만들면 현실에선 아무도 안 쓴다는 걸 다시 증명한 케이스

OAuth가 기존 보안 방어선을 우회하는 이유

• OAuth 토큰은 한번 승인되면 비밀번호 없이도 계속 붙어 있음. 패스워드 로테이션에도 안 죽고, 스코프가 넓은 경우(메일·드라이브·캘린더 전부 접근)도 흔함
  • 초기 승인 후 주기적 감사 안 하는 게 업계 관행이라 공격자 입장에선 "신뢰 관계" 자체가 방어선을 피해가는 경로가 됨
  • 그래서 OAuth 거버넌스는 이제 IAM과 별개로 "서드파티 벤더 리스크 관리" 영역으로 다뤄야 한다는 주장

sequenceDiagram
    participant 공격자
    participant ContextAI as Context.ai 직원 PC
    participant GWS as Google Workspace
    participant Vercel직원 as Vercel 직원 계정
    participant Vercel내부 as Vercel 내부 시스템
    공격자->>ContextAI: Lumma Stealer 감염 (Roblox 스크립트 경유)
    ContextAI->>공격자: OAuth 토큰 + AWS 자격증명 탈취
    공격자->>GWS: Context.ai OAuth 앱으로 워크스페이스 접근
    GWS->>Vercel직원 as 이메일/드라이브/캘린더 열람
    공격자->>Vercel내부: SSO/수집 자격증명으로 내부 진입
    Vercel내부->>공격자: 비-sensitive 환경변수 열거 및 유출

탐지-공개 사이 9일 공백

• Vercel 고객 Andrey Zagoruiko가 4월 10일 OpenAI로부터 "API 키가 외부에 노출됐다"는 알림을 받음 — 그 키는 Vercel에만 존재하던 키였음
  • Vercel 공식 공개는 4월 19일. 즉 최소 9일 전부터 유출 증거가 외부에 존재
  • GDPR 72시간 고지 의무, SOC 2 지속 모니터링 관점에서 민감한 포인트. "Vercel은 언제 알았나"가 규제 이슈로 떠오름
• 이제 OpenAI·Anthropic·GitHub·AWS·Stripe가 보내는 "당신 키가 유출됐다" 알림은 플랫폼 침해의 조기 경보 채널로 취급해야 한다는 게 이번 사건의 교훈

CEO의 "AI 가속 공격" 주장

• 라우시가 공개적으로 "공격 그룹이 고도로 정교했고, AI로 크게 가속화된 것으로 강하게 의심한다"고 발언
  • 구체 근거는 "Vercel 내부 용어를 수동 정찰 없이 파악한 정황", "속도가 인간 페이스를 초과", "에러·레이트리밋 회복이 자연스러움"
  • Microsoft도 4월 발표에서 Storm-2372 후속 캠페인이 생성형 AI로 피싱 미끼·백엔드 자동화를 돌린다고 문서화. 탐지 룰 임계값을 인간 페이스 기준으로 맞춰두면 AI 가속 공격에는 미탐(false negative) 난다는 경고

3주 사이 공급망 연쇄 공격 — 패턴이 드러남

• LiteLLM (3/24): Trivy CI/CD 자격증명 훔쳐서 PyPI에 악성 litellm 1.82.7, 1.82.8 배포. 일 다운로드 340만. 40분~3시간 살아있다가 제거됨. CVE-2026-33634
  • 페이로드는 3단계 백도어로 50종 이상 클라우드 자격증명 노리고 Kubernetes DaemonSet으로 횡적 확산
• Axios (3/31): 메인테이너 계정 탈취로 주당 7천만~1억 다운로드 규모 패키지에 악성 버전 1.14.1, 0.30.4 배포. [email protected] 의존성 주입하고 크로스플랫폼 RAT 심음. MS가 북한 Sapphire Sleet에 귀속
• Vercel (4/19): OAuth → 내부 시스템 → 환경변수
• 세 공격 전부 타깃이 같음 — 개발자 툴체인에 저장된 자격증명·시크릿

크리덴셜 팬아웃의 무게

• Vercel 프로젝트 하나에 환경변수 보통 1030개. 50개 프로젝트 쓰는 조직이면 5001500개 자격증명이 한 플랫폼에
  • 각 자격증명이 별도 시스템의 진입점 — DB, 클라우드(AWS/GCP/Azure), 결제(Stripe), 인증(Auth0), 이메일(SendGrid), 모니터링(Datadog), 소스(GitHub/NPM), AI API(OpenAI/Anthropic)
  • 플랫폼 한 번 뚫리면 공급망 전체로 확산되는 "곱셈기" 역할

ShinyHunters 포럼 주장은 분리해서 봐야

• BreachForums에 ShinyHunters 계열을 자칭하는 자가 "Vercel 직원 580명 기록 + 소스코드 + API키 + GitHub/NPM 토큰 + Linear 워크스페이스 확보했다"고 주장 + 200만 달러 요구
  • 근데 기존 ShinyHunters 멤버들은 BleepingComputer에 "우린 아니다"라고 부인. 브랜드 자체가 여러 행위자에게 재사용되고 있어서 공격자 귀속이 모호
  • Vercel 공식 발표가 서술한 OAuth 공격 체인만으로는 포럼이 주장하는 데이터 범위가 안 나옴 → 과장·별개 사건·조작 가능성

디펜더 입장 — 즉시·단기·장기 액션

• 즉시(0-48시간): 2026년 2월 이후 저장한 sensitive 안 된 환경변수 전부 로테이션 → 재배포. OAuth 앱 승인 목록 감사 (알려진 악성 Client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com 검색)
• 단기(1-4주): 시크릿 매니저 마이그레이션, CI/CD는 OIDC 기반 단기 자격증명으로 전환, OAuth 앱을 서드파티 벤더 인벤토리에 등록
• 장기(1-6개월): 환경변수에 들어가는 시크릿은 "언제든 유출될 수 있다"는 제로트러스트 전제. 최소권한, 역할 기반 임시 자격증명, PaaS를 SBOM tier-1 공급망 의존성으로 취급
• 탐지 관점에서 가장 가치 있는 포인트는 OAuth 앱 접근(T1199)에서 내부 시스템 접근(T1078)으로 피벗하는 구간 — 예상 스코프 밖 리소스 접근, 예상 IP 범위 밖 토큰 사용 모니터링

기술 맥락

Vercel의 환경변수 설계를 놓고 업계에서 한참 전부터 "이거 위험하다"는 지적이 있었어요. 환경변수는 원래 12-factor app 철학에서 나온 거라 "런타임 설정"용이었는데, 현실에서는 API 키·DB 접속 문자열 같은 시크릿을 담는 용도로 굳어졌거든요. 문제는 환경변수가 프로세스 환경이나 빌드 아티팩트 곳곳에 퍼져서 감사가 어렵다는 점이에요.

그래서 Vault, AWS Secrets Manager, Doppler, Infisical 같은 전용 시크릿 매니저가 떠오른 이유가 바로 이거예요. 런타임에 단기 토큰으로 가져오고, 접근 로그 남기고, 자동 로테이션 붙이는 식. Vercel이 sensitive 플래그를 기본값 OFF로 둔 건 개발자 편의를 위해서였겠지만, "매 시크릿마다 옵트인하라"는 보안 정책은 실무에서 거의 안 지켜져요. GitHub Actions가 모든 시크릿을 로그에서 자동 마스킹하는 것도 같은 교훈 때문이죠.

OAuth 공급망 공격은 왜 기존 방어선을 뚫었냐면, OAuth 토큰은 비밀번호 초기화·MFA 재요구·세션 만료 같은 전통적 통제를 전부 우회하거든요. "한번 앱 승인하면 끝"이에요. 그래서 Google Workspace 관리자가 주기적으로 "우리 회사에 연결된 OAuth 앱 목록"을 감사하고, 안 쓰는 벤더는 revoke하는 루틴이 필요해요. 이걸 IAM이랑 분리해서 "서드파티 리스크 관리"로 다루자는 주장이 나오는 배경이죠.

마지막으로 "rotation 후 redeploy" 얘기가 중요해요. Vercel은 배포 아티팩트가 불변(immutable)이라 새 배포를 안 찍으면 옛날 배포가 계속 옛날 환경변수를 쓰거든요. 그래서 "키 바꿨으니 됐지"가 아니라 "키 바꾸고 → 재배포하고 → 이전 배포 비활성화"까지 가야 실제로 끊기는 거예요.