AI 도구 하나가 Vercel을 멈췄다, Context AI 침해로 시작된 OAuth 공급망 해킹의 교훈
🤖 AI Summary
2026년 4월 19일 Vercel은 내부 시스템 침해 사실을 공개했습니다. 시작은 두 달 전 Context AI 직원의 인포스틸러 감염이었고, OAuth 토큰 탈취가 Vercel 직원의 Google Workspace 계정을 거쳐 Vercel 내부 시스템 침투로 이어졌죠. 4월 20일에는 BreachForums에 Vercel 데이터베이스가 200만 달러에 매물로 올라왔습니다. 직원 한 명이 AI 도구에 부여한 Allow All OAuth 권한이 회사 보안의 결정점이 된 사건이에요. 이 글에서는 사건 타임라인을 1차 출처로 복원하고, 우리 회사가 같은 구조에서 점검해야 할 OAuth 공급망 보안 3가지를 정리합니다.
블로그 목차
직원이 한 번 누른 OAuth Allow All이 회사 보안을 결정합니다
요즘 어느 회사든 직원들이 다양한 AI 도구를 시도해보고 있죠. 회의록 자동 정리, 이메일 초안 작성, 문서 요약 같은 생산성 도구가 매주 새로 나오니까요. 그런데 이런 AI 도구를 회사 Google Workspace나 Microsoft 365 계정에 OAuth로 연결할 때 등장하는 Allow All 권한 버튼이 회사 보안의 가장 약한 지점이 될 수 있다는 사실이 2026년 4월 Vercel 사건으로 드러났습니다.
Vercel은 Next.js 배포 플랫폼으로 잘 알려진 회사예요. 이 회사가 4월 19일 자사 내부 시스템에 무단 접근이 있었다는 사실을 공식 공개했고, 그다음 날인 4월 20일에는 Vercel 데이터베이스가 BreachForums에 200만 달러 매물로 올라왔습니다. 시작점은 Vercel이 아니라 Context AI라는 3rd party AI 도구였죠. 이 글에서는 사건 타임라인을 1차 출처로 정리하고, 우리 회사가 같은 구조에서 어디를 점검해야 하는지 짚어봅니다.
두 달에 걸쳐 만들어진 침해, 분 단위가 아니라 60일짜리 공격
이번 사건은 단발 침해가 아니라 두 달 가까이 진행된 다단계 공격이었어요. Vercel 공식 발표, Context AI 공식 발표, TechCrunch·The Register·The Hacker News·OX Security 보도를 종합하면 시간 흐름은 이렇습니다.
출발점은 2026년 2월 Context AI 직원이 게임 익스플로잇을 다운로드했다가 Lumma 인포스틸러에 감염된 사건이었습니다(OX Security 분석). 이 악성코드는 직원 장치에서 자격증명, 세션 데이터, OAuth 토큰을 추출했죠. 3월에는 공격자가 Context AI의 AWS 환경에 무단 접근하면서 동시에 일부 사용자의 OAuth 토큰을 탈취하고 악성 브라우저 확장을 배포했습니다(Context AI 공식 발표).
그리고 그 OAuth 토큰 중 하나가 Vercel 직원의 회사 계정에 연결돼 있었어요. 4월 19일 Vercel은 무단 접근 사실을 공식 공개했고, 다음 날 BreachForums에는 Vercel 데이터베이스가 200만 달러 매물로 올라왔습니다.
Allow All 한 번이 만든 SaaS-to-SaaS 공격 경로
이 사건의 진짜 핵심은 공격자가 멀웨어로 침입한 게 아니라 합법적인 OAuth 토큰으로 들어왔다는 점입니다. Vercel 직원이 Context AI Office Suite 앱을 회사 Google Workspace에 연결할 때 Allow All 권한을 부여한 게 결정적이었죠(Help Net Security 보도). 보안 시스템 입장에서는 정상 사용자가 정상 토큰으로 정상 API를 호출하는 것처럼 보이니까요.
VentureBeat 보도에서 가장 인상적인 표현이 등장합니다. 대부분의 보안팀이 OAuth 연결의 범위와 영향을 탐지·통제하지 못한다는 진단이었어요. 회사 IT 팀이 직원 한 명 한 명이 Google Workspace에 어떤 외부 앱을 연결했는지, 그 앱들이 어떤 권한을 받았는지를 실시간으로 파악하는 게 현실적으로 어렵다는 거죠.
유출된 것과 보호된 것, Vercel 공식 발표 기준
Vercel 공식 KB Bulletin에 따르면 영향 범위는 다음과 같이 정리됩니다.
구분 | 대상 | 상태 |
|---|---|---|
유출됨 | customer API 키, 데이터베이스 자격증명, 서명 키, 토큰 등 non-sensitive로 마킹된 환경변수 | 침해 가능, 즉시 로테이션 권고 |
유출됨 | 일부 소스코드 및 데이터베이스 데이터 | BreachForums에 200만 달러 매물 |
보호됨 | Sensitive로 마킹된 환경변수 (plaintext로 복호화되지 않는 것) | 유출 없음 확인 | |
대응 | 법 집행 기관 신고, Google Mandiant, GitHub, Microsoft, npm, Socket과 협력 조사 | npm 패키지 무결성 확인 완료 |
주목할 부분은 non-sensitive 환경변수도 충분히 위험했다는 점입니다. 많은 개발팀이 환경변수를 sensitive와 non-sensitive로 분류할 때 API 키나 DB 자격증명을 non-sensitive에 두는 경우가 있죠. 결과적으로 이번 사건에서 그게 그대로 노출됐고, 인접 시스템과 고객 환경까지 영향이 번질 수 있는 상황이 됐습니다.
우리 회사가 지금 점검할 OAuth 공급망 3가지
Vercel 사건은 SaaS 도구를 적극 도입하는 모든 회사에 똑같이 적용되는 구조예요. 다음 3가지를 이번 주 안에 한 번 돌려보는 것을 권장합니다.
점검 항목 | 구체 액션 |
|---|---|
1. SaaS 도구 OAuth 연결 인벤토리 | Google Workspace 또는 Microsoft 365 관리자 콘솔에서 직원들이 회사 계정에 연결한 외부 앱 목록을 전수 확인 |
2. Allow All 권한 회수 | 읽기·쓰기·관리자 권한 모두 받은 외부 앱은 즉시 권한 축소, 업무에 꼭 필요한 범위로만 재설정 |
3. 환경변수 분류 재검토 | API 키·DB 자격증명·서명 키가 non-sensitive로 분류돼 있는지 확인, sensitive로 재마킹 |
3가지 점검을 처음 돌려보면 의외로 승인된 적 없는 외부 앱이 회사 계정에 연결돼 있는 경우를 자주 발견합니다. 직원이 개인적으로 시도해본 AI 도구가 그대로 권한을 유지하고 있는 식이죠. 외부 전문가와 함께 점검을 돌려보고 싶다면 스피디 MSP의 SaaS 보안 진단을 활용해보세요.
이것만 기억하세요
Vercel 침해는 멀웨어 침입이 아니라 직원이 AI 도구에 부여한 Allow All OAuth 권한이 진입 경로가 된 SaaS-to-SaaS 공급망 공격이었습니다. 시작은 두 달 전 Context AI 직원의 Lumma 인포스틸러 감염이었고, OAuth 토큰 → Google Workspace → Vercel 내부 → BreachForums 200만 달러 매물까지 60일에 걸쳐 진행됐죠. 우리 회사도 SaaS 도구 OAuth 연결 인벤토리, Allow All 권한 회수, non-sensitive 환경변수 재분류 3가지를 이번 주 안에 한 번 돌려보는 게 같은 구조의 사고를 막는 가장 빠른 출발점입니다.
자주 묻는 질문 (FAQ)
Q. 우리 회사도 Vercel을 쓰고 있는데 어떻게 해야 하나요?
Vercel 공식 권고에 따르면 모든 영향 받은 환경변수와 자격증명을 즉시 로테이션해야 합니다. Vercel은 영향 받은 고객에게 직접 통지했다고 밝혔으니 통지 받았는지 먼저 확인하세요. 통지 없더라도 예방 차원에서 sensitive로 마킹하지 않은 모든 키와 토큰을 점검해 재발급하는 것이 안전합니다.
Q. Context AI의 OAuth 토큰이 어떻게 다른 회사 계정까지 침투할 수 있죠?
OAuth는 사용자 대신 외부 앱이 계정 리소스에 접근할 수 있도록 토큰을 발급하는 인증 방식입니다. Context AI 같은 외부 앱이 침해되면 그 앱이 보유한 OAuth 토큰들도 함께 노출되고, 공격자는 그 토큰으로 사용자 계정에 합법적으로 접근할 수 있게 됩니다. 멀웨어가 새로 침투하는 게 아니라 이미 발급된 토큰을 사용하는 방식이라 보안 솔루션이 탐지하기 어려운 게 핵심 위험입니다.
Q. SaaS 도구 OAuth 연결을 일일이 검토할 인력이 부족합니다. 자동화 방법이 있나요?
Google Workspace와 Microsoft 365 모두 관리자 콘솔에서 외부 앱 연결을 정책으로 통제할 수 있습니다. 사전 승인된 앱만 OAuth 연결을 허용하는 정책을 적용하거나, 새 외부 앱 연결을 관리자 승인제로 전환하는 방식이 일반적입니다. SSPM(SaaS Security Posture Management) 솔루션을 도입하면 OAuth 연결 자체를 지속 모니터링할 수 있습니다.
Q. non-sensitive 환경변수와 sensitive 환경변수는 무슨 차이인가요?
대부분 클라우드 호스팅 플랫폼은 환경변수를 두 등급으로 관리합니다. sensitive는 한 번 입력하면 다시 조회할 수 없고 시스템 내부에서만 복호화돼 사용되는 반면, non-sensitive는 관리자 화면에서 plaintext로 다시 조회할 수 있습니다. 편의성 때문에 API 키를 non-sensitive로 두는 경우가 많은데, 이번 Vercel 사건처럼 침해 시 그대로 노출되니 분류 기준을 보수적으로 잡는 것이 안전합니다.
