2026년 하루 평균 보고된 CVE가 전년 대비 131% 증가했습니다.
← 모든 취약점

Shai-Hulud: npm 웜과 빌드가 영향을 받았는지 확인하는 방법

Shai-Hulud는 npm 패키지를 감염시키는 자기 확산형 웜으로, 피해자 각각을 다음 확산 경로로 끌어들이는 소프트웨어 공급망 공격입니다. 패키지가 설치될 때 실행되어 해당 머신에서 npm 토큰, GitHub 토큰, 클라우드 키를 훔치고, 훔친 npm 토큰으로 피해자가 관리하는 다른 패키지의 감염된 버전을 게시합니다. 2025년 9월 첫 공격 이후 반복해서 다시 나타났으며, 2026년 5월에는 제작자들이 소스 코드를 공개했기 때문에 그 이후의 공격은 각기 다른 그룹의 소행일 수 있습니다. 빌드 중 하나라도 감염된 버전을 설치했다면 해당 작업이 침해된 것으로 간주하고 그 작업이 읽을 수 있었던 모든 시크릿을 교체하세요.

피해의 대부분은 CI에서 발생합니다. 2025년 11월 공격에서 Wiz의 조사에 따르면 개발자 머신에서 발생한 감염은 23%에 불과했고, 나머지는 대부분 CI/CD 파이프라인에서 발생했으며 그중 GitHub Actions가 가장 많았습니다. 빌드는 수백 개의 패키지를 설치하고, 게시와 배포에 필요한 시크릿을 보유하며, 아무도 지켜보지 않는 상태에서 모든 설치 스크립트를 실행합니다. 그래서 새로운 공격이 발표되면 모든 팀이 같은 질문을 던집니다. 우리 빌드 중에 감염된 버전을 설치한 것이 있는가?

무슨 일이 있었나

시기공격 물결이전과 달랐던 점
2025년 9월Shai-Huludpostinstall 스크립트가 3.6 MB 크기의 bundle.js를 실행하고, TruffleHog로 시크릿을 찾아내며, 메인테이너의 패키지를 최대 20개까지 다시 게시했습니다. @ctrl/tinycolor와 18개의 @crowdstrike 패키지를 포함해 500개가 넘는 패키지가 영향을 받았습니다. CISA는 9월 23일 경보를 게시했습니다.
2025년 11월Sha1-Hulud: The Second Comingpreinstall로 옮겨 갔고, Bun 런타임을 설치해 10 MB 페이로드를 실행했으며, 메인테이너당 최대 100개의 패키지에 백도어를 심고, 감염된 머신을 셀프 호스팅 GitHub 러너로 등록했습니다. Zapier, ENS, PostHog, Postman 패키지가 피해를 입었고, Wiz는 시크릿이 유출된 리포지토리를 25,000개 이상 집계했습니다.
2025년 12월"3.0" 테스트단일 패키지에 담긴 수정 버전으로, 의미 있는 확산은 없었습니다.
2026년 5월TanStack42개 @tanstack 패키지의 악성 버전 84개. 공격자는 npm 토큰을 훔치지 않았습니다. pull_request_target 워크플로, 오염된 Actions 캐시, 러너 메모리에서 읽어 낸 OIDC 토큰을 이용해 TanStack 자체의 신뢰할 수 있는 게시(trusted publishing)로 패키지를 게시했습니다. CVE-2026-45321로 추적되며, 5월 27일 CISA의 KEV 카탈로그에 추가되었습니다.
2026년 5월AntV323개 패키지의 639개 버전. GitHub Actions Linux 러너에서 페이로드가 러너 프로세스 메모리에서 시크릿을 읽어 로그 마스킹을 우회했습니다. GitHub는 npm 쓰기 토큰 61,274개를 무효화했습니다.
2026년 6월Miasma32개의 @redhat-cloud-services 패키지가 주입된 워크플로를 통해 유효한 출처 증명과 함께 게시되었습니다. 감염마다 고유하게 암호화된 페이로드를 담고 있어 해시 기반 탐지가 실패했습니다.
2026년 8월CHAINDROPkeyv, cacheable, cache-manager 같은 인기 캐싱 패키지를 포함해 총 수백 개의 패키지가 영향을 받았습니다. 리포지토리 안의 에디터 및 AI 어시스턴트 설정 파일을 통해 지속성을 유지했습니다.
2026년 9월재출현9월 7일, npm이 새로 도입한 게시 시점 악성코드 스캔을 통과한 4개 패키지에서 페이로드가 다시 나타났습니다.
2026년 10월tensorlake10월 8일, 웜이 담긴 [email protected]가 게시되었습니다. OX Security는 새로운 공격자 키를 확인했으며 "독립적인 위협 행위자이거나 Shai-Hulud라는 이름을 쓰는 새로운 그룹"일 가능성을 제기합니다.

CI 작업에서 웜이 하는 일

세부 사항은 공격마다 달라지지만 패턴은 같습니다.

  1. 설치 시점에 실행됩니다. preinstall 또는 postinstall 스크립트는 npm install 또는 npm ci가 감염된 버전에 도달하는 즉시 실행됩니다. 코드에서 해당 패키지를 import할 필요조차 없습니다.
  2. 시크릿을 수집합니다. 환경 변수, .npmrc 토큰, 메타데이터 서비스와 시크릿 관리자의 클라우드 자격 증명, 그리고 TruffleHog가 디스크에서 찾아내는 모든 것을 수집합니다. 이후의 공격은 GitHub Actions 러너의 메모리를 직접 읽어, 해당 단계에 노출된 적이 없고 로그에서는 마스킹으로 가려졌을 시크릿까지 빼냈습니다.
  3. 외부로 빼돌립니다. 초기 공격은 웜의 이름을 딴 공개 GitHub 리포지토리를 만들고, 모든 리포지토리 시크릿을 webhook.site로 전송하는 워크플로를 푸시했습니다. 이후의 공격은 공격자 서버와 메시징 네트워크를 이용했습니다.
  4. 확산하고 잔류합니다. 훔친 npm 토큰으로 다른 패키지의 감염된 버전을 게시합니다. GitHub 토큰으로는 워크플로를 추가하거나, 셀프 호스팅 러너를 등록하거나, 다음에 누군가 리포지토리를 열 때 실행되는 설정 파일을 심습니다.
  5. CI에서는 다르게 동작합니다. 2025년 11월의 페이로드는 GITHUB_ACTIONS, BUILDKITE, CIRCLE_SHA1 같은 변수를 확인했고, CI에서는 동기적으로 실행되어 빌드가 다음 단계로 넘어가기 전에 작업을 마쳤습니다.

영향을 받는 대상

감염된 버전이 레지스트리에 올라와 있는 동안 그 버전을 설치한 머신이나 빌드를 가진 모든 사람입니다. 개발자 노트북, CI 작업, npm install을 실행하는 Docker 빌드, 셀프 호스팅 러너가 여기에 해당합니다. 패키지에 직접 의존할 필요는 없으며, 전이 종속성이나 npx로 실행한 도구만으로도 충분합니다. 공격 물결마다 패키지와 버전 목록이 따로 있고, 감염된 버전은 보통 몇 시간에서 며칠 안에 제거되므로, 중요한 것은 그 기간에 무언가가 그 버전을 설치했는지입니다.

작동 방식

Shai-Hulud는 npm의 버그가 아닙니다. 원래는 정상적인 패키지 안에 게시된 악성 코드이며, 감염된 패키지에 대한 GitHub의 악성코드 보안 권고는 이를 내장된 악성 코드(CWE-506)로 분류합니다. 각 공격은 몇 가지 기법을 조합합니다.

  • 설치 시점 실행. npm은 설치 중에 패키지의 라이프사이클 스크립트(preinstall, postinstall, prepare 등)를 사용자나 CI 작업의 권한으로 실행합니다. 감염된 버전은 의존성 트리에 있기만 하면 되고, 무엇도 그것을 임포트할 필요가 없습니다.
  • 훔친 게시 권한을 이용한 확산. 피해자에게서 빼앗은 npm 또는 GitHub 토큰으로, 웜은 그 피해자의 다른 패키지에 페이로드를 추가한 새 버전을 게시합니다. 그래서 감염된 메인테이너가 늘어날 때마다 더 많은 패키지가 감염됩니다.
  • 피해자 자신의 릴리스 파이프라인을 통한 게시(TanStack, 2026년 5월). GitHub의 보안 권고에 따르면, 공격자는 pull_request_target 워크플로, 포크와 베이스 사이의 신뢰 경계를 넘어 오염된 GitHub Actions 캐시, 러너 메모리에서 읽어 낸 OIDC 토큰을 연쇄적으로 이용해, 게시 워크플로를 변경하지 않고 TanStack의 trusted publishing으로 게시했습니다. 감염된 버전은 포크의 커밋에 대한 선택적 의존성을 선언했고, 그 prepare 스크립트가 페이로드를 실행한 뒤 일부러 실패했기 때문에 npm이 이를 버려 node_modules에 흔적이 남지 않았습니다.
  • 유효한 출처 증명(Miasma, 2026년 6월). 주입된 워크플로가 피해자 자신의 리포지토리에서 게시했기 때문에 감염된 버전은 유효한 출처 증명을 갖추었고, 감염마다 고유하게 암호화된 페이로드가 해시 기반 탐지를 무력화했습니다.

영향을 받았는지 확인하는 방법

  1. 해당 공격의 영향받는 버전 목록을 확보하세요. 보안 업체들이 몇 시간 안에 목록을 공개합니다. 예를 들어 Datadog은 패키지 및 버전 목록이 담긴 침해 지표(IoC) 리포지토리를 운영합니다.
  2. 기본 브랜치뿐 아니라 해당 기간에 CI를 실행한 모든 브랜치에서 모든 잠금 파일을 검색하세요.
  3. 빌드 자체를 검색하세요. CI 로그에서 setup_bun.js, bun_environment.js 또는 보안 권고에 언급된 다른 파일 이름과, 영향받는 버전을 언급하는 설치 출력을 찾으세요. 빌드별로 SBOM을 보관하고 있다면 SBOM에서 해당 버전을 검색하세요.
  4. GitHub 조직을 점검하세요. 웜의 이름을 딴 새 리포지토리, 직접 작성하지 않은 워크플로 파일(예: shai-hulud-workflow.yml, discussion.yaml, formatter_*.yml), 직접 등록하지 않은 셀프 호스팅 러너가 있는지 확인하세요.

상황에 맞게 고쳐 쓸 수 있는 명령입니다. 모든 원격 브랜치의 잠금 파일을 검색하려면, 해당 공격의 영향받는 버전을 affected.txt에 한 줄에 하나씩 name@version 형식으로 적으세요.

git fetch --all --quiet
for ref in $(git for-each-ref --format='%(refname:short)' refs/remotes); do
  while read -r pkg; do
    name=${pkg%@*}; version=${pkg##*@}
    git grep -n -A3 -F "$name" "$ref" -- '*package-lock.json' '*yarn.lock' '*pnpm-lock.yaml' \
      | grep -F "$version" | sed "s|^|$pkg  |"
  done < affected.txt
done

조직의 셀프 호스팅 러너, 웜을 언급하는 새 리포지토리, 웜이 만드는 것으로 알려진 워크플로 파일을 나열하려면 다음을 실행하세요(ORG를 바꾸세요).

gh api --paginate orgs/ORG/actions/runners --jq '.runners[] | [.name, .os, .status] | @tsv'
gh repo list ORG --limit 1000 --json name,description,createdAt \
  --jq '.[] | select((.description // "") | test("hulud"; "i")) | [.name, .createdAt] | @tsv'
for repo in $(gh repo list ORG --limit 1000 --json name --jq '.[].name'); do
  gh api "repos/ORG/$repo/contents/.github/workflows" --jq '.[].name' 2>/dev/null \
    | grep -E '^(shai-hulud-workflow\.yml|discussion\.yaml|formatter_.*\.yml)$' \
    | sed "s|^|$repo  |"
done

리포지토리에도 자체 러너가 있을 수 있습니다(gh api repos/ORG/REPO/actions/runners). 또한 초기 공격은 토큰을 도난당한 개발자의 개인 계정에 리포지토리를 만들었으므로, 개발자들에게 각자의 계정도 확인하도록 요청하세요.

잠금 파일만으로는 판단할 수 없는 이유

일반적인 조언은 package-lock.json, yarn.lock 또는 pnpm-lock.yaml에서 영향받는 버전을 검색하라는 것입니다. 이것부터 하는 것이 맞지만, 잠금 파일이 깨끗하다고 해서 빌드가 깨끗하다는 증거가 되지는 않습니다.

  • 잠금 파일 밖에서 설치되는 패키지. npx some-tool은 프로젝트 종속성이 아닌 패키지를 npm 캐시에 설치합니다. 설정 단계의 npm install -g, 빌드 스크립트 안에서 설치되는 도구, Dockerfile 안의 npm install은 모두 프로젝트의 잠금 파일을 우회합니다.
  • 현재 브랜치의 잠금 파일은 실제로 실행된 잠금 파일이 아닙니다. 3주 전의 빌드는 그때 빌드를 트리거한 브랜치의 잠금 파일 내용을 사용했습니다. 종속성 업데이트 풀 리퀘스트는 누군가 검토하기도 전에 새 버전으로 CI를 실행합니다.
  • 캐시는 이전에 설치된 것을 복원합니다. 복원된 node_modules나 npm 캐시에는 현재 잠금 파일에 더 이상 없는 버전이 들어 있을 수 있습니다.
  • npm ci는 잠금 파일에 적힌 대로 설치합니다. 감염된 버전이 이미 잠금 파일에 고정되어 있었다면, 엄격한 설치는 그 버전을 그대로 충실히 설치합니다.
  • 정상적으로 게시된 버전도 악성일 수 있습니다. TanStack과 Miasma는 자체 릴리스 워크플로를 통해 침해되었고, Miasma의 감염된 버전에는 유효한 출처 증명이 있었습니다. 버전이 제대로 게시되었는지 확인해도 그 버전이 깨끗한지는 알 수 없습니다.

실제로 필요한 것은 감염된 버전이 레지스트리에 올라와 있던 전체 기간 동안, 모든 리포지토리와 모든 브랜치에 걸쳐 각 빌드가 어떤 패키지 버전을 가져왔는지에 대한 기록입니다. 우리는 영향을 받았는가? 빌드 전반에서 새 CVE를 평가하는 방법을 참조하세요.

수정 방법과 아직 패치할 수 없을 때 할 일

  1. 영향받는 버전을 설치한 빌드가 있다면 해당 작업이 침해된 것으로 간주하세요. npm 토큰, GitHub 토큰, 클라우드 자격 증명, 배포 키 등 그 작업이 읽을 수 있었던 모든 시크릿을 교체하세요. 이후의 공격은 훔친 시크릿을 다른 피해자의 계정에 게시했으므로, 자신의 계정에 아무것도 나타나지 않았다고 해서 안전하다고 가정해서는 안 됩니다.
  2. 캐시를 비우세요. GitHub Actions 캐시와 개발자 머신 및 셀프 호스팅 러너의 npm 캐시를 삭제해, 다음 빌드가 깨끗한 버전을 설치하도록 하세요.
gh cache delete --all --repo ORG/REPO   # GitHub Actions caches, per repository
npm cache clean --force
rm -rf node_modules "$(pnpm store path)"   # pnpm; for Yarn: yarn cache clean
  1. 깨끗한 버전으로 고정하세요. 그리고 웜이 추가한 워크플로, 리포지토리, 러너, 설정 파일을 제거하세요.

정리 결과 검증

  1. 모든 잠금 파일이 깨끗한 버전으로 해석됩니다. 각 브랜치에서 npm ls <package>(또는 pnpm why, yarn why)가 설치된 버전을 보여 줍니다. 그중 어느 것도 해당 공격의 목록에 있어서는 안 됩니다.
  2. 깨끗하게 설치한 결과에 페이로드 파일이 없습니다. 위의 캐시 삭제 후 다시 설치하고, 보안 권고에 언급된 페이로드 파일을 찾아보세요.
find node_modules -name bundle.js -size +3M \
  -o -name setup_bun.js -o -name bun_environment.js -o -name router_init.js
  1. 이전 자격 증명이 더 이상 작동하지 않습니다. 폐기한 npm 토큰이 npm token list에서 사라졌고, 이전 GitHub 토큰과 배포 키가 삭제되었으며, 클라우드 키는 교체에 그치지 않고 비활성화되었습니다.
  2. 캐시가 사라졌습니다. 영향받은 어느 리포지토리에서도 gh cache list에 정리 이전에 만들어진 캐시가 나타나지 않습니다.
  3. 웜이 추가한 것이 남아 있지 않습니다. 직접 만들지 않은 리포지토리, 워크플로 파일, 셀프 호스팅 러너, 편집기 및 AI 어시스턴트 설정 파일이 없습니다.
  4. 다음 빌드가 깨끗합니다. 잠금 파일만이 아니라 빌드 로그나 빌드별 SBOM에서 실제로 설치된 버전을 확인하세요.

다음 공격의 피해를 줄이는 방법

  • 가능한 곳에서는 설치 스크립트를 끄세요. 2026년 7월에 출시된 npm v12는 설치 스크립트를 기본적으로 비활성화하고 패키지별로 허용할 수 있게 합니다. pnpm과 Yarn도 비슷한 제어 기능을 제공합니다.
  • 새 버전을 도입하기 전에 기다리세요. 감염된 버전의 대부분은 몇 시간에서 며칠 안에 발견되어 제거됩니다. Dependabot과 Renovate가 모두 지원하는 종속성 업데이트 대기 기간(cooldown)을 설정하면 감염된 버전이 빌드에 들어오지 않습니다. 2026년 10월 20일부터 GitHub Enterprise Cloud용 공개 프리뷰로 제공되는 GitHub의 패키지 방화벽도 npm 설치에서 악성 패키지를 검사하고 대기 기간을 제공합니다.
  • 신뢰할 수 있는 게시와 수명이 짧은 토큰으로 게시하세요. npm은 2025년 12월에 모든 클래식 토큰을 폐기했습니다. 수명이 긴 토큰 대신 CI에서 OIDC 기반의 신뢰할 수 있는 게시를 사용하고, 게시 워크플로를 빌드 및 테스트 워크플로와 분리하세요.
  • 웜이 악용하는 워크플로를 강화하세요. pull_request_target을 피하고, 액션을 커밋 SHA로 고정하며, GITHUB_TOKEN에는 각 작업에 필요한 권한만 부여하세요. GitHub Actions 시크릿: 유출 경로와 보호 방법을 참고하세요.
  • 빌드가 연결할 수 있는 곳을 제한하세요. 빌드에 필요한 것은 패키지 레지스트리와 몇몇 API뿐입니다. 빌드가 그곳에만 접근할 수 있다면 웜이 webhook.site나 자체 서버로 보내는 호출은 실패합니다. 이그레스 정책이 GitHub Actions에서 데이터 유출을 막는 방법을 참고하세요. 다만 일부 공격이 이용했던 GitHub 자체 API처럼 빌드가 정당하게 사용하는 호스트를 통한 유출은 막지 못합니다.

침해 여부 확인

Shai-Hulud는 처음부터 악의적으로 설계되었습니다. 감염된 버전을 설치한 머신이나 작업은 모두 그것을 실행했습니다. 침해 지표는 공격마다 다르므로, 확인하려는 공격의 보안 권고를 사용하세요. 1차 출처의 지표는 다음과 같습니다.

공격 물결침해 지표출처
2025년 9월페이로드 bundle.js, SHA-256 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09. 워크플로 .github/workflows/shai-hulud-workflow.yml(shai-hulud 브랜치). Shai-Hulud라는 이름의 공개 리포지토리. webhook.site로의 연결StepSecurity, CISA
2025년 11월setup_bun.js, SHA-1 d1829b4708126dcc7bea7437c04d1f10eacd4a16. bun_environment.js, SHA-1 d60ec97eea19fffb4809bc35b91033b52490ca11 또는 3d7570d14d34b0ba137d502f042b27b0f37a59fa. cloud.json, contents.json, environment.json, truffleSecrets.json, actionsSecrets.json이 있는 리포지토리. 워크플로 .github/workflows/discussion.yaml과 formatter_*.yml. SHA1HULUD라는 이름의 셀프 호스팅 러너Wiz
2026년 5월, TanStack"@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"(optionalDependencies 안). 패키지 루트의 페이로드 router_init.js(약 2.3 MB). 헬퍼 tanstack_runner.js. filev2.getsession.org와 seed1.getsession.org~seed3.getsession.org로의 연결, litter.catbox.moe에서의 2단계 다운로드GHSA-g7cv-rxg3-hmpx

이후 공격은 감염마다 페이로드를 바꾸었으므로, 파일 해시가 일치하지 않는다고 해서 아무것도 증명되지 않습니다. 먼저 패키지 버전으로 대조하세요.

침해를 가정해야 할 때. 영향받는 버전을 설치한 모든 호스트와 CI 작업은, 설치가 실패했거나 node_modules에 아무것도 남지 않았더라도 침해된 것으로 간주하세요. TanStack에 대한 GitHub의 보안 권고는 영향받는 버전을 설치한 개발 환경이나 CI 환경은 "침해된 것으로 간주해야 한다"고 말합니다. 공격이 발표된 날이 아니라 감염된 버전이 처음 게시된 시점부터 확인하세요.

자격 증명을 교체하세요. 설치 과정이 접근할 수 있었던 모든 것을 교체하세요. 포스트모템에 따르면 TanStack 공격에서는 AWS, GCP, Kubernetes, Vault, GitHub, npm, SSH 자격 증명이 그 대상이었습니다. 설치 기간 중과 그 이후에 영향받은 호스트에서 발생한 활동을 클라우드 감사 로그에서 검토하세요.

캐시와 아티팩트를 삭제하세요. CISA의 권고대로 아티팩트 리포지토리와 의존성 프록시에서 영향받는 버전의 캐시된 사본을 찾아 삭제하세요. node_modules, npm 캐시, CI 캐시를 삭제하세요. TanStack 공격에서는 오염된 pnpm 스토어 캐시가 공격자의 침투 경로였으므로, 패키지 캐시뿐 아니라 Actions 캐시도 확인하세요. 침해된 작업이 만든 것은 모두 다시 빌드해 다시 릴리스하세요.

고객에게 알릴 내용

npm으로 빌드한 소프트웨어를 제공한다면, 고객은 제품에 웜이 들어 있는지 또는 릴리스 파이프라인이 침해되었는지 물어 올 것입니다. 무엇을 확인했고 무엇을 했는지로 답하세요.

[날짜]부터 [날짜]까지 [제품]의 모든 빌드를 공개된 Shai-Hulud 감염 npm 패키지 버전 목록과 대조했습니다. [영향받는 버전을 설치한 빌드는 없었습니다.] / [[날짜]의 [구성 요소] 빌드가 [package@version]을 설치했습니다. 해당 빌드가 접근할 수 있었던 자격 증명을 교체하고, 깨끗한 종속성으로 [제품]을 다시 빌드해 [버전]을 출시했습니다. 릴리스 [x~y]가 영향을 받으니 [버전]으로 업그레이드해 주세요.] 새로운 공격으로 상황이 바뀌면 이 공지를 업데이트하겠습니다.

아직 확인 중이라면 그렇다고 말하고, 언제 답할지 알려 주세요. 첫 공지와 결과별 템플릿은 공급망 공격 후 고객에게 답하는 방법을 참고하세요.

CRACI의 역할

CRACI는 GitHub Actions 작업을 CRACI 러너에서 실행하며(runs-on: craci), 각 작업이 npm 및 기타 레지스트리에서 실제로 가져오는 모든 패키지를 캐시에서 복원된 패키지까지 포함해 기록합니다. 이 기록은 위에서 설명한 사각지대를 메웁니다. 기록이 잠금 파일에 선언된 내용이 아니라 작업이 실제로 내려받은 항목에서 나오므로, npx 도구, 전역 설치, 빌드 스크립트 안의 설치가 모두 드러납니다. 새로운 공격이 발표되면 잠금 파일과 로그로 재구성할 필요 없이 CRACI가 기록한 빌드에서 영향받는 버전을 조회하면 되고, 각 작업의 네트워크 추적은 그 작업이 어디에 연결했는지 보여 줍니다. 빌드 기록은 모든 과거 빌드를 SBOM과 함께 보관하므로, 보존 기간 안에서 어떤 빌드에 감염된 버전이 포함되었는지와 노출되었던 기간을 확인할 수 있습니다.

CRACI의 이그레스 정책은 작업이 연결할 수 있는 곳을 제한하며, 작업 시작 전에 검증되고 실패 시 차단(fail closed)되며, 작업이 정책에서 허용하지 않는 대상에 접근하려 하면 알림을 보냅니다. TanStack 공격처럼 CVE가 공개된 감염 릴리스는 다른 취약점과 마찬가지로 표시되며, 정책 게이트로 이를 포함한 빌드를 차단할 수 있습니다. CRACI는 패키지의 악성 행위를 점수화하지 않으며, 보안 권고가 나오기 전의 새로운 감염 버전을 표시하지도 않습니다. 설치 전에 감염된 버전을 차단하려면 패키지 평판 도구와 함께 사용하세요.

빌드 하나의 패키지 기록을 직접 확인해 보세요

다른 사고: 모든 취약점.

출처 및 업데이트

1차 출처와 원본 조사:

업데이트:

  • 2026-11-11: 정보 상자에 EPSS, CWE 분류, 발견자를 추가하고, 복사해 쓸 수 있는 점검 명령과 웜의 작동 방식, 정리 결과 검증, 공격별 지표를 담은 침해 여부 확인 섹션을 추가했습니다.
  • 2026-11-11: 블로그에서 취약점 섹션으로 옮겼습니다. 2026년 10월 8일 tensorlake 공격, 2026년 9월 재출현 날짜, TanStack 공격의 CVE-2026-45321과 KEV 등재, GitHub의 패키지 방화벽을 추가했습니다.
  • 2026-09-25: CRACI 블로그에 처음 게시했습니다.

자주 묻는 질문

Shai-Hulud는 아직 활동 중인가요?

네. 2025년 9월부터 여러 차례에 걸쳐 다시 나타났고, 2026년 5월에는 제작자들이 소스 코드를 공개했으므로 이후의 공격은 다른 그룹의 소행일 수 있습니다. 여기서 다루는 가장 최근의 공격은 2026년 10월 8일 tensorlake 패키지를 노렸습니다.

Shai-Hulud에 CVE가 있나요?

웜 전체에는 CVE가 없습니다. GitHub는 감염된 개별 패키지에 대해 악성코드 보안 권고를 게시하며, 2026년 5월 TanStack 공격에는 CVE-2026-45321이 부여되었습니다. CISA는 이를 2026년 5월 27일 알려진 악용 취약점(KEV) 카탈로그에 추가했습니다.

잠금 파일이 깨끗하면 영향을 받지 않은 건가요?

아닙니다. npx로 설치한 패키지, 전역 설치, 빌드 스크립트와 Dockerfile 안의 설치, 다른 브랜치의 오래된 잠금 파일, 복원된 캐시는 모두 현재 잠금 파일에 나타나지 않는 감염된 버전을 들여올 수 있습니다. 각 빌드가 실제로 무엇을 가져왔는지에 대한 기록이 필요합니다.

영향을 받았는지 어떻게 확인하나요?

해당 공격의 영향받는 패키지 버전을 확보하고, 그 기간에 CI를 실행한 모든 브랜치의 잠금 파일을 검색하고, CI 로그와 빌드별 SBOM에서 해당 버전과 페이로드 파일 이름을 찾고, GitHub 조직에 직접 만들지 않은 리포지토리, 워크플로, 셀프 호스팅 러너가 있는지 확인하세요.

빌드가 감염된 버전을 설치했다면 어떻게 해야 하나요?

해당 작업이 침해된 것으로 간주하세요. npm 토큰, GitHub 토큰, 클라우드 자격 증명, 배포 키 등 그 작업이 읽을 수 있었던 모든 시크릿을 교체하고, GitHub Actions 캐시와 npm 캐시를 삭제하고, 웜이 추가한 워크플로, 리포지토리, 러너가 있는지 확인하세요.

웜이 우리 빌드에서 실행되었는지 어떻게 알 수 있나요?

빌드 로그, 잠금 파일, 설치된 패키지에서 해당 공격의 침해 지표를 찾아보세요. bundle.js, setup_bun.js, bun_environment.js, router_init.js 같은 페이로드 파일, 직접 만들지 않은 리포지토리와 워크플로, SHA1HULUD라는 이름의 셀프 호스팅 러너, webhook.site나 getsession.org로의 연결입니다. 영향받는 버전을 설치한 작업은 페이로드를 실행한 것이므로, 다른 흔적이 없더라도 침해된 것으로 간주하세요.