콘텐츠로 이동

Red Hat npm 오염 사고

Red Hat npm 오염 사고 thumbnail
2026-06-01, @redhat-cloud-services 네임스페이스의 여러 npm 패키지에서 악성 코드가 공개적으로 확인됐다. 공개 분석 기준으로 오염된 패키지는 preinstall 훅으로 node index.js를 실행하며, 설치만으로 payload가 동작한다. 이 사고의 핵심은 취약한 애플리케이션 함수가 아니라, 신뢰된 GitHub Actions...

요약

2026-06-01, @redhat-cloud-services 네임스페이스의 여러 npm 패키지에서 악성 코드가 공개적으로 확인됐다. 공개 분석 기준으로 오염된 패키지는 preinstall 훅으로 node index.js를 실행하며, 설치만으로 payload가 동작한다. 이 사고의 핵심은 취약한 애플리케이션 함수가 아니라, 신뢰된 GitHub Actions OIDC 퍼블리싱 경로와 정상 provenance가 악용됐다는 점이다.

Red Hat은 같은 날 advisory를 게시했고, 2026-06-03에 갱신했다. Red Hat 공개 공지 기준으로 이 패키지들은 Hybrid Cloud Console 프론트엔드 라이브러리이며, 오염 기간 동안 console.redhat.com 배포는 없었고 배포 과정에서 install-time script를 제거하는 보호 장치가 적용된다고 밝혔다. 현재 조사 기준으로 고객 측 조치는 필요하지 않다는 것이 Red Hat 입장이다. 반면 Snyk, Microsoft, JFrog 분석은 해당 패키지를 직접 설치했거나 CI에서 복원한 개발 환경은 별도 노출 대상으로 봐야 한다고 정리한다.

Warning

이 사고는 애플리케이션 런타임보다 설치 단계가 먼저 오염된 사례다. 직접 사용 코드가 실행되지 않아도 npm install 또는 npm ci만으로 payload가 발동할 수 있다.

개요

항목 내용
사고 유형 npm 공급망 오염
공개 확인일 2026-06-01
벤더 공지 갱신 2026-06-03
대상 @redhat-cloud-services 네임스페이스의 복수 패키지
실행 지점 npm installpreinstall
공개 분석 공통점 install-time 실행, 난독화된 index.js, 자격 증명 수집, 추가 전파 시도
신뢰 체인 악용 손상된 GitHub 계정, GitHub Actions OIDC, 정상 provenance

공개 자료에서 일치하는 골자는 다음과 같다.

  • 손상된 GitHub 계정이 RedHatInsights 조직 저장소에 비인가 커밋을 밀어 넣었다.
  • GitHub Actions가 id-token: write 권한으로 OIDC 토큰을 받아 npm 퍼블리싱 경로를 실행했다.
  • 결과물은 정상 저장소와 워크플로에서 생성된 것으로 보이는 provenance를 가졌다.
  • 패키지 설치 시 preinstall이 즉시 실행돼 개발자 단말이나 CI runner의 비밀정보를 수집하려 했다.

Snyk는 최소 32개 오염 릴리스를 언급했다. JFrog와 다른 분석은 더 많은 오염 버전을 제시하지만, 공개 자료마다 집계 단위가 달라 본문에서는 보수적으로 복수 패키지 오염으로 정리한다.

타임라인

날짜 내용
2026-06-01 @redhat-cloud-services 패키지 오염이 공개적으로 식별됨
2026-06-01 Red Hat advisory 게시
2026-06-01 Snyk와 JFrog가 install-time hook과 퍼블리싱 경로 분석 공개
2026-06-02 Microsoft가 다단계 loader, Bun 실행, exfiltration 흐름 분석 공개
2026-06-03 Red Hat advisory 갱신

공격 메커니즘

오염된 패키지의 가장 중요한 차이는 package.json에 추가된 install hook이다.

{
  "scripts": {
    "preinstall": "node index.js"
  }
}

이 한 줄로 인해 패키지를 import하지 않아도 설치 시점에 악성 index.js가 실행된다. 공개 분석에서 확인된 코드 수준 특징은 다음과 같다.

  • index.js가 정상 엔트리 파일 대신 수 MB 크기의 난독화 JavaScript로 교체됐다.
  • 바깥 레이어는 숫자 배열, ROT 계열 문자열 변환, eval()로 다음 단계를 복원한다.
  • 다음 단계는 AES-128-GCM으로 암호화된 blob을 복호화한다.
  • Bun runtime이 없으면 공식 Bun 배포 경로에서 받아 실행한다.
  • 프로세스 체인은 대체로 node -> shell -> bun -> payload 형태로 이어진다.

JFrog와 Microsoft 분석 기준으로 payload가 수행하는 primitive는 아래 수준까지 공개 확인된다.

  • 환경 변수, ~/.npmrc, GitHub 관련 토큰, SSH 키, CI secret 수집
  • AWS, Azure, GCP, Kubernetes, Vault 등 클라우드/플랫폼 자격 증명과 identity 정보 탐색
  • GitHub 계정 아래 새 public repository 생성 후 결과물 커밋
  • npm publish 권한이 있으면 다른 패키지를 재포장해 다시 퍼블리시 시도
  • GitHub 저장소에 .github/setup.js 또는 workflow 파일을 주입해 추가 전파 시도

이 사고는 src/ 내부 함수 취약점보다 패키지 메타데이터와 CI/CD 퍼블리싱 체인이 공격면이 됐다는 점이 더 중요하다. provenance가 유효하더라도, 그 provenance를 만든 계정과 워크플로가 이미 손상됐다면 결과물은 악성일 수 있다.

영향

직접 영향 평가는 패키지를 설치한 위치를 기준으로 잡는 편이 맞다.

  • @redhat-cloud-services 패키지를 직접 또는 간접 의존한 저장소
  • 2026-06-01 이후 손상된 버전을 복원한 개발자 워크스테이션
  • npm install 또는 npm ci를 수행한 CI runner
  • npm, GitHub, 클라우드 자격 증명이 설정된 빌드 환경

다만 Red Hat 공식 공지 기준으로는 Hybrid Cloud Console의 고객 제공 릴리스에는 손상된 패키지가 포함되지 않았고, 현재 조사 결과 고객 조치는 필요하지 않다. 따라서 일반적인 Red Hat 서비스 이용자와 해당 npm 패키지를 직접 소비한 개발 환경은 구분해서 봐야 한다.

탐지 포인트

네트워크

설치 직후 비정상 외부 통신이 있었는지 본다.

  • GitHub repository 생성, commit, ref update 같은 API 호출 증가
  • npm registry 조회 뒤 곧바로 publish 관련 호출이 이어지는 패턴
  • Bun runtime 다운로드 정황
  • 클라우드 metadata 또는 secret manager 조회 급증

엔드포인트

패키지와 로컬 아티팩트 차이를 먼저 확인한다.

npm view @redhat-cloud-services/<package> versions --json
npm pack @redhat-cloud-services/<package>@<version>
tar -xOf <package-version>.tgz package/package.json
tar -xOf <package-version>.tgz package/index.js | head

확인 포인트는 단순하다.

  • package.jsonpreinstall이 추가됐는지
  • 원래 작아야 할 index.js가 비정상적으로 커졌는지
  • /tmp 아래 임시 JavaScript, Bun 관련 실행 파일 생성 흔적이 있는지
  • node, sh, bun 순으로 이어지는 비정상 실행 체인이 있었는지

서버

CI와 GitHub 쪽 흔적이 더 직접적이다.

  • 2026-06-01 전후 npm install 또는 npm ci 이력
  • id-token: write가 들어간 낯선 GitHub Actions workflow
  • 보호되지 않은 브랜치에 갑자기 추가된 workflow 파일
  • 알 수 없는 public repository 생성
  • repository description에 Miasma: The Spreading Blight 사용
  • publish 권한이 있는 계정에서 예상치 못한 패키지 patch release 생성

lockfile 점검은 가장 빠른 1차 필터다.

grep -R "@redhat-cloud-services" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

대응

직접 소비 환경에서 손상 버전 설치가 확인됐다면 조치는 설치 흔적 제거보다 호스트 격리와 자격 증명 교체가 먼저다.

  1. 오염 버전이 들어간 lockfile, 캐시, 내부 registry mirror를 식별한다.
  2. 해당 버전을 설치한 단말과 runner를 노출 자산으로 분리한다.
  3. 재설치가 필요하면 install script를 막고 진행한다.
npm install --ignore-scripts
npm config set ignore-scripts true
  1. npm token, GitHub token, SSH key, 클라우드 자격 증명을 clean host에서 순차 교체한다.
  2. GitHub 조직과 npm 계정에서 예기치 않은 repository, workflow, publish 이력을 확인한다.
  3. 퍼블리싱 파이프라인에서는 OIDC 신뢰 대상을 저장소와 워크플로 파일명만이 아니라 브랜치, 보호 규칙, 리뷰 강제와 함께 묶어 본다.
  4. provenance 검증은 유지하되, install-time script 추가와 엔트리 파일 치환 같은 행위 기반 검사를 별도로 둔다.

참고 자료