npm 패키지 323개를 오염시킨 ‘미니 샤이-훌루드’, AI 코딩 에이전트까지 노렸다

npm 공급망 공격이 또 터졌는데, 이번엔 꽤 세다

• 국내 프론트엔드 개발 환경에서 많이 쓰이는 시각화 오픈소스 패키지 300여 개가 한꺼번에 악성코드에 오염됨

  • 한국 시각 2026년 5월 19일 오전 10시 39분부터 11시 56분까지, 약 1시간 17분 동안 벌어진 일임
  • 글로벌 npm 레지스트리에 323개 패키지, 총 639개 악성 버전이 올라감
  • 짧게 지나간 사고처럼 보이지만, 설치 타이밍이 겹친 프로젝트는 그대로 맞을 수 있는 유형임

• 피해 범위가 프론트엔드 쪽에서 꽤 현실적임

  • 월 다운로드 420만 건 규모의 size-sensor가 포함됨
  • echarts-for-react, @antv/scale 같은 시각화 도구도 언급됨
  • 버전 범위를 느슨하게 잡아둔 프로젝트라면 깨끗한 설치(Clean Install)를 하는 순간 악성 버전이 들어올 수 있음

무서운 포인트는 ‘자가 증식’임

• 공격자는 공인 개발자 ‘에이툴’의 npm 계정을 탈취해 패키지를 무기화함

  • 악성코드는 ‘미니 샤이-훌루드’ 툴킷 기반으로 설명됨
  • 개발자가 패키지를 내려받는 즉시 실행되도록 설계됐음
  • 원본 저장소를 복사한 뒤 정식 코드 목록에는 잘 안 보이는 고아 커밋(Orphan Commit)을 만들어 공식 파일처럼 위장하는 임포스터 커밋(Imposter Commit) 기법도 쓰였음

• 진짜 문제는 악성코드가 웜(Worm)처럼 퍼졌다는 점임

  • 감염된 개발자 PC에서 npm 배포 토큰을 훔침
  • 그 개발자가 관리하는 다른 정상 패키지를 찾아 악성코드를 심고 강제로 재배포함
  • 그래서 해커 계정 하나가 아니라 여러 정상 개발자 명의로 악성 패키지가 도미노처럼 퍼질 수 있었음

• 탈취 대상도 npm 토큰에서 끝나지 않음

  • AWS, 쿠버네티스 같은 클라우드 핵심 인프라 자격증명까지 수집 대상에 들어감
  • 1패스워드 같은 로컬 비밀번호 관리자도 노렸다고 설명됨
  • 개발자 노트북 하나가 빌드·배포·클라우드 권한의 관문이 되는 현실을 제대로 찌른 셈임

AI 코딩 에이전트도 공격 표면이 됐다

• 이번 공격은 AI 코딩 에이전트의 설정 파일을 감염 경로로 삼음

  • 개발자가 프로젝트 폴더를 열기만 해도 악성코드가 실행되도록 유도함
  • PC 안의 다른 프로젝트까지 연쇄 오염시키는 흐름이 가능해짐
  • “AI 에이전트는 편한 도구”에서 “항상 켜져 있고 권한도 많은 로컬 자동화 주체”로 보안 관점이 바뀌어야 하는 이유임

• 서명 체계를 통과하는 ‘신원 세탁’도 들어감

  • 공격자는 탈취한 깃허브 토큰을 공식 npm 배포 토큰으로 교환함
  • 겉으로는 합법적인 발행자처럼 보이게 만들었음
  • 그 결과 정품 인증서 서명 체계까지 통과하면서 정적 분석 도구가 정상 파일로 오인할 여지가 생김

명령제어 서버 대신 깃허브 검색창을 썼다

• 탈취한 정보는 정상 관측 데이터처럼 위장돼 빠져나감

  • 시스템 관측 데이터(OpenTelemetry)처럼 보이게 만든 가짜 엔드포인트로 암호화 전송됐다고 설명됨
  • 엔드포인트는 t[.]m-kosche[.]com/api/public/otel/v1/traces 형태로 언급됨
  • 보안 장비 입장에서는 “이거 그냥 관측 데이터 아닌가?” 하고 지나칠 수 있는 구간을 노린 셈임

• 명령 전달에는 깃허브 검색 API를 데드드롭(Dead drop)처럼 악용함

  • 공격자가 직접 명령제어(C2) 서버를 세우면 추적당하기 쉬움
  • 대신 깃허브 어딘가에 특정 키워드와 코드를 올려둠
  • 감염된 컴퓨터들이 백그라운드에서 깃허브 검색 API를 주기적으로 뒤져 그 명령을 찾아 실행하는 구조임

sequenceDiagram
    participant 공격자
    participant 깃허브
    participant 감염된개발자PC
    participant npm레지스트리
    participant 클라우드인프라
    공격자->>깃허브: 키워드와 명령 코드 게시
    감염된개발자PC->>깃허브: 검색 API로 명령 탐색
    감염된개발자PC->>npm레지스트리: 탈취한 배포 토큰으로 악성 버전 재배포
    npm레지스트리->>감염된개발자PC: 다른 프로젝트 설치 과정에서 악성 패키지 유입
    감염된개발자PC->>클라우드인프라: 자격증명 수집 시도
    감염된개발자PC->>공격자: 관측 데이터처럼 위장해 탈취 정보 전송

당장 봐야 할 체크리스트

• 5월 19일 전후에 생성되거나 갱신된 패키지 잠금 파일을 확인해야 함

  • package-lock.json 같은 파일에서 문제 시점의 버전이 들어왔는지 봐야 함
  • 특히 시각화 라이브러리나 간접 의존성으로 들어온 패키지는 놓치기 쉬움

• 빌드 인프라와 로컬 개발 환경의 자격증명을 재발급해야 함

  • 클라우드 토큰, API 키, npm 배포 토큰처럼 노출 가능성이 있는 값은 폐기와 재발급(Rotation)이 권고됨
  • “내 패키지는 배포 안 하니까 괜찮겠지”가 아니라, 설치 과정에서 로컬 비밀값이 털렸을 가능성까지 봐야 함

• AI 에이전트와 IDE 설정 파일도 검사 대상임

  • 프로젝트별 설정 파일, 자동 실행 훅, 숨겨진 스크립트를 확인해야 함
  • AI 코딩 에이전트가 프로젝트를 열 때 실행하는 설정이 있다면 특히 봐야 함

기술 맥락

• 이번 사건의 핵심은 npm 패키지 하나가 아니라 배포 권한 자체가 털렸다는 점이에요. 패키지 매니저는 원래 “공식 레지스트리에 올라온 정상 발행자의 버전”을 신뢰하거든요. 그런데 그 정상 발행자 신원이 탈취되면, 설치하는 쪽에서는 겉으로 보기엔 이상한 게 별로 없어요.

• 비인간 신원(NHI)이 중요하게 나온 이유도 여기에 있어요. npm 배포 토큰, 깃허브 토큰, 클라우드 키는 사람이 매번 로그인해서 쓰는 게 아니라 자동화 파이프라인과 도구가 들고 쓰는 권한이에요. 만료가 길고 다중 인증이 약하면 한 번 털렸을 때 공격자가 배포·재배포 흐름까지 가져갈 수 있어요.

• AI 코딩 에이전트 설정 파일이 위험해진 건, 요즘 에이전트가 단순 편집기를 넘어 프로젝트 문맥을 읽고 명령을 실행하는 쪽으로 움직이기 때문이에요. 프로젝트를 여는 행위가 곧 로컬 자동화 실행으로 이어질 수 있으면, 설정 파일은 사실상 실행 경로의 일부가 돼요.

• 그래서 대응도 단일 패키지 차단만으로 끝나기 어려워요. 특정 시점에 여러 패키지의 발행자가 동시에 바뀌었는지, 새 버전이 올라온 직후 바로 설치해도 되는지, 배포 토큰이 어디서 생성되고 언제 폐기되는지까지 봐야 해요. 공급망 보안이 이제 의존성 목록 관리에서 신원 수명주기 관리로 넘어가고 있는 셈이에요.