미니 샤이-훌루드(mini Shai-Hulud)란 무엇인가요?

npm·PyPI 저장소에 정상 패키지로 위장해 배포되는 공급망 공격 악성코드 계열입니다. 설치 즉시 GitHub 토큰·AWS 키·npm 배포 토큰 등을 탈취하고, 이를 발판으로 클라우드 계정과 CI/CD 파이프라인까지 침투합니다.

npm 공급망 공격을 어떻게 탐지하나요?

npm audit은 CVE 등록 취약점만 잡으므로 postinstall 스크립트 기반 악성 패키지를 탐지하지 못합니다. package.json 의존성 이름을 알려진 악성 패키지 목록과 직접 대조하고, postinstall 스크립트에서 외부 통신 여부를 확인해야 합니다. CodeScan 같은 공급망 전용 스캐너 사용도 권장합니다.

GitHub Actions 토큰 탈취를 막는 방법은?

장기 AWS 액세스 키 대신 GitHub Actions OIDC 연동으로 임시 자격증명을 발급받는 방식으로 전환하세요. 워크플로우 파일에 permissions: 블록으로 최소 권한을 명시하고, package-lock.json을 커밋해 npm ci로 고정 설치하는 것이 기본입니다.

npm 공급망 공격이 클라우드 계정 침해로 이어지는 이유는?

CI/CD 환경에는 클라우드 배포를 위한 고권한 토큰이 환경변수나 시크릿으로 저장되어 있습니다. 악성 패키지가 이 토큰을 탈취하면 공격자는 AWS CLI·GitHub API 등을 통해 클라우드 인프라 전체에 접근할 수 있습니다. 토큰 하나로 측면 이동이 가능한 구조입니다.

미니 샤이-훌루드가 일반 공급망 공격과 다른 점은?

탈취한 npm 배포 토큰을 이용해 피해자가 관리하는 정상 패키지에 악성 버전을 추가 배포할 수 있습니다. 즉, 한 개발자 PC 감염이 해당 개발자가 배포하는 모든 패키지로 전파되는 자가전파(worm) 특성이 있습니다.

npm '미니 샤이-훌루드' 공급망 웜 — 토큰 탈취·클라우드 침해 [2026]

미니 샤이-훌루드(mini Shai-Hulud)는 npm·PyPI 저장소에 정상 패키지로 위장해 유포되는 공급망 공격 웜 계열이다. 패키지 설치와 동시에 숨겨진 스크립트가 실행되어 GitHub 토큰·AWS 키·npm 배포 토큰을 탈취하고, 이를 발판 삼아 CI/CD 파이프라인과 클라우드 계정까지 침투한다.

2026년 5월 11~12일 사이에 처음 공개됐고, 이후 변종이 빠르게 파생됐다. TanStack·Mistral AI·UIPath 등 주요 오픈소스 생태계 패키지가 피해를 입었으며, 한 축인 '미아즈마(Miasma)' 변종은 레드햇 관련 npm 패키지까지 영향을 미쳤다 (출처: 데일리시큐, 2026-05-14). 개별 악성 패키지의 공식 권고·CVE 매핑은 GitHub Security Advisories(GHSA)에서 패키지명으로 직접 조회할 수 있다.

SENTRIX는 보안 실무 10년 레드팀이 운영하는 보안 전문 기업이다. 이 글은 공격 체인의 전 과정을 분해하고, 개발팀과 DevOps가 지금 바로 적용할 수 있는 방어 체계를 정리한다.

한눈에 보는 미니 샤이-훌루드

Q. 미니 샤이-훌루드가 정확히 무엇인가요?: A. npm·PyPI 공급망 공격에 사용되는 악성코드 패밀리입니다. 원래 'TeamPCP'가 개발한 코드가 유출된 뒤 다수의 모방 공격자가 재사용하고 있습니다. 정상 패키지명을 철자 한 글자 차이로 흉내 낸 가짜 패키지에 삽입되어 배포됩니다 (출처: 데일리시큐, 2026-05-19).
Q. 어떻게 전파되나요?: A. 개발자가 npm install 또는 pip install로 악성 패키지를 설치하는 순간 postinstall 스크립트가 자동 실행됩니다. 추가 파일 실행 없이 설치만으로 탈취가 시작됩니다. 일부 변종은 깃허브 Actions 워크플로우를 직접 조작해 OIDC 토큰을 런타임 메모리에서 추출하는 방식도 사용합니다.
Q. 어떤 데이터를 빼가나요?: A. GitHub 토큰, npm 배포 토큰, AWS/Azure/GCP 자격증명, Kubernetes 서비스 계정 토큰, HashiCorp Vault 인증정보, SSH 키가 주요 탈취 대상입니다. 일부 변종은 암호화폐 지갑 정보도 수집합니다.
Q. TanStack은 왜 84개 악성 버전이 생겼나요?: A. 공격자가 TanStack 생태계 내 42개 패키지에 각각 정상 버전과 악성 버전을 함께 등록했습니다. 자동화 스크립트로 버전을 대량 생성했기 때문에 발견 전까지 총 84개 악성 버전이 배포됐습니다.
Q. 내가 영향을 받았는지 어떻게 알 수 있나요?: A. npm audit, pip-audit로 기본 점검하되, 이번 공격처럼 postinstall 스크립트를 쓰는 신규 악성 패키지는 audit 결과에 나오지 않을 수 있습니다. package.json의 의존성 목록을 알려진 악성 패키지 이름(chalk-tempalte, axois-utils 등)과 직접 대조하는 것이 더 빠릅니다.

1. 공격 개요 — 2025년 유출 코드가 2026년에 확산된 이유

미니 샤이-훌루드의 원본 코드는 2025년 9월 이전부터 지하 포럼에서 유통됐다. 2026년 5월에 폭발적으로 확산된 이유는 코드가 난독화 없이 그대로 유출되어 재사용 장벽이 극도로 낮아진 데 있다. 옥스시큐리티(Ox Security)는 분석 결과 "난독화되지 않은 상태였고, 유출된 원본과 거의 같았다"고 밝혔다 (출처: 데일리시큐, 2026-05-19).

즉, 원래 TeamPCP가 만든 코드를 다른 공격자들이 복붙 수준으로 재사용하고 있다는 뜻이다. 이는 기존 공급망 공격과는 결이 다르다. 도구의 진입 장벽이 내려가면 공격자 풀이 넓어지고, 변종 생성 속도도 빨라진다.

2. 전파·탈취 체인 — 설치 1초 만에 무슨 일이 벌어지나

공격 흐름을 단계별로 분해하면 아래와 같다.

단계	행위	주요 기술
1. 패키지 등록	정상 패키지명 오타 버전 등록 (타이포스쿼팅)	chalk-tempalte, axois-utils 등
2. 설치 트리거	npm install / pip install 실행 즉시 postinstall 스크립트 작동	package.json scripts.postinstall
3. 자격증명 수집	환경변수·설정파일·메모리에서 토큰 수집	~/.aws/credentials, .env, ~/.npmrc
4. 탈취·유출	C&C 서버 전송 + 일부 공개 깃허브 저장소에 자동 업로드	GitHub GraphQL API 악용
5. 측면 이동	탈취한 토큰으로 클라우드 콘솔·깃허브 저장소·CI/CD 접근	AWS CLI, GitHub API
6. 지속 유지	GitHub Actions 워크플로우 파일 변조로 재감염 유도	.github/workflows/ 조작

가장 위험한 구간은 4→5 단계다. GitHub 토큰이 탈취되면 공격자는 리포지토리에 접근해 또 다른 악성 코드를 커밋하거나, OIDC 기반으로 AWS 임시 자격증명을 발급받을 수 있다. 단순한 토큰 유출이 아니라 토큰 하나로 클라우드 전체가 열리는 구조다.

일부 변종(axois-utils)은 탈취 외에 감염 시스템을 DDoS 공격 노드로 동원하는 기능까지 포함한 것으로 보고됐다 (출처: 데일리시큐 2026-05-19).

3. 개발팀·DevOps가 입는 실제 피해

이 공격이 단순한 정보탈취와 다른 이유는 개발 파이프라인 자체가 공격 경로가 된다는 점이다.

피해 유형	구체적 시나리오
소스코드 유출	깃허브 리포지토리 전체 clone 후 외부 전송
공급망 오염	npm 배포 토큰 탈취 → 정상 패키지에 악성 버전 추가 배포
클라우드 인프라 침해	AWS/GCP/Azure 키로 S3 덤프, EC2 신규 인스턴스 생성, IAM 백도어
CI/CD 무결성 훼손	깃허브 Actions 워크플로우 변조 → 이후 빌드 전체 오염
컨테이너 레지스트리 침해	Docker Hub·ECR 자격증명 탈취 → 악성 컨테이너 이미지 푸시

CI/CD가 오염되면 "코드를 고쳐도 배포 과정에서 다시 감염"되는 악순환이 생긴다. 이 상태에서는 패키지 제거만으로 사고가 해결되지 않는다. 토큰 전체를 교체하고 워크플로우 히스토리를 감사해야 한다.

📌 개발팀이 가장 놓치는 지점
npm audit은 CVE 등록된 취약점만 잡는다. 이번 미니 샤이-훌루드처럼 postinstall 스크립트로 동작하는 악성 패키지는 audit 결과에 나타나지 않는다. 의존성 목록을 직접 감사하는 도구가 별도로 필요하다.

CodeScan은 의존성 파일(package.json, requirements.txt)을 포함한 공급망 취약점을 30초 안에 스캔한다.
👉 CodeScan 30초 무료 스캔 시작하기

4. 의존성 점검 단계 — 지금 당장 할 수 있는 것

사고가 발생한 뒤에 하는 게 아니라, 주기적으로 해야 하는 작업이다.

Step 1. 알려진 악성 패키지 이름 직접 대조

2026년 5월 기준 옥스시큐리티가 신고·제거 요청한 악성 패키지 이름은 아래와 같다 (보도 기준, 패키지는 이미 삭제되었지만 과거 설치 여부 확인 필요).

chalk-tempalte
@deadcode09284814/axios-util
axois-utils
color-style-utils

이 이름들이 package-lock.json 또는 pip freeze 결과에 남아 있다면 즉각 격리가 필요하다.

Step 2. postinstall 스크립트 감사

# 설치된 패키지 중 postinstall 스크립트를 가진 패키지 목록 출력
npm query :root > /dev/null && cat node_modules/*/package.json | jq -r 'select(.scripts.postinstall != null) | "\(.name): \(.scripts.postinstall)"'

postinstall에 curl, wget, fetch 같은 외부 통신이 있으면 즉시 검토 대상이다.

Step 3. 환경변수·.env 파일 오염 여부 확인

공격 직후 C&C로 전송된 데이터는 복구가 불가능하다. 하지만 현재 설정 파일에 불필요하게 넓은 권한의 토큰이 남아 있는지 확인하고, 즉시 최소 권한으로 교체한다.

Step 4. 깃허브 Actions 워크플로우 무결성 검증

.github/workflows/ 디렉토리의 최근 변경 이력을 git log로 확인한다. 본인이 수정하지 않은 변경이 있다면 침해 신호다.

5. CI/CD 토큰 보호 — 설계 단계부터 달라져야 하는 것

이번 사고를 계기로 점검해야 할 CI/CD 보안 설계 원칙은 세 가지다.

원칙 1. 장기 토큰 → OIDC 임시 자격증명으로 전환

AWS_ACCESS_KEY_ID 같은 장기 자격증명을 GitHub Secrets에 저장하는 방식은 구조적으로 취약하다. GitHub Actions ↔ AWS OIDC 연동을 사용하면 각 워크플로우 실행마다 임시 자격증명이 발급되고, 탈취돼도 수 시간 내에 만료된다.

원칙 2. 최소 권한(Least Privilege) 엄격 적용

빌드 토큰이 S3 버킷 전체 읽기 권한을 갖고 있을 필요가 없다. GitHub 토큰 권한은 permissions: 블록으로 워크플로우 단위로 명시적 제한을 걸어야 한다.

permissions:
  contents: read   # 소스 읽기만
  packages: write  # 패키지 배포만
  # id-token: write  # OIDC가 필요한 경우에만 활성화

원칙 3. 의존성 고정(Lock File) + 해시 검증

package-lock.json, poetry.lock, pip.lock을 반드시 커밋하고, CI에서 npm ci(install이 아닌 ci)로 설치한다. 이렇게 하면 버전 범위(^, ~)에 해당하는 악성 최신 버전이 자동 설치되는 상황을 막을 수 있다.

6. 자가점검 체크리스트

현재 개발 환경에 아래 항목을 대조해보자.

항목	점검 내용	상태
패키지 이름 오타	package.json 의존성에 유사 오타 패키지 없음	☐
postinstall 스크립트	설치된 패키지 중 외부 통신 postinstall 없음	☐
장기 토큰 저장	AWS 장기 키를 Secrets에 저장하지 않음 (OIDC 전환)	☐
GitHub 토큰 권한	워크플로우별 permissions: 최소 권한 명시	☐
Lock File 사용	npm ci / pip install --require-hashes로 고정 설치	☐
워크플로우 변경 이력	.github/workflows/ 최근 변경 본인 확인	☐
.env 토큰 유효성	불필요한 고권한 토큰 즉시 만료·재발급	☐
의존성 감사 주기	npm audit / pip-audit 주간 실행 CI 통합	☐

8개 중 절반 이상이 ☐이면 현재 의존성 파이프라인이 공격 노출 상태다. 지금 당장 lock file 점검과 고권한 토큰 교체부터 시작하는 게 맞다.

7. Bitwarden 사건과 무엇이 다른가

기존에 다룬 npm 공급망 공격 — Bitwarden 사건(관련 글 참조)은 특정 서비스 회사의 패키지가 직접 오염된 케이스였다.

이번 미니 샤이-훌루드가 다른 점은 자가전파 설계다. 탈취한 npm 배포 토큰으로 정상 패키지에 악성 버전을 추가 배포할 수 있어, 한 명의 개발자 PC에서 시작된 감염이 해당 개발자가 관리하는 패키지 전체로 번질 수 있다.

기업 단위로 보면, CI/CD 서버가 감염되면 그 서버가 배포한 모든 패키지가 잠재적 감염원이 된다. 이것이 '웜(worm)'이라고 부르는 이유다.

SBOM이 갖춰져 있었다면 어떤 패키지가 어느 빌드에 포함됐는지 즉시 추적할 수 있었을 것이다. 공급망 보안 체계 전반을 점검하고 싶다면 공급망 보안 체크리스트를 함께 참고하자.

Vercel 배포 환경에서 공급망 리스크가 어떻게 나타나는지는 Vercel 공급망 리스크에서 다뤘다.

지금 해야 할 한 가지를 고르라면

10년간 여러 공급망 침해 사고를 다뤄보면서 느낀 것이 있다. 대부분의 개발팀은 "npm install이 이렇게 위험한 행위인 줄 몰랐다"고 말한다.

postinstall은 설계 의도상 빌드 자동화를 위한 기능이지만, 공격자 입장에선 코드 실행을 보장받는 완벽한 진입점이다. --ignore-scripts 플래그를 기본으로 쓰고, 꼭 필요한 스크립트만 허용하는 방향으로 내부 정책을 바꾸는 것 — 이게 지금 당장 할 수 있는 가장 효과적인 한 가지다.

의존성 취약점 전체를 한 번에 확인하고 싶다면 CodeScan을 써보면 된다. package.json·requirements.txt 업로드만으로 알려진 취약점과 수상한 패키지를 30초 안에 리포트로 받을 수 있다.

다음 행동

**개발자·DevOps 팀이라면**
지금 사용 중인 의존성 파일을 30초 안에 점검하세요. 알려진 악성 패키지, 취약한 버전, 수상한 postinstall 스크립트를 자동으로 잡아냅니다.
👉 CodeScan 30초 무료 스캔 시작하기 **보안책임자·CTO라면**
우리 조직의 CI/CD 파이프라인이 미니 샤이-훌루드 유형 공격에 얼마나 노출되어 있는지 30분 1:1 상담으로 점검받으세요.
👉 CI·CD 공급망 보안 진단 상담 신청하기

관련 글

npm 공급망 공격 — Bitwarden 사건 분석 — 패키지 직접 오염 vs 자가전파 웜의 차이
Vercel 공급망 리스크 — 배포 파이프라인의 사각지대 — 배포 도구가 공격 경로가 될 때
공급망 보안 체크리스트 — 외주·SaaS 도입 전 점검 기준 — 전체 공급망 관리 체계

우리 서비스, 지금 안전한가?

URL 하나로 주요 보안 항목을 자동 진단. 등급 + 수정 가이드까지 자동 생성.

지금 무료 스캔 진단 문의하기