Red Hat NPM 백도어 사건이 말하는 것

Red Hat NPM 백도어 사건의 핵심은 낯선 악성 패키지가 아니라, 신뢰받는 공식 네임스페이스의 패키지가 오염됐다는 점입니다. 2026년 6월 1일, @redhat-cloud-services npm 네임스페이스에 속한 여러 패키지의 공급망 침해가 공개됐습니다.¹

해당 패키지들은 Red Hat Hybrid Cloud Console 웹 인터페이스에서 쓰이는 프론트엔드 JavaScript 라이브러리였습니다.¹ 공격자는 가짜 패키지를 새로 만든 것이 아니라, 이미 신뢰받고 있던 배포 경로를 악용했습니다. 이 차이가 이번 사건을 단순한 악성 패키지 문제가 아니라 CI/CD 신뢰 경계의 문제로 보게 만듭니다.

공식 패키지도 배포 경로가 뚫리면 위험하다

Red Hat의 초기 조사에 따르면, 침해된 GitHub 계정이 Red Hat GitHub 조직 내 패키지에 악성 코드를 주입하는 데 사용됐습니다.¹ Aikido는 악성 패키지가 GitHub Actions OIDC 기반 게시 흐름을 통해 배포됐다고 설명했습니다.²

여기서 중요한 점은 OIDC 자체가 문제라는 뜻이 아니라는 것입니다. OIDC 기반 게시 방식은 장기 npm 토큰을 저장하지 않도록 해주는 중요한 보안 장치입니다. 하지만 워크플로를 실행할 수 있는 계정이나 권한이 장악되면, 짧은 수명의 합법 토큰도 공격에 사용될 수 있습니다.

따라서 질문은 “토큰을 저장했는가”에서 “누가 게시 워크플로를 실행할 수 있는가”, “어떤 조건에서 패키지가 배포되는가”로 바뀌어야 합니다.

설치 시점이 공격 지점이 된다

Aikido는 32개 패키지의 96개 버전이 침해됐고, 해당 패키지들의 누적 주간 다운로드 수를 116,991회로 집계했습니다.² 이번 변종은 패키지 내부에서 자신을 Miasma로 식별했으며, Shai-Hulud 계열의 자격증명 탈취 웜으로 분석됐습니다.²

이런 유형의 공격에서 특히 위험한 지점은 애플리케이션 실행 시점이 아니라 설치 시점입니다. 악성 코드는 패키지가 실제 서비스 코드에서 import되기 전, npm install 과정에서 실행될 수 있습니다.

그 결과 개발자 PC, CI 러너, 빌드 환경에 남아 있는 GitHub 토큰, 클라우드 키, npm 토큰, SSH 키 등이 직접적인 공격 대상이 됩니다. 패키지를 “사용했는지”뿐 아니라 “설치한 적이 있는지”를 확인해야 하는 이유입니다.

영향은 제한됐지만 확인은 필요하다

Red Hat은 침해 기간 동안 Hybrid Cloud Console의 새 릴리스가 게시되지 않았다고 밝혔습니다.¹ 또한 console.redhat.com 배포 전에 패키지의 설치 시점 스크립트를 제거하는 보호 장치가 게시 프로세스에 포함돼 있다고 설명했습니다.¹

Red Hat은 영향을 받은 패키지가 ARO, OSD, ROSA 같은 Red Hat 관리형 클라우드 서비스와 관련이 없다고도 밝혔습니다.¹ 알려진 범위에서는 서비스 영향이 제한적으로 설명됐지만, 공급망 침해의 특성상 조직별 확인은 별도로 필요합니다.

실무적으로는 다음을 우선 확인해야 합니다.

• lockfile에 영향을 받은 패키지와 버전이 포함돼 있는지

• 개발자 PC나 CI 환경에서 해당 버전이 설치된 적이 있는지

• 설치 이력이 있다면 CI 시크릿, 클라우드 자격증명, npm 토큰, GitHub 토큰을 회전해야 하는지

• npm install 단계에서 실행되는 스크립트를 어떻게 통제하고 감사할지

• GitHub Actions 워크플로 실행 권한과 OIDC publish 권한이 과도하게 열려 있지 않은지

영향 패키지 목록과 침해 지표는 Red Hat의 공지와 Aikido 분석을 기준으로 확인하는 것이 좋습니다.¹²

공급망 보안의 기준이 바뀌고 있다

이번 사건은 공식 네임스페이스, trusted publishing, provenance 같은 장치가 불필요하다는 뜻이 아닙니다. 오히려 모두 필요한 방어층입니다. 다만 단독으로 충분하지 않다는 점을 보여줍니다.

이제 공급망 보안의 기준은 “어디서 받은 패키지인가”에만 머물 수 없습니다. “어떤 계정과 워크플로가 빌드·게시를 수행했는가”, “설치 중 어떤 코드가 실행되는가”, “CI 환경의 권한이 어디까지 열려 있는가”까지 함께 봐야 합니다.

Red Hat NPM 백도어 사건의 실질적인 교훈은 명확합니다. 신뢰는 패키지 이름이나 조직 네임스페이스가 아니라, 계정·워크플로·게시 권한·설치 스크립트까지 이어지는 전체 경로에서 검증돼야 합니다.

참고

¹RHSB-2026-006 Supply chain compromise of @redhat-cloud-services npm packages

²Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm