대참사로 이어질 뻔한 자피어 취약점 연쇄 공격: 평범한 실수 다섯 개가 어떻게 공급망을 위협했나

2단계: 최소 권한으로 ECR 저장소 정찰

이렇게 탈취한 AWS 역할(Role)의 이름은 allow_nothing_role이었습니다. 하지만 이름과 달리 네 가지 중요한 권한을 가지고 있었습니다. Amazon ECR(Elastic Container Registry)과 관련된 ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer가 바로 그것입니다 .

이 네 가지 권한만으로도 Docker 레지스트리 인증 토큰 없이 AWS API를 통해 직접 컨테이너 이미지를 내려받을 수 있었습니다. 연구원들은 이 권한을 이용해 1,111개의 실제 운영(Production) 저장소 목록을 확보하고, 레이어 다운로드 API를 통해 이미지를 추출했습니다 .

3단계: 컨테이너 이미지 히스토리 속 NPM 토큰 복구

내려받은 수많은 컨테이너 이미지 중 하나에서, NPM 배포용 토큰이 이미지 설정 히스토리 안에 그대로 남아 있는 것을 발견했습니다. 빌드 과정에서 Dockerfile의 ARG 명령어를 통해 토큰을 전달했고, 이 값이 이미지의 불변(Immutable)한 history[] 필드에 영구적으로 기록된 겁니다. 이미지를 내려받을 수만 있다면 누구든 이 토큰을 복구할 수 있는 상태였습니다 .

4단계: 2단계 인증마저 우회하는 NPM 배포 권한

찾아낸 NPM 토큰에는 세 가지 치명적인 속성이 포함되어 있었습니다.

action: write

name: null

bypass_2fa: true

즉, 2단계 인증(2FA) 같은 추가 보안 장치 없이도 NPM 레지스트리에 무엇이든 올릴 수 있는 사실상의 무제한 쓰기 권한이 주어진 셈입니다 .

5단계: 공급망을 통한 브라우저 코드 실행 시나리오

공격 체인의 마지막 목표였던 zapier-design-system 패키지는 zapier.com에 인증된 모든 사용자 세션에서 로드되는 핵심 요소입니다. 연구원들은 브라우저 개발자 도구로 이 로드 경로를 확인한 후, 실제 악성 패키지를 배포하지 않고 여기서 실증을 멈췄습니다 .

만약 공격자가 변조된 패키지를 배포했다면, 다음 릴리스 때 공격자가 통제하는 악성 자바스크립트가 인증된 zapier.com 도메인에서 실행될 수 있었습니다. 이 위치에서 공격자는 Zaps 생성, Tables 및 MCP 서버 조작은 물론, 인증된 사용자 권한으로 기존 연동 서비스를 마음대로 구동할 수 있었을 겁니다. 다만, 연결된 서비스의 OAuth 토큰이나 API 키는 서버 측에 남아 있어 브라우저에 직접 노출되지는 않았을 것이라고 연구원들은 덧붙였습니다 .

자피어의 발 빠른 대응

토큰 시큐리티는 2026년 2월 12일에 이 취약점을 자피어에 보고했습니다. 자피어는 불과 나흘 만에 보고서를 분류(Triage)하고, 유출된 NPM 토큰을 폐기했으며, 과도하게 설정된 AWS 역할 권한을 제한했습니다. 그리고 3월 5일에는 모든 보완 조치가 완료되었음을 확인했습니다. 자피어는 실제로 이 취약점이 악용된 정황은 발견되지 않았다고 밝혔습니다 .

보고서를 제출한 연구원들은 자피어 버그 바운티 프로그램의 최대 보상금인 3,000달러를 받았으며, 자피어는 다음 프로그램 검토 시 이 상한선을 재검토하기로 약속했습니다 .

참고로 이번 연구 공개는 2025년 11월 24일에 발생했던 실제 공급망 공격과는 별개의 사건입니다. 당시에는 '샤이 훌루드 2.0(Shai Hulud 2.0)'이라는 웜이 자피어의 NPM 계정을 탈취해 무려 425개의 패키지를 감염시킨 사건이 있었습니다 .

진짜 교훈: '틈새의 위험'을 누구도 감지하지 못한다

이번 연구를 이끈 토큰 시큐리티의 야이르 발릴티(Yair Balilti) 보안 연구 팀장은 핵심을 이렇게 짚었습니다.

"공격 체인의 모든 고리는 이미 알려진 패턴이었습니다. 진짜 취약점은 이들을 '조합'하는 구조 자체였고, 조합의 위험은 바로 여러 팀 사이의 틈새에서 발생합니다. Lambda 샌드박스, ECR/IAM, GitLab CI 토큰, NPM 배포, 브라우저까지 모든 구성 요소의 담당 팀이 다릅니다. 각 팀은 자기 구역만 보고 '이 정도면 괜찮다'고 결론 내릴만한 수준이었습니다. 위험은 모든 시스템을 가로지르는 공격 경로를 그려볼 때에만 드러납니다."

이 사례가 주는 교훈은 명확합니다. Lambda 팀은 '어차피 토큰을 지웠으니' 메모리 탐색 공격은 위험하지 않다고 생각했고, IAM 팀은 ECR 읽기 전용 권한만 부여했다고 생각했습니다. CI/CD 팀은 NPM 토큰을 빌드 ARG로 전달하는 게 관행이었고, NPM 팀은 쓰기 권한이 있는 토큰을 그저 관리했을 뿐입니다. 프론트엔드 팀 역시 디자인 시스템 패키지를 로드하는 게 당연한 업무였습니다. 각각의 판단은 개별적으로는 문제없어 보였지만, 다섯 개가 하나로 이어지자 파국으로 치닫는 공격 체인이 완성된 것입니다 .

이제 기업들은 더 이상 개별 구성 요소의 권한만 따로 감사해서는 안 됩니다. 시스템 경계를 넘나드는 공격 경로를 추적하는 통합적인 시각의 보안 검토가 필수적인 이유입니다. 사소해 보이는 구성들이 어떻게 상호작용하여 거대한 공격 사슬로 조립될 수 있는지 살펴야 합니다 .