# Vercel 보안 침해 확인, 해커는 탈취한 데이터 판매 중이라고 주장

> Clean Markdown view of GeekNews topic #28699. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28699](https://news.hada.io/topic?id=28699)
- GeekNews Markdown: [https://news.hada.io/topic/28699.md](https://news.hada.io/topic/28699.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-20T09:42:50+09:00
- Updated: 2026-04-20T09:42:50+09:00
- Original source: [bleepingcomputer.com](https://www.bleepingcomputer.com/news/security/vercel-confirms-breach-as-hackers-claim-to-be-selling-stolen-data/)
- Points: 1
- Comments: 2

## Topic Body

- **Vercel**이 내부 시스템에 대한 무단 접근이 발생한 보안 사고를 공식 확인, 현재 사고 대응 전문가 및 법 집행 기관과 협력 중  
- 침해의 원인은 서드파티 AI 도구인 **Context.ai**의 Google Workspace OAuth 앱이 손상되면서 Vercel 직원 계정이 탈취된 것  
- 공격자는 **민감하지 않은(non-sensitive) 환경 변수**를 열거해 추가 접근 권한을 획득했으며, 해당 변수는 미암호화 상태로 저장되어 있었음  
- **ShinyHunters**를 자처하는 해커가 해킹 포럼에서 접근 키, 소스 코드, 데이터베이스 데이터, API 키 등을 판매한다고 주장하며 **200만 달러 몸값**을 요구  
- Vercel은 Next.js, Turbopack 등 **오픈소스 프로젝트의 안전성**을 확인했으며, 고객에게 환경 변수 검토와 민감 변수 기능 활성화를 권고  
  
---  
  
### 보안 사고 개요  
- Vercel은 JavaScript 프레임워크에 특화된 클라우드 호스팅 및 배포 인프라 플랫폼으로, **Next.js** 개발사이자 서버리스 함수, 엣지 컴퓨팅, **CI/CD 파이프라인** 서비스 제공  
- 보안 공지를 통해 내부 시스템에 대한 **무단 접근(unauthorized access)** 이 발생했음을 공식 확인  
- 일부 고객(limited subset)이 영향을 받았으며, 서비스 자체에는 영향이 없었다고 발표  
- 사고 대응 전문가를 고용하고 **법 집행 기관에 통보**, 조사 진행 중  
  
### 침해 경로 및 기술적 상세  
- 침해의 근본 원인은 서드파티 AI 플랫폼 **Context.ai**의 **Google Workspace OAuth 앱**이 손상된 것  
- Vercel CEO **Guillermo Rauch**가 X(구 트위터)에서 추가 상세 정보를 공개  
  - 공격자는 Vercel 직원의 Google Workspace 계정을 Context.ai 침해를 통해 탈취  
  - 이후 해당 계정에서 Vercel 환경으로 **접근 권한을 상승(escalate)**  
- 공격자는 **"민감하지 않음(non-sensitive)"으로 지정된 환경 변수**에 접근, 이 변수들은 암호화되지 않은 상태(not encrypted at rest)로 저장  
- Vercel은 모든 고객 환경 변수를 **완전 암호화(fully encrypted at rest)** 저장하며 다층 방어 메커니즘을 갖추고 있으나, "non-sensitive" 지정 변수가 취약점으로 작용  
- Google Workspace 관리자에게 다음 OAuth 앱 확인을 권고:  
  - `110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com`  
  
### 해커의 데이터 판매 주장  
- **ShinyHunters**를 자처하는 위협 행위자가 해킹 포럼에 Vercel 침해 및 데이터 판매 게시글 작성  
  - 판매 대상: **접근 키, 소스 코드, 데이터베이스 데이터**, 내부 배포 접근 권한, API 키(NPM 토큰, GitHub 토큰 포함)  
  - Linear 데이터를 증거로 제시하며 다수의 직원 계정 접근 권한 보유 주장  
- ShinyHunters 조직과 연관된 기존 위협 행위자들은 BleepingComputer에 이번 사건과 **무관하다고 부인**  
- 공격자가 공유한 텍스트 파일에는 Vercel 직원 정보 **580건**이 포함되어 있으며, 이름, Vercel 이메일 주소, 계정 상태, 활동 타임스탬프로 구성  
- 내부 **Vercel Enterprise 대시보드**로 보이는 스크린샷도 함께 공유  
- BleepingComputer는 해당 데이터와 스크린샷의 진위를 **독립적으로 확인하지 못함**  
- Telegram 메시지에서 위협 행위자는 Vercel과 접촉 중이며, **200만 달러의 몸값(ransom)** 을 요구했다고 주장  
  
### Vercel의 대응 및 고객 권고  
- Next.js, **Turbopack** 및 기타 오픈소스 프로젝트는 안전함을 확인  
- 대시보드에 환경 변수 **개요 페이지** 및 민감 환경 변수 관리를 위한 **개선된 인터페이스** 배포  
- 고객에게 권고하는 조치:  
  - **환경 변수(environment variables)** 검토  
  - **민감 환경 변수 기능(sensitive environment variable feature)** 활성화로 미사용 시 암호화 보장  
  - 필요 시 **시크릿 로테이션(secret rotation)** 수행

## Comments



### Comment 55873

- Author: neo
- Created: 2026-04-20T09:42:51+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47824463) 
- 방금 공지가 업데이트됐고, 침해가 **서드파티 AI 도구**의 Google Workspace OAuth 앱 손상에서 시작됐다고 밝힌 점이 중요해 보였음  
  조사 지원용 IOC도 공개됐고, 관리자라면 이 앱 사용 여부를 바로 확인하라는 내용이었음  
  OAuth App은 `110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com`이며, 원문은 [Vercel 보안 공지](https://vercel.com/kb/bulletin/vercel-april-2026-security-in...)에서 확인 가능함
  - [Guillermo Rauch의 설명](https://x.com/rauchg/status/2045995362499076169)을 보면, Vercel 직원이 쓰던 Context.ai 고객 계정 쪽 침해가 출발점이었고, 그 뒤로 Vercel Google Workspace 계정과 환경까지 연쇄적으로 접근당한 것으로 보였음  
    특히 **non-sensitive 환경변수** 열거를 통해 추가 접근이 가능했다는 설명이 눈에 띄었고, 공격자가 AI로 크게 가속된 고도화된 그룹 같다는 추정도 나왔음  
    그런데도 아직 사용자 대상 **이메일 공지**가 없다는 점은 꽤 걱정스러웠음
  - OAuth 클라이언트 ID만 말하지 말고 실제 **앱 이름**도 공개해주면 좋겠다고 느꼈음  
    상대를 바로 지목하고 싶지 않은 마음은 이해하지만, 서비스명을 숨기면 대응만 늦어지는 느낌이었음
  - 어차피 결국 드러날 텐데 왜 책임 있는 앱을 **직접 명명**하지 않는지 이해가 잘 안 갔음
  - 이미 그 앱이 삭제된 것처럼 보였음
  - 이 사건이 지난 10년간 웹 개발이 흘러온 방향의 자연스러운 결과처럼 느껴졌음  
    요즘은 안정적인 기반 위에 쌓기보다 여러 **서드파티 조합**을 엮는 게 너무 당연해졌고, 그만큼 실패 지점도 많아졌음  
    결국 보안은 가장 약한 고리만큼만 강하다는 점이 다시 드러났고, 특히 vibe-coded 느낌의 AI 도구에 비즈니스를 얹는 건 분명한 리스크라고 생각했음  
    이 방향을 계속 밀어야 하는지, 그리고 복잡성이 얼마나 더 커져야 되돌아볼지 스스로 묻게 됐음

- [Claude Code 추천 스택 분석](https://amplifying.ai/research/claude-code-picks/report)을 보면, Claude Code가 기본으로 특정 제공업체와 프레임워크를 권장하면서 웹을 더 **획일화**하고 있다고 느꼈음  
  이런 다양성 부족이 결국 사고가 날 때 **파급 반경**을 더 키우는 것 같았음
  - reddit에 올라오는 저노력 **vibe-coded 프로젝트**들을 보면 정말 자주 Vercel 위에 올라가 있었음  
    거의 기본 선택지처럼 굳어졌다는 인상이었음
  - 며칠 전 Claude Code로 새 CRUD React 앱을 억지로 만들어봤더니 기본값으로 Node JS와 NPM 의존성을 한가득 쏟아냈음  
    그래서 아예 **Node 없이** 해달라고 하자 곧바로 Python 백엔드로 다시 짜줬고, 의존성도 줄이는 방향으로 바꿨다고 스스로 설명했음  
    참고로 이건 그냥 버릴 결과물을 위한 실험이었지, vibe coding을 추천하려는 건 아니었음
  - 좋은 지적이지만 문제의 핵심이 Claude 자체라고는 생각하지 않았음  
    결국 **사용 방식**의 문제이고, Claude가 결정을 대신하게 두지 않도록 개발자를 더 잘 이끌어야 한다고 봤음  
    조언은 받을 수 있어도 최종적으로는 사람이 비판적으로 검토해야 하며, 그 점에서는 다른 팀원과 협업하는 것과 크게 다르지 않다고 느꼈음
  - AI가 **평균으로의 수렴**을 훨씬 빠르게 만들고 있다는 생각이 머릿속을 떠나지 않았음  
    인터넷도 원래 그런 경향이 있었지만, 이번에는 결이 좀 다르게 느껴졌음
  - 에이전트를 희생양으로 삼는 데 아주 반대하는 건 아니지만, 이런 문제는 사실 **인간들 사이**에서도 늘 보이던 패턴이라고 생각했음

- 예전에 보안 사고 대응팀에 있었던 사람으로서, 이번 대응팀이 얼마나 힘들지 공감은 됐음  
  그래도 첫 공지는 정말 **형편없는 커뮤니케이션**처럼 보였음  
  무슨 일이 있었는지는 말 안 하면서, 법 집행기관엔 알릴 만큼 심각했다는 식의 표현만 있고, 고객에게 주는 행동 지침은 "환경변수를 검토하라" 정도였음  
  그런데 고객 입장에선 그걸로 뭘 해야 하는지 너무 अस्प명했음. 값이 아직 있는지 보라는 건지, 이미 유출됐는지는 어떻게 판단하라는 건지 알 수 없었음  
  내 기준에선 즉시 비밀번호, 액세스 토큰, Vercel에 맡긴 민감정보를 전부 **회전(rotatation)** 하라고 말했어야 했고, 이어서 접근 로그와 고객 데이터 이상 징후를 감사하라고 안내했어야 했음  
  비싼 호스팅 비용을 내는 이유는 결국 보안과 안정성을 **전문적으로 관리**해주리라는 기대 때문인데, 지금은 초반 불확실성을 감안해도 지나치게 의도적으로 모호해 보였음
  - 사고 페이지를 보니, Vercel에서 **sensitive 표시**된 환경변수는 읽을 수 없도록 저장돼 있고 현재까지 접근 증거는 없다고 했음  
    다만 API 키, 토큰, DB 자격 증명, 서명 키 같은 비밀값이 sensitive로 표시되지 않았다면 잠재적으로 노출된 것으로 보고 우선적으로 교체하라고 했음  
    출처는 [incident page](https://vercel.com/kb/bulletin/vercel-april-2026-security-in...)였고, 내가 본 시점은 동부시간 오후 4시 22분 기준이었음
  - 솔직히 왜 이걸 여기서 먼저 읽고 있는지 이해가 안 갔음  
    1년 넘게 돈 내는 고객인데, 정작 **회사 이메일**보다 뉴스 애그리게이터가 먼저 알려주는 상황이 황당했음
  - 작년에도 Vercel이 Next 미들웨어 취약점 대응을 **서툴게 처리**했던 일이 있었고, 그래서 이번도 완전히 새롭진 않게 느껴졌음  
    관련 맥락은 [HN 스레드](https://news.ycombinator.com/item?id=43448723)와 [당시 반응](https://xcancel.com/javasquip/status/1903480443158298994)에서 볼 수 있었음
  - 보안은 정말 어렵고, 내가 신뢰하는 벤더는 AWS, Google, IBM 셋뿐이라는 생각이었음  
    그 외는 대체로 **문제를 자초**하는 선택처럼 느껴졌음
  - 비싼 값을 내는 이유는 보안과 안정성 기대도 있지만, 버튼 몇 번으로 바로 배포되는 **편의성**도 크다고 느꼈음  
    다만 나는 이제 그 편의성에 기대지 않기로 했고, Render에서 linode로 전부 옮겼음  
    예전엔 Render에 월 50달러 넘게 냈는데 지금은 3~5달러 수준이라, 앞으로는 그런 호스팅 업체를 다시 쓸 생각이 거의 없었음

- “Vercel이 어떤 시스템이 뚫렸는지 밝히지 않았다”는 문장을 보니, 보안 전문가는 아니어도 이건 꽤 **납득하기 어려운 태도**처럼 느껴졌음  
  고객이 영향을 이해하도록 돕기보다 자기들 방어에 더 치중하는 인상도 들었음
  - 한편으로는 시스템 이름을 더 구체적으로 말해도 꼭 더 유용하진 않을 수 있다고 생각했음  
    예를 들어 GitHub에서 잘 알려지지 않은 **하위 서브시스템 X**가 뚫렸다고 말해봐야, 이미 나온 “일부 고객 환경이 손상됐다” 수준보다 실질적으로 더 도움이 안 될 수도 있겠다는 생각이었음

- 공지에 IOC가 추가된 걸 다시 보니, 이번 사건이 **Google Workspace OAuth 앱** 손상에서 시작됐다는 점은 확실히 커뮤니티 전체에 중요한 정보였음  
  관리자와 계정 소유자는 해당 앱 식별자를 바로 확인해봐야겠다고 느꼈고, 자세한 내용은 [Vercel 공지](https://vercel.com/kb/bulletin/vercel-april-2026-security-in...)에 있었음
  - 저 OAuth 앱이 도대체 **어느 도구**인지 정말 궁금했음

- 나는 MacBook Pro와 Chrome 147.0.7727.56 환경인데, 페이지 좌상단 Vercel 로고를 누르자마자 Chrome 앱이 **즉시 크래시**났음  
  꽤 흥미로운 버그처럼 느껴졌음
  - 나는 Arch Linux인데, Chrome 147.0.7727.101에서는 같은 크래시가 재현됐고 Firefox 149.0.2나 Chromium 147.0.7727.101에서는 안 났음  
    지금 다들 Vercel이 뭔가 침해된 것 같다는 이야기를 읽다가, 웹페이지 크래시까지 재현해보고 있는 상황이 묘하게 웃겼음  
    물론 이런 집단 재현 놀이가 **절대 역효과**를 안 낼 리 없다는 생각도 들었음
  - 아쉽게도 내 쪽 Windows 11 Pro의 Chrome 147.0.7727.101에서는 크래시를 재현하지 못했음  
    [영상도 남겨봤고](https://imgur.com/a/pq6P4si), uBlock Origin Lite를 써서 그게 원인인가 싶었지만 꺼도 여전히 안 터졌음  
    재현됐으면 조금 **재밌었을 것** 같다는 생각도 했음
  - 2021년쯤 Linux에서 GitHub 드롭다운 메뉴를 열면 시스템 전체가 죽던 **Chromium 버그**가 떠올랐음  
    한동안 그랬다가 결국 고쳐졌던 기억이 있었음
  - 나도 Windows 11의 Chrome에서 같은 현상을 봤음  
    다만 URL로 Vercel 홈을 한 번 직접 연 뒤에는 로고를 눌러도 더는 크래시가 안 났음
  - 내 환경은 MBP M4 Max와 Chrome 146.0.7680.178인데 크래시는 없었음  
    대신 이제 **Finish update 버튼**을 누르기가 좀 꺼려졌음

- 관련 정보로 [HN 다른 스레드](https://news.ycombinator.com/item?id=47824426)와 몇 개의 X 글을 같이 보고 있었음  
  [Theo의 첫 언급](https://x.com/theo/status/2045862972342313374)에선 신빙성이 있어 보인다고 했고, [후속 글](https://x.com/theo/status/2045870216555499636)에선 sensitive로 표시된 env var는 안전하며 표시되지 않은 값은 예방 차원에서 교체하라고 했음  
  또 [다른 글](https://x.com/theo/status/2045871215705747965)에선 이 유형의 해킹이 어떤 호스트에도 일어날 수 있다고 했고, [또 다른 언급](https://x.com/DiffeKey/status/2045813085408051670)에선 ShinyHunters 연관 가능성이 거론됐음
  - sensitive로 표시되지 않은 값이 정말 **민감하지 않다면**, 굳이 교체할 이유는 없다고 생각했음  
    만약 반드시 교체해야 하는 값이라면 애초에 그건 민감정보였고 sensitive로 표시했어야 했다는 뜻 아닌가 싶었음
  - 이 Theo라는 사람이 누구길래 여러 사람이 계속 인용하는지 궁금했음  
    지금 시점에서는 실질적인 내용이 아주 많아 보이진 않았음

- 이런 사건은 현대 웹 생태계가 얼마나 **단일 실패 지점**에 집중돼 있는지 다시 떠올리게 했음  
  지금까지의 공개 자체는 비교적 투명하다고 느끼지만, 완전관리형 PaaS에 전적으로 기대는 선택의 **리스크 프로필**은 다시 계산하게 됐음

- “일부 제한된 고객”이라는 표현은 기술적으로는 99%여도 성립할 수 있어서, 꽤 **모호한 표현**처럼 들렸음

- 혹시 이게 실제로는 많은 고객이 영향을 받았는데, 떠나면 곤란한 큰 고객들만 **subset**으로 부르는 상황인가 하는 의심도 들었음
  - 어디까지나 추측이지만, “limited subset”이라는 표현이 좋은 소식이었던 경우는 드물었다고 느꼈음  
    보통 진짜 안심시킬 수 있으면 “사용자의 1% 미만”처럼 **구체적 수치**를 말하는데, 이번엔 그러지 않았음  
    그래서 아직 가시성이 부족하거나, 숫자가 마음에 들지 않는 것 아닐까 싶었음  
    그래도 대응팀이 얼마나 고생 중일지는 공감하고 있고, 앞으로는 더 공개적이고 투명하게 소통해주길 바라고 있었음

### Comment 55891

- Author: click
- Created: 2026-04-20T11:29:45+09:00
- Points: 1
- Parent comment: 55873
- Depth: 1

여기서도 힌디어 문자가 보이네요. 최근들어 openai, claude, google 무관하게 한국어 output에 힌디어가 섞여나오는 경우가 꽤 자주 발생하는데 한국어 데이터셋 라벨링을 인도인들이 해준걸까요?  
중국 모델은 한국어 응답에 중국어가 섞여나와서 불호였는데 최근에는 프론티어 모델들이 힌디어를 자꾸 섞으니까 오히려 중국 모델에 대한 거부감이 낮아졌어요