Web

Vercel 내부 시스템 무단 접근 사고 - 26.04.20

Aidengoldkr 2026. 4. 20. 07:37

2026년 4월 19일, Vercel이 내부 시스템에 대한 무단 접근이 발생했다고 공식적으로 인정했다.

Vercel은 Next.js의 핵심 후원사이자 전 세계 수백만 개발자가 사용하는 클라우드 배포 플랫폼이다. 이 사건이 단순한 기업 침해로 끝나지 않은 이유는, Vercel이 인터넷 인프라의 핵심을 담당하고 있기 때문이다.

 

https://vercel.com/kb/bulletin/vercel-april-2026-security-incident

무슨 일이 있었나

이슈: 공격자가 Vercel 내부 시스템에 침투해 소스 코드, 직원 계정 데이터, 고객 환경 변수, NPM 토큰, GitHub 개인 액세스 토큰(PAT)을 탈취했다고 주장했다.

 

Vercel은 "제한적인 하위 집합(limited subset)"의 고객이 영향을 받았다고 밝혔다. 핵심 호스팅 서비스는 정상 운영 중이라고 했다.

공격자는 사이버 범죄 포럼 BreachForums에 탈취한 데이터를 200만 달러에 판매한다는 게시글을 올렸다. 자신을 악명 높은 해킹 그룹인 ShinyHunters라고 주장했고, Vercel 직원 수백명 (약 580명)의 계정 정보와 내부 대시보드 스크린샷을 샘플로 공개했다.

흥미로운 점은, ShinyHunters 본체가 이 사건과의 연관성을 전면 부인했다는 것이다. 실제 공격자의 정체는 여전히 불명확하다.

침해의 시작점: 서드파티 AI 도구의 OAuth 앱

해결책을 논하기 전에, 어떻게 침투했는지를 이해하는 것이 중요하다.

Vercel의 자체 보안 게시판에 따르면, 이번 사건의 진입점은 Vercel 직원들이 업무에 사용하던 소규모 서드파티 AI 도구였다. 이 도구는 Google Workspace OAuth 앱을 통해 직원의 Google 계정에 대한 접근 권한을 위임받은 상태였다.

 

공격자는 Vercel을 직접 공격한 것이 아니었다. 방어력이 상대적으로 취약한 AI 벤더의 인프라를 먼저 장악했다.

벤더가 장악되자, 벤더가 보관하고 있던 수백 개 조직의 OAuth 액세스 토큰이 공격자의 손에 들어갔다. 공격자는 탈취한 Vercel 직원의 OAuth 토큰으로 Google Workspace 환경에서 합법적인 사용자로 위장했고, 거기서부터 이슈 트래커인 Linear와 GitHub 엔터프라이즈 환경으로 측면 이동(Lateral Movement)을 수행했다.

 

침해 지표(IOC)로 공개된 손상된 OAuth App Client ID:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

 

보안 연구자들과 보안 커뮤니티의 추정에 따르면 이 Client ID로 Google의 인증 동의 화면을 렌더링해 AI 도구 이름을 역추적하려 했을 때, Google 서버는 "Error 401: invalid_client"를 반환했다. 벤더가 자신의 신원이 공개되는 것을 막기 위해 OAuth 앱 자체를 삭제해버린 것이다.

 

Vercel이 해당 AI 벤더의 이름을 공개하지 않은 결정은 보안 커뮤니티의 강한 비판을 받았다. 동일한 도구를 사내에서 사용 중인 다른 조직들이 적시에 방어 조치를 취하지 못하게 되기 때문이다.

환경 변수 노출의 구조적 문제

Vercel은 환경 변수를 민감한(Sensitive) 변수와 일반(Non-sensitive) 변수로 구분하여 저장한다.

민감한 환경 변수는 쓰기 전용(Write-only)으로 취급된다. 한 번 등록하면 Vercel 대시보드나 API를 통해 원문 값을 다시 읽어올 수 없다. 이번 침해에서 해당 볼트에 대한 접근 또는 복호화 흔적은 발견되지 않았다.

 

문제는 일반 환경 변수였다. 빠른 개발과 디버깅을 위해 접근성이 높은 형태로 저장되어 있는데, 관리자 권한이 탈취된 상황에서는 그 안에 있는 API 키, 데이터베이스 자격 증명, JWT 서명 비밀키가 전부 노출 위험에 처한다.

 

여기서 주의해야 할 점이 있다.

Vercel 대시보드에서 기존 키를 삭제하고 새 키를 입력하는 것만으로는 충분하지 않다. 공격자가 이미 이전 키를 데이터베이스 덤프로 확보한 상태라면, Vercel 내에서 값을 바꿔도 공격자의 구 키는 여전히 유효하다.

 

근본적인 대응은 업스트림 서비스 제공자 측에서 기존 키를 명시적으로 폐기(Revoke)하는 것이다. AWS 콘솔, Stripe 대시보드, MongoDB Atlas 등에서 직접 접속해서 기존 액세스 토큰을 삭제하고 새로 발급받아야 한다.

NPM과 공급망 공격의 가능성

이 사건이 단순한 데이터 유출로 끝나지 않을 수 있는 이유가 바로 NPM 토큰이다.

Vercel은 Next.js를 비롯해 JavaScript 생태계에서 수천만 건의 주간 다운로드를 기록하는 핵심 패키지들을 관리한다. 만약 공격자가 유효한 NPM 퍼블리시 토큰을 확보했다면, 악성 코드가 삽입된 업데이트를 공식 레지스트리에 배포하는 것이 가능해진다.

 

전 세계 수백만 명의 개발자가 npm install 한 번에 감염될 수 있는 시나리오다.

Vercel은 현재까지 빌드 조작이나 NPM 패키지 변조에 대한 명확한 증거는 없다고 밝혔다. 그러나 이론적 가능성만으로도 충분히 비상이다.

2026년 공급망 공격의 흐름

이 사건을 독립적으로 보면 안 된다.

2026년 1분기, TeamPCP라는 위협 그룹이 LiteLLM이라는 LLM 프록시 라이브러리를 공격했다. LiteLLM은 하루 평균 340만 건 이상 다운로드되는 AI 애플리케이션의 핵심 의존성이었다.

 

TeamPCP는 컨테이너 취약점 스캐너 Trivy와 정적 분석 도구 Checkmarx KICS의 배포 파이프라인을 먼저 침해하고, 거기서 탈취한 크리덴셜로 PyPI에 악성 LiteLLM 버전(1.82.7, 1.82.8)을 올렸다. 버전 1.82.8에는 .pth 파일이 숨어 있었는데, Python 인터프리터가 실행되는 순간 해당 코드가 자동으로 실행되면서 AWS/GCP/Azure 토큰, SSH 키, .env 파일을 수집해 외부 서버로 전송했다.

 

이 캠페인의 직접적인 피해자 중 하나인 Mercor는 4TB 규모의 데이터 유출을 공식 시인해야 했다.

Vercel 사건과 LiteLLM 사건의 공통점: 보안 검증 없이 서드파티 AI 도구에 과도한 권한을 부여하는 문화.

공격자는 방화벽을 뚫지 않았다. 신뢰받는 서드파티를 통해 "로그인"했다.

Web3 생태계로의 전이 위험

Vercel이 단순한 정적 사이트 호스팅 업체가 아니라는 점이 이 사건을 더 복잡하게 만든다.

탈중앙화 거래소(DEX) 프론트엔드, 지갑 커넥터 인터페이스, 크로스체인 브리지 대시보드의 상당수가 Vercel 위에서 호스팅된다.

 

Web3 개발팀은 프라이빗 RPC 엔드포인트 URL, Alchemy/Infura API 키 등을 Vercel 환경 변수로 관리하는 경우가 많다.

비민감 환경 변수가 대량 노출되었다면, 특정 DeFi 프로젝트의 배포 파이프라인 권한까지 획득할 수 있다. 스마트 컨트랙트를 직접 건드리지 않고도, 프론트엔드 JavaScript를 미세하게 조작해 사용자의 지갑 트랜잭션을 공격자의 주소로 돌리는 것이 기술적으로 가능한 시나리오다.

 

같은 시기에 KelpDAO가 LayerZero 기반 rsETH 브리지 공격으로 2억 9,200만 달러 규모의 자산을 탈취당했다. Vercel 침해와의 직접적 인과관계는 확인되지 않았지만, 두 사건이 겹치면서 DeFi 시장에 공포가 퍼졌고 Aave 토큰이 단기적으로 20% 폭락하는 연쇄 반응이 일어났다.

지금 당장 해야 할 것

Vercel을 사용하고 있다면:

  1. 모든 비민감 환경 변수를 업스트림에서 폐기(Revoke)하고 재발급받을 것 — Vercel 대시보드 교체가 아니라, AWS/Stripe/GitHub 등 각 서비스 콘솔에서 직접.
  2. 새로 발급받은 모든 자격 증명은 Sensitive 플래그를 켜서 저장할 것.
  3. GitHub 조직과 NPM 패키지에 연동된 Vercel 토큰을 전부 강제 만료시키고 재생성할 것.
  4. Google Workspace 관리 콘솔에서 연동 앱 목록을 감사하고, 공개된 IOC(110671459871-...)를 차단 목록에 등록할 것.
  5. 과거 빌드 로그를 스캔해 민감 변수 값이 콘솔 출력에 노출된 적이 없는지 확인할 것.

장기적으로는, 반영구적인 API 키를 환경 변수에 넣는 방식 자체를 재검토해야 한다. HashiCorp Vault나 AWS Secrets Manager를 통해 런타임 시점에 수명이 짧은 임시 토큰을 발급받는 동적 시크릿 프로비저닝 구조로 전환하는 것이 근본적인 해결 방향이다.

마무리

이번 사건에서 배운 것은 명확하다.

현대의 공격자는 방화벽을 뚫는 데 시간을 쓰지 않는다. 직원이 무비판적으로 OAuth 권한을 승인한 소규모 AI 도구 하나가, 수백만 개발자의 인프라를 위협하는 진입점이 되었다.

 

편의성과 보안은 언제나 상충하지만, AI 도구의 도입 속도가 보안 검토 속도를 압도하는 지금 이 시기에는 그 긴장이 특히 위험하다.

서드파티 AI 도구에 기업의 핵심 인프라 접근 권한을 부여하는 것은, 기존 엔터프라이즈 SaaS 도입 이상의 엄격한 보안 심사를 거쳐야 한다. 그것이 이번 사태가 남긴 가장 중요한 교훈이다.

참고 자료

'Web' 카테고리의 다른 글

Good Bye! BOJ! 백준 메모리얼 웹 배포 후기  (0) 2026.04.16
[풀스택 100시간 과정] #4 - 세션, 쿠키, API, 페이징  (0) 2026.04.13
[풀스택 100시간 과정] #3 - 서버와 HTTP  (0) 2026.04.13
조코딩 x OpenAI x Primer AI 해커톤 참가 후기 – Actonix를 출품하며  (0) 2026.03.10
Vercel 요청 페이로드 4.5MB 제한 트러블슈팅과 Presigned URL 아키텍쳐 도입  (0) 2026.02.08

'Web'의 다른글

  • 현재글Vercel 내부 시스템 무단 접근 사고 - 26.04.20

관련글

티스토리툴바