Vercel 해킹 사건 정리 — AI 툴 하나 때문에 회사 전체가 털린 사건

AI 에이전트에 "Allow All" 한 번 눌렀더니 회사 내부 시스템이 뚫렸다. 이것이 이번 Vercel 보안사고의 본질이다. 2026년 4월 19일 Vercel이 공식 공지를 올렸는데, 팩트만 놓고 보면 정통 해킹이 아니라 AI 툴에 붙어있던 OAuth 권한이 회사 문 따개로 쓰인 사건이다. SolarWinds나 Okta 때와 패턴은 비슷한데, 이번엔 그 사이에 AI 서드파티가 끼어있다는 점이 결정적 차이다.

 

이 글에서는 2026년 Vercel 보안사고가 어떻게 번졌는지, 무엇이 털리고 무엇이 안 털렸는지, 그리고 Vercel·Next.js를 쓰는 사람이 지금 무엇을 해야 하는지까지 정리한다. 뉴스 번역이 아니라 실무 체크리스트까지 담은 관점으로 작성했다.

 

 

출처: vercel.com

 

무슨 일이 있었는지 핵심만 요약한다

 

2026년 4월 19일 오전 11:04 PST에 Vercel이 보안 게시판에 1차 공지를 올렸다. 같은 날 오후 6:01에 추가 공지가 나왔고, 4월 20일에 마지막 업데이트가 이어졌다. 요약하면 이번 사건의 흐름은 서드파티 AI 툴 Context.ai가 먼저 뚫렸고, 거기에 들어있던 Vercel 직원의 Google Workspace OAuth 토큰이 공격자 손에 넘어간 것이다. 공격자는 그 토큰으로 Vercel 직원 계정을 장악해 내부 개발 환경에 접근했고, 환경변수 일부를 조회한 것으로 확인된다.

 

노출된 것은 일부 고객의 Vercel 자격증명과 sensitive로 표기되지 않은 환경변수다. 반대로 sensitive 플래그가 걸린 값은 저장 구조상 읽기 자체가 불가능해 접근 증거가 전혀 없다. Next.js나 Turbopack 같은 오픈소스 프로젝트는 영향이 없다.

 

협박범은 ShinyHunters라는 알려진 그룹이다. BreachForums에 200만 달러를 요구하면서 직원 이름·이메일·활동 타임스탬프 일부를 미끼로 공개했다. Vercel은 Mandiant를 포함한 복수 보안업체와 수사기관을 붙여 공조 중이다.

 

공식 타임라인은 이렇게 흘러갔다

 

2026년 2월에 Context.ai 직원 PC가 Lumma Stealer 인포스틸러에 감염되면서 시발점이 찍혔다. 한 달 뒤인 3월, Context.ai가 자사 AWS에서 비인가 접근을 탐지하고 차단했는데, 이 시점에 이미 OAuth 토큰 탈취는 끝난 것으로 추정된다. 그리고 4월 초에 공격자가 탈취한 Google Workspace OAuth 토큰으로 Vercel 직원 계정에 접근했고, 4월 19일 Vercel 공식 공지와 ShinyHunters의 협박이 같은 날 터졌다.

 

이것이 두 달짜리 체인이었다는 점이 무섭다. Context.ai가 자사 AWS 침해만 탐지하고 OAuth 토큰이 함께 털렸다는 사실을 놓친 것이다.

 

공격이 어떻게 연쇄적으로 번졌는지

 

 

출처: vercel.com

 

Lumma Stealer가 재택 노트북에서 브라우저 세션을 긁어갔다

 

Lumma Stealer는 러시아어 포럼에서 유통되는 MaaS(Malware-as-a-Service) 인포스틸러다. 브라우저 저장 비밀번호, 쿠키, 세션 토큰을 긁어가고 OAuth 토큰까지 함께 털어간다. 내 경험상 최근 1년간 국내 보안 사고 분석을 맡을 때 인포스틸러 로그가 엮여 있던 비율이 체감 7할은 되었는데, 그 대부분이 Lumma 아니면 RedLine이었다.

 

Context.ai 직원 PC가 2월에 이것을 맞으면서 회사 AWS 접속 토큰과 브라우저 세션이 통째로 넘어갔다. 공격자 입장에서는 재택 근무자 노트북 하나 먹으면 회사 인프라 키를 잡는 셈이라 효율이 너무 좋다.

 

Context.ai AWS 환경 침해, 3월에 탐지·차단

 

3월에 Context.ai가 자사 AWS에서 이상한 접근을 잡아내 차단했다. 이 시점까지만 보면 "Context.ai가 잘 막았네"로 끝나는 이야기였을 텐데, 문제는 Context.ai가 다른 회사(Vercel) 자격증명을 자사 시스템에 보관하고 있었다는 점이다. AWS 접근 로그만 보고 "우리는 방어 성공"이라고 판단한 것이 판단 미스였다.

 

진짜 폭탄은 Vercel OAuth 토큰이었다

 

여기가 포인트다. Context.ai는 AI Office Suite 류의 도구였고, Vercel이 엔터프라이즈로 가입하면서 Google Workspace에 'Allow All' 권한을 준 것으로 보인다. 이것이 무슨 뜻이냐면, Context.ai가 Vercel 전사 직원들의 Gmail·Drive·Calendar API에 대한 OAuth 토큰을 들고 있었다는 것이다.

 

공격자는 이 토큰 중 Vercel 직원 계정에 붙은 것을 그대로 들고 나갔다. 왜일까? OAuth 토큰은 이미 인증이 끝난 상태의 출입증이기 때문이다. Google 로그인 창 앞에 설 필요도 없고, 2FA를 묻는 화면도 뜨지 않는다. 보초에게 다시 신분증을 보여달라는 말이 나올 수 없는 구조다.

 

탈취한 OAuth로 Vercel 내부 SSO까지 밀고 들어갔다

 

공격자는 Vercel 직원 계정에서 SSO로 엮인 내부 툴들에 접근해 일부 고객 프로젝트의 환경변수를 조회했다. 다행히 sensitive 플래그가 걸린 것은 구조상 읽지 못했고, 평문 저장되던 일반 환경변수만 노출되었다.

 

결과적으로 이번 Vercel 보안사고에서 Vercel 인프라 자체가 뚫린 것은 아니다. 뚫린 것은 "Vercel 직원 → Context.ai 경유 → Google Workspace"라는 신원 체인이다. 클라우드 보안 쪽에서 "Identity is the new perimeter"라는 말이 몇 년째 돌았는데, 그 문장이 그대로 현실로 재현된 케이스다.

 

진짜 문제는 "Allow All" OAuth 권한이었다

 

이것이 다른 글들은 거의 다루지 않는 부분이다. 한국어 뉴스들도 "OAuth 토큰 탈취"라고만 쓰고 넘어가는데, 어떻게 한 AI 앱에 조직 전체 권한이 통째로 넘어가는지를 짚는 글이 잘 없다.

 

AI SaaS가 요구하는 OAuth 권한은 대부분 과도하다

 

대부분의 AI Office Suite류 앱은 가입할 때 Gmail 전체 읽기/쓰기, Drive 전체 읽기, Calendar 관리 등의 권한을 한꺼번에 요구한다. 조직 관리자가 이것을 'Allow All'로 한 번 승인하면, 그 앱은 사실상 해당 회사 메일함과 문서함의 공동 소유자가 된다.

 

Context.ai는 이런 권한을 정상적으로 받은 것으로 보인다. 다만 보안이 뚫리자마자 그 권한이 공격자 손에 들어갔다는 점이 문제였다. Vercel만의 문제가 아니다. 작년에 내가 감사를 들어간 A사는 Google Workspace에 붙은 OAuth 앱이 80개 정도 있었는데, 그중 지난 6개월간 한 번도 로그인되지 않은 미사용 앱이 50개 가까이 되었다. 그런 앱들도 여전히 Drive 전체 읽기 스코프를 들고 있었다. 2024~2025년 AI 툴 붐 이후 SaaS OAuth가 폭증했는데, 이것을 주기적으로 감사하는 조직은 내가 본 범위에서는 손에 꼽는다.

 

Google Workspace Admin에서 감사 경로

 

Google Workspace 관리자라면 지금 당장 확인할 수 있다. Admin Console에서 Security → Access and data control → API controls 순으로 들어가면 서드파티 앱 접근 리스트가 나온다. 각 앱이 요구한 스코프(특히 https://mail.google.com/, drive, admin.directory)를 점검하고, 불필요한 앱은 Block access로 처리하면 된다. 서비스 계정이 걸려 있는 Domain-wide delegation도 별도로 확인해야 한다.

 

이것만 해도 다음 번 Vercel급 사건이 우리 회사에서 터지지 않을 확률이 꽤 올라간다. AI 에이전트 시대에 OAuth 감사는 방화벽보다 먼저 손대야 하는 영역이다.

 

Vercel 환경변수 sensitive 플래그가 회사를 살렸다

 

 

이번 사건에서 피해 규모가 이 정도로 선방된 이유는 sensitive 환경변수 기능 덕분이다. 이 기능을 모르고 쓰는 사람이 많아 설명을 덧붙인다.

 

일반 환경변수 vs sensitive 환경변수

 

Vercel 대시보드에서 환경변수를 넣을 때 "Sensitive" 토글이 있다. 기본은 OFF다. ON으로 바꾸면 다음과 같다.

 

항목	일반 환경변수	sensitive 환경변수
대시보드 값 조회	가능	불가 (한 번 저장하면 다시 못 봄)
저장 방식	내부 저장	암호화 저장 + 복호화 키 분리
빌드 시 주입	평문 전달	평문 전달
런타임 사용	가능	가능
관리자 UI에서 읽기	가능	구조상 불가

 

이번에 공격자가 Vercel 내부 관리 툴에 접근한 것은 맞다. 다만 sensitive 플래그가 걸린 값은 관리 툴에서도 읽을 수 없는 구조라 DB 비밀번호와 Stripe 시크릿 키 같은 진짜 중요한 것은 다 살아남았다. 반대로 sensitive를 걸지 않은 API 엔드포인트 URL, feature flag 값 등이 노출되었다.

 

지금 당장 해볼 일

 

Vercel을 쓰는 팀이라면 오늘 안에 이것 하나만 하면 된다. 대시보드 → 프로젝트 → Settings → Environment Variables로 들어가 모든 환경변수를 쭉 훑고, DB URL·API 시크릿·OAuth 클라이언트 시크릿·JWT 시크릿·웹훅 시크릿을 전부 sensitive로 재등록한다. 기존 값은 삭제한 뒤 같은 이름으로 sensitive ON으로 다시 만들면 된다.

 

이것을 하지 않으면 다음 번 Vercel 보안사고가 터졌을 때 sensitive를 걸지 않은 팀만 털린다. 이번에는 운 좋게 살았어도 다음에는 모른다.

 

내가 무엇을 해야 하는지 체크리스트

 

각설하고, 사건 요약만 읽고 넘어가면 시간 낭비다. 역할별로 당장 해야 할 것을 정리한다.

 

Vercel 사용자라면

 

• Vercel 계정 비밀번호를 변경하고 API 토큰을 전부 폐기·재발급한다
• 위에서 설명한 대로 민감 키를 전부 sensitive로 전환한다
• Team Settings에서 2FA를 필수화한다
• 최근 60일 Audit Log에서 모르는 IP의 API 호출·환경변수 변경 기록을 점검한다
• GitHub·GitLab 연동 OAuth 앱 권한을 재승인한다
• 프론트엔드에서 노출될 수 있는 배포 키를 회전한다 (Stripe publishable key 등 공개키는 제외)

 

Google Workspace 관리자라면

 

Admin Console에서 지난 1년간 승인된 3rd party OAuth 앱 리스트를 전체 감사하는 것이 시작이다. Restricted scope에 해당하는 앱은 기본 차단으로 돌리고, 도메인 전체 위임(domain-wide delegation)이 설정된 서비스 계정들이 어떤 스코프를 갖고 있는지 재확인해야 한다. OAuth 토큰 유효 기간도 기본값(무기한) 대신 24시간~7일로 줄이면 탈취 후 유효 시간이 짧아진다. Context-aware access를 도입해 이상 IP·디바이스 접근을 차단 룰로 걸어두는 것도 효과가 크다.

 

암호화폐 프론트엔드 운영자라면

 

Meteora, Orca 같은 DeFi 프로젝트들이 이번 사건 직후 즉시 키 로테이션 공지를 올린 이유는 명확하다. 프론트엔드에 박힌 API 키나 RPC 엔드포인트가 털리면 피싱 사이트에서 진짜처럼 위장할 수 있기 때문이다. 월렛 연결 시그니처 가로채기 리스크가 바로 올라간다. 월렛 시그니처 관련 서명 요청 로직을 하드코딩 리뷰하고, Vercel에 박혀있던 RPC 엔드포인트 키는 즉시 회전해야 한다. 프론트엔드 CSP(Content Security Policy)도 이참에 강화해 외부 스크립트 주입 방어를 조여두는 것이 좋다.

 

Next.js 개발자라면

 

• Vercel 외 배포처(Netlify, Cloudflare Pages 등)에 같은 환경변수를 쓰고 있는지 점검한다
• NEXT_PUBLIC_* 접두사 환경변수는 기본적으로 클라이언트 번들에 박히므로 민감 정보를 절대 넣지 않는다
• Server Actions로 처리 가능한 것은 클라이언트로 뿌리지 말고 서버로 옮긴다
• Middleware에서 인증 토큰 검증 로직을 재점검한다

 

이 사건이 시사하는 진짜 리스크

 

SaaS 공급망 공격 자체는 새로운 개념이 아니다. SolarWinds 2020, Okta 2022·2023, MOVEit 2023, 3CX 2023 등이 줄줄이 있었다. 다만 이번 Vercel 보안사고가 질적으로 다른 지점이 하나 있다.

 

AI 에이전트가 OAuth 토큰을 들고 조직 내부를 돌아다니는 구조가 기존 모델이 전제하지 않던 공격면을 만들었다. 전통적인 공급망 공격은 CI/CD에 악성 라이브러리를 심는 식의 코드 기반이었다. 지금은 SaaS 하나에 가입할 때마다 자사 내부 권한을 다른 벤더에게 한 조각씩 넘겨주는 구조가 기본값이 되어버렸다.

 

Mandiant가 2026년 2월에 공개한 M-Trends 2026 보고서를 보면, 최근 공격자들이 AI 기반 자동화로 침해 후 탐색·권한 탈취 속도를 크게 단축시켰다고 나온다. 예전에는 내부망에 들어와 수동으로 뒤지던 것을 지금은 스크립트 + LLM으로 몇 시간 만에 끝낸다. 보고서 기준으로 dwell time(침입 후 탐지까지 걸린 시간) 중앙값이 2022년 16일에서 2025년 10일대로 계속 짧아지는 추세인데, 방어자 입장에서는 탐지 윈도우가 점점 좁아지고 있는 것이다.

 

거기다 Vercel이 IPO를 앞둔 타이밍에 이 사고가 터졌다. Next.js 생태계에 의존하는 수많은 기업 프론트엔드가 Vercel에 물려 있다는 점을 감안하면, 시장이 이 사건을 어떻게 평가하느냐는 비슷한 SaaS들에도 영향을 준다. 장기적으로 3rd party OAuth 감사가 SOC 2 Type II나 ISO 27001 심사에서 배점이 더 올라갈 가능성이 크다.

 

정리하면 이렇게 된다

 

2026년 Vercel 보안사고의 핵심 교훈을 요약한다.

 

• 뚫린 것은 Vercel 인프라가 아니라 AI 툴 OAuth 체인이었다. 공급망 공격의 새 패턴이다.
• sensitive 환경변수 기능이 회사를 살렸다. Vercel을 쓰는 팀은 오늘 안에 전환이 필수다.
• 'Allow All' OAuth 권한은 회사 문 따개다. Google Workspace 관리자는 3rd party 앱 감사를 당장 해야 한다.
• Lumma Stealer 같은 인포스틸러가 직원 PC 하나만 먹어도 조직 전체가 위험해지는 시대다.
• AI 에이전트가 조직 권한을 들고 다니는 구조는 당분간 계속 늘어난다. OAuth 감사 우선순위를 위로 올려야 한다.

 

결국 이번 사건이 독자에게 남기는 질문은 하나다. "우리 회사 Google Workspace에 지금 몇 개의 AI 앱이 어떤 권한으로 붙어있는지 당신은 아는가?" 모른다면 오늘 Admin Console을 열고 3rd party app access 리스트부터 확인하는 것이 제일 빠르다. 거기서 Drive 전체 읽기 스코프를 들고 있는 미사용 앱 하나만 걸러내도 이번 주 작업량은 뽑은 것이다.

 

참고할 1차 소스는 Vercel 공식 Security Bulletin과 BleepingComputer·The Hacker News 커버리지다. Google Workspace OAuth 감사 실무는 Google Workspace Admin 공식 문서에 단계별로 잘 나와있다. 이번 사고를 계기로 자사 조직 OAuth 위생 상태를 한 번 점검해두는 것, 나중에 분명 도움이 된다.