에스코어 인사이트
원문에 앞서 국내 개발·보안 조직이 함께 점검할 만한 사항을 간단히 정리했습니다.
•
패키지·버전 신뢰 검증: 기존에 사용해 온 메인테이너의 패키지라도 버전별 출처·게시 이력·무결성·변경 내용을 확인한 뒤 반입
•
설치 스크립트 실행 통제: 개발자 PC와 CI/CD에서 preinstall 등 의존성 설치 스크립트의 실행 범위를 제한하고 예상하지 못한 런타임 다운로드를 차단·모니터링
•
자격증명 노출 대응: 감염이 의심되는 시스템에서 악성코드와 지속성 메커니즘을 제거하고 npm·GitHub·클라우드·Vault·Kubernetes·CI/CD 자격증명을 폐기·교체한 뒤 검증된 구성요소로 재빌드
핵심 요약
•
•
악성 preinstall 훅이 실행되면 npm, GitHub, 클라우드, Kubernetes, Vault, CI/CD 등의 자격증명을 탈취하고, 확보한 게시 권한으로 다른 패키지까지 감염시킵니다.
•
영향을 받은 버전을 설치했다면 해당 환경이 침해됐을 가능성을 전제로 대응해야 합니다. 자격증명을 폐기하기 전에 악성코드와 지속성 메커니즘을 먼저 제거하고, 안전성이 확인된 구성요소로 다시 빌드해야 합니다.
2026년 8월 4일 Shai-Hulud가 npm의 keyv와 cacheable 관련 패키지에서 다시 발견됐으며, 이후 @servicetitan 네임스페이스를 비롯해 여러 메인테이너의 패키지로 빠르게 확산했습니다.
영향을 받은 릴리스에는 정상 패키지를 통해 유포되는 자격증명 탈취 악성코드가 포함돼 있으며, 이를 통해 다른 npm 패키지까지 감염이 확산될 수 있습니다. 패키지 자체는 정상이라도 특정 버전은 악성코드에 감염됐을 수 있으므로 주의해야 합니다.
무슨 일이 있었나?
공격자는 침해된 GitHub 메인테이너 계정과 탈취한 자격증명으로 확보한 게시용 계정을 이용해 정상 npm 패키지의 악성 버전을 배포했습니다. 여기에는 @servicetitan 네임스페이스의 패키지에 접근할 수 있는 계정도 포함됐습니다. 영향을 받은 릴리스에는 setup.mjs를 호출하는 악성 preinstall 훅이 포함돼 있습니다.
의존성 라이프사이클 스크립트를 실행할 수 있는 환경에서는 로더가 독립 실행형 Bun 런타임을 내려받은 뒤, Math_Symbol.js 또는 Math_Init.js라는 이름의 난독화된 2단계 페이로드를 실행합니다. npm 12는 승인되지 않은 의존성 설치 스크립트를 기본적으로 차단하지만, 이전 npm 버전이나 해당 스크립트의 실행을 허용하도록 구성된 환경에서는 이 훅이 여전히 실행될 수 있습니다.
패키지 자체는 정상적으로 동작하는 것처럼 보여도, 실행 과정에서 주변 환경이 침해될 수 있습니다. 악성코드는 로컬 파일, 환경 변수, 실행 중인 프로세스, 클라우드 메타데이터 서비스, Kubernetes 서비스 계정, Vault 위치를 검색해 npm, GitHub, 클라우드, CI/CD, 데이터베이스, SSH, 결제, 메시징 및 기타 자격증명을 찾습니다.
이후 수집한 데이터를 암호화해 외부로 유출합니다. npm 게시 권한을 확보하면 피해자가 관리하는 다른 패키지를 찾아 같은 악성 훅과 페이로드를 삽입하고 새 버전으로 게시합니다.
이 과정은 다음과 같이 반복됩니다.
1.
신뢰받는 메인테이너 계정이나 게시용 자격증명을 침해합니다.
2.
정상 패키지를 통해 악성코드를 배포합니다.
3.
개발자 시스템이나 CI 환경에서 자격증명을 탈취합니다.
4.
탈취한 자격증명으로 더 많은 패키지를 침해합니다.
5.
이 과정을 반복합니다.
Bun을 추가로 사용하면 실행 단계가 하나 더 늘어나며, Node.js 중심의 보안 통제를 벗어나 페이로드가 실행될 가능성도 있습니다. 탐지 단서로는 node의 setup.mjs 실행, Bun 아카이브 다운로드, Bun을 통한 Math_Symbol.js 또는 Math_Init.js 실행, 임시 Bun 파일 생성, npm·GitHub·클라우드 메타데이터 서비스나 공격자 인프라로 향하는 비정상적인 외부 통신 등이 있습니다.
Shai-Hulud의 지속성과 진화
기존 Shai-Hulud 캠페인은 2025년 9월 처음 관찰됐습니다. 당시에도 악성 npm 패키지가 단순한 정보 탈취를 넘어 추가 공격으로 이어질 수 있다는 점이 확인됐습니다.
이번 캠페인에서도 Shai-Hulud 악성코드 계열의 전형적인 공격 방식이 그대로 나타났습니다. 신뢰받는 패키지를 침해해 자격증명을 탈취하고, 확보한 게시 권한으로 오픈소스 생태계 전반에 공격을 확산시킵니다.
이전 Shai-Hulud npm 활동에서는 악성코드가 일회성 자격증명 탈취에 그치지 않고 탈취한 토큰을 이용해 추가 패키지를 오염시킬 수 있다는 점이 확인됐습니다. 이후 Miasma 공격 물결에서도 같은 공격 방식을 유지하면서 실행 방식과 난독화 기법을 계속 바꿨습니다.
Mini Shai-Hulud는 기존 수법에 다음 기법을 추가하거나 강화했습니다.
•
2단계 페이로드를 실행하기 위해 Bun을 내려받습니다.
•
GitHub와 도메인 기반의 별도 데이터 유출 경로를 사용합니다.
•
AI 코딩 도구와 IDE 설정을 표적으로 삼습니다.
•
감염된 호스트에서 악성코드가 다시 실행되도록 지속성을 확보합니다.
•
신뢰받는 계정과 게시 워크플로를 통해 침해된 패키지를 다시 게시합니다.
Microsoft Threat Intelligence는 조사 대상 패키지에서 일관된 감염 패턴을 확인했으며, 한 공격자가 여러 개의 탈취된 토큰을 사용하는 것으로 보인다고 분석했습니다. 이 사실만으로 모든 Shai-Hulud 캠페인의 배후가 같다고 단정할 수는 없지만, 기술적으로 이어지는 흔적은 뚜렷합니다.
영향을 받은 버전은 2,200개 이상
게시 시점에 Sonatype Research Labs가 sonatype-2026-005579와 관련해 추적 중인 구성요소 버전은 2,225개입니다.
Sonatype은 같은 패키지라도 버전별 위험이 다를 수 있어 패키지가 아닌 버전 단위로 추적합니다. 따라서 패키지명이 목록에 있는지만 볼 것이 아니라 실제 사용 중인 버전이 영향을 받는지 확인해야 합니다.
이 수치는 게시 시점의 현황으로, 최종 집계가 아닙니다. 초기에 공개된 패키지 목록만 믿기보다 Sonatype Guide나 소프트웨어 구성 분석(SCA) 데이터를 활용해 실제 애플리케이션이 영향을 받는지 확인해야 합니다.
조직은 어떻게 대응해야 하나?
개발자 워크스테이션, CI/CD 러너, 빌드 에이전트, 캐시, 컨테이너 이미지 등 관련 환경에 영향받은 패키지 버전이 남아 있는지 점검해야 합니다.
package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOM, 빌드 로그, 저장소·프록시 텔레메트리를 확인하고 다음 흔적이 있는지 점검해야 합니다.
•
setup.mjs, Math_Symbol.js, Math_Init.js
•
예상하지 못한 Bun 바이너리
•
.claude/settings.json 또는 .vscode/tasks.json의 의심스러운 변경
•
승인되지 않은 npm 패키지 배포 또는 비정상적인 GitHub 저장소 활동
영향을 받은 버전이 설치됐다면 패키지만 삭제해서는 충분하지 않습니다. 시스템을 격리하고 관련 로그를 보존한 뒤 외부 통신 흔적을 조사해야 합니다. 노출됐을 가능성이 있는 npm, GitHub, 클라우드, Vault, Kubernetes, CI/CD, SSH, 데이터베이스, 서비스 자격증명을 폐기·교체하기 전에 악성코드와 지속성 메커니즘을 먼저 제거해야 합니다.
그런 다음 안전성이 확인된 환경에서 침해되지 않은 것으로 검증된 패키지 버전으로 다시 빌드해야 합니다. 버전 번호가 더 높다고 해서 안전한 것은 아닙니다.
신뢰는 여전히 공격의 통로다
Mini Shai-Hulud npm 침해 사고에서도 Sonatype이 npm 공격에서 꾸준히 관찰해 온 패턴이 반복됐습니다. 공격자는 타이포스쿼팅이나 의존성 혼동, 낯선 신규 패키지를 이용하는 데 그치지 않고 신뢰받는 메인테이너와 패키지, 게시 워크플로 자체를 점점 더 노리고 있습니다.
많은 조직이 여전히 과거의 평판만으로 소프트웨어의 안전성을 판단합니다.
•
널리 쓰이는 패키지입니다.
•
메인테이너가 잘 알려져 있습니다.
•
오랫동안 유지돼 온 프로젝트입니다.
•
이전 버전은 안전했습니다.
•
버전에 출처 증명(provenance) 정보가 포함돼 있습니다.
•
정상적인 게시 절차를 거친 업데이트로 보입니다.
하지만 이런 조건만으로 지금 내려받는 패키지가 안전하다고 볼 수는 없습니다.
보안팀은 프로젝트의 과거 신뢰도에 기대기보다 새로 도입하는 패키지 버전이 실제로 어떤 동작을 하는지 검증해야 합니다. 악성 패키지가 개발자 워크스테이션이나 빌드 파이프라인에서 실행되기 전에 차단할 수 있는 사전 통제 체계도 필요합니다.
Sonatype Research Labs는 추가로 영향을 받은 구성요소나 기술적 세부 사항이 확인되면 조사를 이어가며 sonatype-2026-005579 정보를 갱신할 예정입니다. Sonatype은 신속하게 정보를 공유하되 연구 결과를 근거로 판단하고, 개발자와 보안팀이 바로 실행할 수 있는 대응 방안을 제시한다는 편집 원칙에 따라 내용을 업데이트합니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide