Vercel가 고객 비밀을 평문으로 저장하고 그걸 기능이라 불렀습니다

Vercel이 침해를 당했습니다. 공격자는 탐지되기 전까지 약 두 달간 내부에 머물렀습니다. 공격자는 Vercel의 선택적 "민감함(sensitive)" 플래그를 사용하지 않은 모든 프로젝트의 고객 환경 변수 — API 키, 데이터베이스 비밀번호, 서명 키, 토큰 — 를 열거하고 복호화했습니다.

공격 경로는 이렇습니다. Context.ai라는 서드파티 AI 도구가 침해당했고, 공격자는 그 거점으로 Vercel 직원의 Google Workspace 계정을 장악했습니다. 그리고 그곳에서 Vercel 내부 시스템으로 넘어간 뒤 비밀 정보를 읽기 시작했습니다.

이 데이터는 현재 BreachForums에서 200만 달러에 판매되고 있다고 알려져 있습니다.

기본값이 아니었던 "민감함" 체크박스

여기가 중요한 부분입니다.

Vercel에는 환경 변수가 두 종류 있습니다. 일반 변수는 "저장 시 암호화"되지만 Vercel 시스템이 복호화해 읽을 수 있습니다. 그리고 "민감함" 변수는 Vercel的说法대로 내부 접근조차 막는 추가 암호화를 사용합니다.

공격자는 모든 일반 변수를 읽을 수 있었습니다. "민감함" 변수만 보호된 것이었죠.

문제는 "민감함"이 선택 사항이었다는 점입니다. 기본값이 아니었습니다. 체크박스를 선택하지 않고 DATABASE_URL이나 STRIPE_SECRET_KEY, JWT_SIGNING_KEY를 설정한 개발자 — 대부분이 그렇습니다 — 의 값은 내부 접근 권한을 가진 공격자가 복호화할 수 있는 형태로 남아 있었습니다.

Vercel의 사후 권고는 이렇습니다. "암호화된 저장을 위해 민감 환경 변수 기능을 활성화하세요." 바꿔 말하면, 당신이 비밀을 보호하고 있다고 가정했던 암호화는 사실 우리로부터, 그리고 우리 시스템에 침입한 누구로부터도 비밀을 보호하고 있지 않았다는 뜻입니다.

두 달간의 체류 시간

최초 침해는 2026년 2월에 발생했습니다. Vercel이 첫 보안 공지를 게시한 것은 4월 19일입니다. 공격자가 내부 시스템에 접근할 수 있었던 시간이 대략 두 달인 셈입니다.

Vercel 자체 보안 팀은 공격자를 "운영 속도와 Vercel 제품 API 표면에 대한 깊은 이해를 고려할 때 매우 정교하다"고 표현했습니다. 당신의 인프라를 호스팅하는 회사가 공격자가 예상보다 자사 시스템을 잘 이해하고 있었다고 말한다면, 한 번쯤 생각해볼 만합니다.

그 두 달 동안 공격자는 영향을 받은 고객 프로젝트 전반에서 접근 가능한 모든 환경 변수를 열거할 시간이 있었습니다. 유출할 시간도, 판매할 시간도 있었습니다.

OAuth 공급망

진입 지점은 Vercel 자체 코드조차 아니었습니다. 한 Vercel 직원이 Google OAuth를 통해 Context.ai — AI 생산성 도구 — 를 승인했습니다. Context.ai가 침해당하자 공격자는 그 OAuth 부여가 제공한 모든 권한을 그대로 물려받았습니다.

이 패턴은 계속 반복되고 있습니다. 조직은 주요 인증을 신중하게 잠그고 나서, 종종 더 약한 자체 보안 태세를 가진 서드파티 도구에 OAuth 토큰을 나눠줍니다. 체인에서 앱 하나만 침해당해도 공격자는 직원의 접근 권한을 물려받습니다.

침해된 OAuth App ID는 공개되어 있습니다: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. 조직에서 이 앱을 승인했다면 지금 바로 철회하세요.

해야 할 일

Vercel에서 배포한다면:

• 모든 환경 변수를 즉시 교체하세요 — "영향을 받았는지" 확인을 기다리지 마세요
• 앞으로 모든 환경 변수에 민감 플래그를 활성화하세요
• Google Workspace OAuth 앱 권한을 감사하고 적극적으로 사용하지 않는 것은 철회하세요
• 2026년 2월~4월 사이의 예상치 못한 변경이 있는지 Vercel 배포 로그를 검토하세요
• Vercel에 저장되어 있던 자격 증명을 사용한 비인가 접근이 있는지 하위 서비스(데이터베이스, 결제 처리사, API)를 확인하세요

진짜 교훈

Vercel의 아키텍처는 내부 접근이 복호화할 수 있는 방식으로 고객 비밀을 저장했습니다. 더 강한 옵션을 제공하긴 했지만 기본값으로 만들지 않았습니다. 두 달 동안 아무도 그 비밀을 읽고 있는 공격자를 알아채지 못했습니다.

이것이 "우리를 믿으세요" 보안의 문제입니다. Vercel은 환경 변수를 저장 시 암호화했습니다 — 기술적으로는 사실입니다. 하지만 복호화 키는 Vercel이 쥐고 있었습니다. Vercel 시스템이 침해당했을 때, 당신의 비밀도 함께 침해된 것입니다.

대안은 제로 지식 아키텍처입니다. 서비스 제공자가 수학적으로 당신의 데이터를 복호화할 수 없는 구조입니다. "하지 않기로 선택한" 것이 아니라, 할 수 없는 것입니다. 아무리 내부 침해가 일어나고, 어떤 비위 직원이 나타나고, 인프라에 두 달간 머무는 정교한 공격자가 온다 해도, 서버가 복호화 키를 한 번도 갖고 있지 않았다면 읽을 수 있는 것은 없습니다.

Vercel은 고객에게 진짜 암호화를 선택하려면 체크박스를 선택하라고 요구하고 있습니다. 물어볼 가치가 있는 질문은 이렇습니다. 처음부터 그게 유일한 옵션이 아니었을까요?