breakinglog
인기 TypeScript 검증 라이브러리 Zod 4.6.6에서 악성 코드가 발견됐다는 소식이 10월 12일 확산됐지만, 문제의 코드는 실제 npm 배포판에 포함되지 않은 것으로 확인됐습니다. 9월 21일 Zod의 공개 소스 저장소에 악성 코드가 들어간 공격 자체는 사실입니다. 그러나 저장소에 침입한 것과 사용자가 설치하는 npm 패키지가 오염된 것은 다른 사건입니다.
Zod는 입력값을 검사하는 라이브러리로, 일반 웹 서비스뿐 아니라 MCP TypeScript SDK와 같은 AI 도구 개발에도 사용됩니다. 현재 설치된 Zod에 악성 코드가 있다고 단정하거나 모든 4.6.6 사용자가 긴급히 삭제해야 한다고 안내할 근거는 없습니다.
10월 12일 왜 다시 논란이 됐나요?
Zod의 공식 v4.6.6 릴리스 페이지는 10월 11일 공개됐습니다. 여기에 9월의 의심스러운 커밋 d821685이 변경 기록으로 표시됩니다. 하지만 이후 해당 변경을 되돌린 커밋도 같은 기록에 포함돼 있습니다. 릴리스 화면에 악성 커밋이 보인다는 사실만으로 최종 배포 파일에도 악성 코드가 들어갔다고 해석할 수는 없습니다.
이 문제의 실제 발생 시점은 2026년 9월 21일입니다. GitHub의 당시 보안 사고 보고서는 Zod와 standard-schema, nub의 공개 저장소에 공통된 악성 코드가 들어갔다고 기록했습니다. 따라서 오늘 새로 감염됐다는 설명도 부정확합니다.
공격자가 무엇을 시도했나요?
의심스러운 변경은 정상적인 코드 수정처럼 보이는 커밋 안에 원격 코드를 가져오는 로더를 숨겼습니다. 이 로더는 공개 이더리움 RPC 서비스를 조회해 외부 전달 주소를 얻고, 그곳에서 추가 JavaScript와 데이터를 내려받아 실행하도록 설계됐습니다. 정상적인 입력값 검증과 무관한 동작입니다.
관련 코드가 GitHub에 존재했다는 것은 확인됐지만, GitHub 보안 보고서에 따르면 Zod와 standard-schema의 악성 변경은 npm 게시 절차에 도달하지 않았습니다. 같은 공격에 연루된 @nubjs/nub@0.9.4만 npm 게시 검증 단계에 들어갔고, 이 버전은 악성 코드 검사에 차단돼 일반 설치가 가능한 상태로 공개되지 않았습니다.
그렇다면 Zod 4.6.6이 안전하다는 근거는?
Zod 유지보수자 콜린 맥도널은 사고 보고서에 남긴 답변에서 공격자가 npm 게시 토큰이 아닌 Git 푸시 자격증명을 탈취했을 가능성을 설명했습니다. Zod는 이미 신뢰 기반 게시(trusted publishing)와 승인 절차가 별도로 있는 GitHub 환경을 사용했으므로, 코드 저장소에 대한 쓰기 권한만으로는 악성 버전을 배포할 수 없었다는 설명입니다.
Zod의 10월 11일 공식 릴리스는 공격을 취소하는 변경이 반영된 이후의 커밋 284243f를 가리킵니다. GitHub 사고 보고서와 공식 릴리스 기록은 악성 코드가 정상 npm 배포로 이어지지 않았다는 판단을 뒷받침합니다. 다만 이번 작성 환경에서는 npm 패키지 파일을 직접 내려받아 재검사하지 못했습니다.
중요한 차이도 있습니다. Zod는 릴리스 승인 장치가 차단했고, nub는 npm의 사전 악성 코드 스캔이 배포를 차단했습니다. 두 패키지를 모두 npm 스캐너가 막았다고 표현하면 사고의 핵심을 놓치게 됩니다.
AI 에이전트와 MCP 개발자는 무엇을 확인하면 되나요?
MCP TypeScript SDK 공식 문서는 일부 버전에서 zod를 필수 피어 의존성으로 안내합니다. 따라서 Zod에 대한 보안 경보는 AI 에이전트, MCP 서버 및 도구 스키마를 만드는 팀에도 영향을 줍니다. 그러나 공식 npm 배포판의 오염 여부와 개별 프로젝트가 설치한 소스의 출처는 분리해서 확인해야 합니다.
프로젝트의 의존성 버전은 터미널에서 npm ls zod로 확인할 수 있습니다. 정상 레지스트리의 4.6.6을 설치했다는 사실 자체는 이번 공개된 악성 커밋 실행의 증거가 아닙니다. 반대로 9월 21일 당시 공격 커밋을 직접 체크아웃하거나 저장소 소스를 사용한 개발 환경이라면, 해당 파일을 실행한 적이 없는지 설치 스크립트와 작업 기록을 별도로 살펴봐야 합니다.
공식 사고 보고 이후 Zod 유지보수자는 자신이 관리하는 npm 패키지를 승인된 워크플로에서만 단계적으로 게시하고 2단계 인증을 요구하는 방식으로 옮겼다고 밝혔습니다. 이번 사건이 보여준 교훈은 “Zod 4.6.6 전체가 위험하다”가 아니라, 코드 변경 권한과 실제 배포 권한을 분리하는 보안 장치가 공급망 공격을 막는 데 실효성이 있었다는 점입니다.
