2026년 4월 19일, Vercel은 공격자가 타사 AI 도구(Context.ai)를 손상시키고, Vercel 직원의 Google Workspace 계정을 탈취한 후, "민감한 정보"로 표시되지 않은 환경 변수를 제한된 범위의 고객 프로젝트에서 읽었다고 확인했습니다. 지난 30일 이내에 Vercel에 배포한 것이 있다면, 귀하의 환경 변수 중 하나가 이미 타인의 손에 있을 가능성이 있다고 가정하고 빠르게 대응해야 합니다.

불편한 진실은 이렇습니다: 대부분의 개발자들은 "민감한 정보" 토글을 건드리지 않고 템플릿에서 .env 값을 그대로 배포합니다. 바로 공격자가 읽은 환경 변수의 유형입니다. 이 가이드는 다음 60분 동안 무엇을 확인하고, 무엇을 교체하고, 다음 플랫폼 침해가 앱을 깨뜨리지 않도록 스택을 강화하는 방법을 안내합니다.

TL;DR: 다음 60분 동안 할 6가지

다른 것은 몰라도 지금 바로 이 6가지를 하세요:

  • 프로덕션 브랜치에서 자동 배포를 일시 중지합니다.
  • vercel env pull을 실행하고 출력에서 비밀 패턴(sk_live_, AKIA, ghp_, eyJ)을 grep으로 검색합니다.
  • 민감하지 않은 환경 변수로 저장된 모든 API 키를 교체합니다(결제, 데이터베이스, 인증, 클라우드 제공자 키부터 시작).
  • Vercel의 "Sensitive" 환경 변수 토글을 사용해 교체된 비밀을 다시 추가한 후 재배포합니다.
  • 4월 1~20일에 대한 Vercel 활동 로그를 열어 인식하지 못한 배포, 로그인 또는 토큰 이벤트를 표시합니다.
  • 동일한 기간에 GitHub 조직 감사 로그를 검토하세요. 새로운 PAT, 배포 키 또는 워크플로 변경 사항을 찾습니다.

아래는 필요한 명령어, 패턴, 교체 순서와 함께 전체 분석 내용입니다.

2026년 4월 Vercel 침해에서 실제로 무슨 일이 일어났나요?

Vercel은 4월 19, 2026년에 공격자가 Context.ai(Vercel 직원이 사용하던 타사 AI 생산성 도구)를 손상시켰다고 공개했습니다. 공격자는 직원의 Vercel Google Workspace 계정을 탈취했고, Vercel의 내부 환경으로 이동한 후, "민감한 정보"로 표시되지 않은 환경 변수에 접근했습니다.

"민감한 정보"로 표시된 변수는 별도의 암호화된 읽기 경로를 사용하며, Vercel은 이들이 노출된 증거가 없다고 합니다. 그 외 모든 것(API 키, 데이터베이스 URL, JWT 비밀을 저장하는 일반 환경 변수)은 읽을 수 있었습니다. 이후 사이버범죄 포럼 게시물에서는 Vercel 데이터를 200만 달러에 판매하고 있다고 주장했지만, Vercel은 유출을 확인하지 않았습니다. 어쨌든, 안전한 조치는 Vercel이 직접 이메일을 보내지 않았더라도 교체 목적으로 침해를 가정하는 것입니다.

회사는 공격자를 "운영 속도와 Vercel 시스템에 대한 상세한 이해를 바탕으로 고도로 정교함"으로 평가했습니다. 즉, 이것은 스크립트 키디가 아니라는 뜻입니다. 시간을 소중히 여기세요.

내가 영향을 받았나요? 5분 안에 확인하는 방법

짧은 답: Vercel을 사용 중이고 "민감한 정보" 토글을 철저히 사용하지 않았다면 자신이 영향을 받았다고 생각하세요. 5분 안에 확인하는 방법:

  • Vercel의 활동 로그를 열고 2026년 4월 1일부터 지금까지 필터링합니다. 인식하지 못한 로그인, 토큰 생성 또는 배포를 찾습니다.
  • Google Workspace 관리자 → 보안 → API 컨트롤로 이동하여 공개된 손상 지표를 검색합니다: OAuth 클라이언트 ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. 승인된 경우 즉시 철회하세요.
  • 팀의 누가 Google SSO를 사용하여 Context.ai에 로그인한 적이 있는지 확인합니다. 있다면 해당 계정을 더 높은 위험도로 취급하세요.
  • Vercel 프로젝트의 환경 변수 탭을 확인합니다. "민감한 정보"로 표시되지 않은 변수의 수를 센다. 그것들이 모두 대상입니다.

Vercel에서 "We identified a security incident affecting your account"로 시작하는 이메일을 받았다면, 귀하는 확인된 영향을 받은 범주에 있습니다. 교체 섹션으로 건너뛰어 지금 바로 시작하세요.

60분 긴급 대응 매뉴얼

이는 영향 범위 순서대로 정렬됩니다. 단계를 건너뛰지 마세요. 각 단계는 다음 단계를 가능하게 합니다.

1단계: 환경 고정 (처음 10분)

법의학적 분석을 시작하기 전에 출혈을 멈추세요:

  • main/프로덕션 브랜치에서 자동 배포를 일시 중지합니다 (Vercel 대시보드 → 프로젝트 → 설정 → Git).
  • 더 깊은 침해가 의심되면 github.com/organizations//settings/installations에서 Vercel GitHub 앱을 임시로 비활성화합니다.
  • Vercel 감사 로그를 CSV로 내보내 로컬에 저장합니다. 나중에 이것이 GDPR 보고 대상 사건이 되면 필요합니다.
  • Observability Plus를 활성화합니다 (체험판 일주일이라도). 확장된 로그를 유지하기 위함입니다.

이것은 "증거 보존" 단계입니다. 로그를 스냅샷하기 전에 교체하면 타임라인이 손상됩니다.

2단계: 환경 변수를 가져와 비밀을 스캔합니다

터미널을 열고 다음을 실행하세요:

vercel env pull

출력을 스캔합니다. 가장 빠른 방법은 GitGuardian의 CLI입니다:

ggshield secret scan file .env

아무것도 설치하고 싶지 않다면, 이 패턴들로 grep을 사용하세요. 환경 파일에서 유출된 비밀의 80%를 잡습니다:

grep -E "(sk_live_|AKIA|ghp_|eyJ|mongodb://|redis://|DATABASE_URL)" .env

모든 매치는 교체 후보입니다. 아직도 자격 증명인 일치하지 않은 모든 비밀 (DB URL, Redis 비밀번호, 웹훅 서명 키)도 교체 후보입니다. grep은 명백한 것들만 잡습니다.

3단계: 우선순위 순서로 비밀을 교체합니다 (알파벳순 아님)

대부분의 팀이 여기서 실수합니다. 40개의 비밀을 무작위 순서로 교체하면, 세션 키가 모든 활성 로그인을 무효화하고, 지원 티켓이 폭주합니다. 계층별로 하세요:

계층 0 — 다음 30분 내에 교체:

  • 모든 GitHub Personal Access Token (세분화 및 클래식)
  • 모든 기존 Vercel 민감한 환경 변수 토큰
  • 배포 보호 토큰

계층 1 — 오늘 교체:

  • 결제 처리자 비밀 키 (Stripe sk_live_, Adyen, Braintree)
  • AUTH_SECRET, NEXTAUTH_SECRET, JWT 서명 키, 세션 쿠키
  • 쓰기 액세스 권한이 있는 데이터베이스 연결 문자열 (DATABASE_URL, Mongo, Redis)
  • 클라우드 제공자 키 (AWS IAM, GCP 서비스 계정, Azure 클라이언트 비밀)
  • 웹훅 서명 비밀 (발신자와 수신자 모두 업데이트)

계층 2 — 이번 주에 교체:

  • 타사 SaaS 키 (이메일, SMS, 분석, CRM)
  • OAuth 클라이언트 비밀
  • SMTP 자격 증명, CDN 키

계층 3 — 편할 때 교체:

  • 읽기 전용 분석 토큰, Sentry DSN, 공개/익명 키

중요한 작업 순서:

  • 데이터베이스의 경우: 이전 사용자를 철회하기 전에 새 사용자를 만들거나 교체 중에 사이트가 다운됩니다.
  • 세션 키의 경우: 로그아웃 이벤트를 계획하세요. 모든 활성 세션이 종료됩니다.
  • 웹훅의 경우: 같은 배포 윈도우에서 양쪽을 업데이트합니다.
  • 모든 환경 변수 변경 후 재배포합니다. Vercel은 런타임이 아니라 빌드 시간에 값을 베이킹합니다.

4단계: 모두 "민감한 정보"로 다시 추가합니다

새로운 값을 다시 넣을 때, 모든 것에 "민감한 정보" 토글을 켭니다. 민감한 값은 별도의 암호화된 경로를 사용하며, Vercel의 자체 공지에 따르면 이번 사건에서 노출되지 않았습니다. 이것은 대부분의 영향을 받은 고객을 구했을 한 번의 클릭 변경입니다.

5단계: 원치 않는 변경 사항에 대한 저장소 감사

main 브랜치의 HEAD를 4월 1일 이전의 알려진 좋은 커밋과 비교합니다. 다음에 중점을 두세요:

  • package.json 스크립트 — 특히 postinstall, prepare, preinstall
  • 락 파일 (package-lock.json, pnpm-lock.yaml)에서 예기치 않은 새로운 의존성
  • .github/workflows/*.yml에서 새로운 워크플로 또는 고정되지 않은 작업
  • vercel.json에서 빌드 명령 변경 또는 알 수 없는 도메인을 가리키는 의심스러운 재작성
  • next.config.js에서 새로운 헤더 또는 리다이렉트

npm 패키지를 게시한다면, npm view <pkg> time --json도 실행하고 귀하가 작성하지 않은 것이 배포되지 않았는지 확인하세요.

6단계: 다운스트림 사냥

공격자는 환경 변수에서 멈추지 않습니다. 그들을 사용합니다. 4월 1일부터 현재까지의 기간에 대해 다운스트림 시스템을 쿼리하세요:

  • AWS CloudTrail: 예기치 않은 CreateUser, AttachUserPolicy, S3 GetObject 버스트, 새로운 IP에서의 로그인.
  • 데이터베이스 감사 로그: 대량의 SELECT * 쿼리, 내보내기, 비정상 지역에서의 연결.
  • Stripe/Adyen: 새로운 API 키, 의심스러운 환불, 이상한 위치에서의 고객 생성.
  • 인증 제공자: 불가능한 여행 로그인, 승인되지 않은 비밀번호 재설정, 새로운 OAuth 앱.

...

출처 바로가기