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

• 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) 수행

[GN⁺]

Hacker News 의견들

• 방금 공지가 업데이트됐고, 침해가 서드파티 AI 도구의 Google Workspace OAuth 앱 손상에서 시작됐다고 밝힌 점이 중요해 보였음
  조사 지원용 IOC도 공개됐고, 관리자라면 이 앱 사용 여부를 바로 확인하라는 내용이었음
  OAuth App은 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com이며, 원문은 Vercel 보안 공지에서 확인 가능함

  • Guillermo Rauch의 설명을 보면, Vercel 직원이 쓰던 Context.ai 고객 계정 쪽 침해가 출발점이었고, 그 뒤로 Vercel Google Workspace 계정과 환경까지 연쇄적으로 접근당한 것으로 보였음
    특히 non-sensitive 환경변수 열거를 통해 추가 접근이 가능했다는 설명이 눈에 띄었고, 공격자가 AI로 크게 가속된 고도화된 그룹 같다는 추정도 나왔음
    그런데도 아직 사용자 대상 이메일 공지가 없다는 점은 꽤 걱정스러웠음
  • OAuth 클라이언트 ID만 말하지 말고 실제 앱 이름도 공개해주면 좋겠다고 느꼈음
    상대를 바로 지목하고 싶지 않은 마음은 이해하지만, 서비스명을 숨기면 대응만 늦어지는 느낌이었음
  • 어차피 결국 드러날 텐데 왜 책임 있는 앱을 직접 명명하지 않는지 이해가 잘 안 갔음
  • 이미 그 앱이 삭제된 것처럼 보였음
  • 이 사건이 지난 10년간 웹 개발이 흘러온 방향의 자연스러운 결과처럼 느껴졌음
    요즘은 안정적인 기반 위에 쌓기보다 여러 서드파티 조합을 엮는 게 너무 당연해졌고, 그만큼 실패 지점도 많아졌음
    결국 보안은 가장 약한 고리만큼만 강하다는 점이 다시 드러났고, 특히 vibe-coded 느낌의 AI 도구에 비즈니스를 얹는 건 분명한 리스크라고 생각했음
    이 방향을 계속 밀어야 하는지, 그리고 복잡성이 얼마나 더 커져야 되돌아볼지 스스로 묻게 됐음

• Claude Code 추천 스택 분석을 보면, 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였고, 내가 본 시점은 동부시간 오후 4시 22분 기준이었음
  • 솔직히 왜 이걸 여기서 먼저 읽고 있는지 이해가 안 갔음
    1년 넘게 돈 내는 고객인데, 정작 회사 이메일보다 뉴스 애그리게이터가 먼저 알려주는 상황이 황당했음
  • 작년에도 Vercel이 Next 미들웨어 취약점 대응을 서툴게 처리했던 일이 있었고, 그래서 이번도 완전히 새롭진 않게 느껴졌음
    관련 맥락은 HN 스레드와 당시 반응에서 볼 수 있었음
  • 보안은 정말 어렵고, 내가 신뢰하는 벤더는 AWS, Google, IBM 셋뿐이라는 생각이었음
    그 외는 대체로 문제를 자초하는 선택처럼 느껴졌음
  • 비싼 값을 내는 이유는 보안과 안정성 기대도 있지만, 버튼 몇 번으로 바로 배포되는 편의성도 크다고 느꼈음
    다만 나는 이제 그 편의성에 기대지 않기로 했고, Render에서 linode로 전부 옮겼음
    예전엔 Render에 월 50달러 넘게 냈는데 지금은 3~5달러 수준이라, 앞으로는 그런 호스팅 업체를 다시 쓸 생각이 거의 없었음

• “Vercel이 어떤 시스템이 뚫렸는지 밝히지 않았다”는 문장을 보니, 보안 전문가는 아니어도 이건 꽤 납득하기 어려운 태도처럼 느껴졌음
  고객이 영향을 이해하도록 돕기보다 자기들 방어에 더 치중하는 인상도 들었음

  • 한편으로는 시스템 이름을 더 구체적으로 말해도 꼭 더 유용하진 않을 수 있다고 생각했음
    예를 들어 GitHub에서 잘 알려지지 않은 하위 서브시스템 X가 뚫렸다고 말해봐야, 이미 나온 “일부 고객 환경이 손상됐다” 수준보다 실질적으로 더 도움이 안 될 수도 있겠다는 생각이었음

• 공지에 IOC가 추가된 걸 다시 보니, 이번 사건이 Google Workspace OAuth 앱 손상에서 시작됐다는 점은 확실히 커뮤니티 전체에 중요한 정보였음
  관리자와 계정 소유자는 해당 앱 식별자를 바로 확인해봐야겠다고 느꼈고, 자세한 내용은 Vercel 공지에 있었음

  • 저 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에서는 크래시를 재현하지 못했음
    영상도 남겨봤고, uBlock Origin Lite를 써서 그게 원인인가 싶었지만 꺼도 여전히 안 터졌음
    재현됐으면 조금 재밌었을 것 같다는 생각도 했음
  • 2021년쯤 Linux에서 GitHub 드롭다운 메뉴를 열면 시스템 전체가 죽던 Chromium 버그가 떠올랐음
    한동안 그랬다가 결국 고쳐졌던 기억이 있었음
  • 나도 Windows 11의 Chrome에서 같은 현상을 봤음
    다만 URL로 Vercel 홈을 한 번 직접 연 뒤에는 로고를 눌러도 더는 크래시가 안 났음
  • 내 환경은 MBP M4 Max와 Chrome 146.0.7680.178인데 크래시는 없었음
    대신 이제 Finish update 버튼을 누르기가 좀 꺼려졌음

• 관련 정보로 HN 다른 스레드와 몇 개의 X 글을 같이 보고 있었음
  Theo의 첫 언급에선 신빙성이 있어 보인다고 했고, 후속 글에선 sensitive로 표시된 env var는 안전하며 표시되지 않은 값은 예방 차원에서 교체하라고 했음
  또 다른 글에선 이 유형의 해킹이 어떤 호스트에도 일어날 수 있다고 했고, 또 다른 언급에선 ShinyHunters 연관 가능성이 거론됐음

  • sensitive로 표시되지 않은 값이 정말 민감하지 않다면, 굳이 교체할 이유는 없다고 생각했음
    만약 반드시 교체해야 하는 값이라면 애초에 그건 민감정보였고 sensitive로 표시했어야 했다는 뜻 아닌가 싶었음
  • 이 Theo라는 사람이 누구길래 여러 사람이 계속 인용하는지 궁금했음
    지금 시점에서는 실질적인 내용이 아주 많아 보이진 않았음

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

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

• 혹시 이게 실제로는 많은 고객이 영향을 받았는데, 떠나면 곤란한 큰 고객들만 subset으로 부르는 상황인가 하는 의심도 들었음

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

[click]

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

[slowandsnow]

전 클로드 쓰면 일본어가 자주 나오던데요. 어제도 그랬음