2026년 7월, AsyncAPI 이름으로 등록된 npm 패키지 다섯 개 버전이 악성코드를 포함한 채 공식 npm 레지스트리를 통해 배포된 사실이 확인되었다. 설치만으로 RAT와 정보 탈취 기능이 동작해 개발 환경과 CI/CD 파이프라인 전반의 자격 증명이 위험에 노출될 수 있다. 이번 사건은 비공식 패키지를 넘어 공식 유지보수 패키지를 표적으로 옮는 공급망 공격 양상의 전환점으로 평가된다.
- 오염된 패키지: AsyncAPI 명목의 npm 패키지 5개 버전에서 RAT 및 정보 탈취 모듈이 포함된 상태로 배포
- 유포 경로: 공식 npm 레지스트리를 통해 설치 시 자동 실행되어 별도의 사용자 조작 없이 악성 행위가 개시
- 위험 범위: 로컬 개발 환경, CI/CD 빌드, 그리고 의존 패키지를 통해 배포된 산출물의 하위 사용자까지 2차 전파 가능성이 있음
신뢰받는 패키지 이름이라는 안심 효과 자체가 공격 벡터가 될 수 있으며, 의존성 잠금과 서명 검증 절차의 도입을 검토할 필요가 있다.
Bleeping Computer는 2026년 7월 15일, AsyncAPI 프로젝트와 관련된 npm 패키지 일부가 악성코드를 포함한 채 배포된 사실을 공개했다. 이번 사건은 단순한 비공식 패키지의 오염이 아니라, 개발자가 신뢰할 수 있는 공식 채널에서 내려받은 의존성이 곧바로 침투 경로가 될 수 있다는 점을 다시 한번 확인시켜 준 사례다. 본문에서는 공격 경위, 악성코드 동작 방식, 영향 범위 추정, 그리고 조직이 즉시 적용해야 할 대응 절차를 순서대로 정리한다.
공격 개요
오염된 AsyncAPI 패키지 다섯 개 버전이 공식 npm 채널로 배포된 경위
이번 사건에서 확인된 AsyncAPI 관련 npm 패키지는 총 다섯 개의 버전에서 악성코드가 포함된 상태로 공개된 것으로 보고되었다. 공격자는 AsyncAPI라는 이미 개발자 사이에 인지도가 높은 프로젝트 이름을 이용해 패키지 신뢰도를 빌렸으며, 별도의 피싱이나 우회 설치 없이 공식 npm 레지스트리 경로만으로 침투가 이루어졌다는 점이 보고된 위협 요소다. AsyncAPI 프로젝트 측의 공식 입장이나 정상 패키지 목록은 AsyncAPI 공식 프로젝트 페이지에서 별도로 확인할 필요가 있다.
설치만으로 실행된 RAT 및 권한 탈취 흐름
원문에 따르면 배포된 페이로드는 설치 시 실행되는 구조를 가진 것으로 보고되며, 원격 접근 트로이 목마(RAT) 기능과 정보 탈취 모듈이 결합된 형태로 동작한다. 즉, 개발자가 의존성 설치 명령을 실행하고 npm이 패키지 내부 스크립트를 수행하는 과정에서 자격 증명 수집과 외부 통신이 동시에 이루어졌을 가능성이 높다. 특히 토큰, API 키, 그리고 환경 변수에 저장된 시크릿이 외부로 유출될 경우 빌드 서버와 클라우드 권한까지 연쇄적으로 잠재 위험에 노출될 수 있다.
악성코드 동작 방식
정보 탈취 모듈이 수집하는 자격 증명 및 시스템 정보 항목
공급망 공격에서 사용되는 정보 탈취형 악성코드는 일반적으로 다음 항목들을 우선적으로 수집하는 것으로 알려져 있다. 이번 AsyncAPI 사례도 동일한 패턴을 따랐을 것으로 추정되며, 항목별 수집 여부는 침해 지표(IoC) 분석을 통해 추가로 확인해야 한다.
- 환경 변수: npm 토큰, 클라우드 액세스 키, 데이터베이스 접속 정보
- 자격 증명 파일: 브라우저 저장 패스워드, SSH 키, 쿠키, 캐시된 세션
- 시스템 정보: 호스트명, 운영체제 정보, 사용자명, IP 주소
- 코드 자산: 로컬 저장소의 .git 디렉터리, 설정 파일, 하드코딩된 시크릿
원격 명령 제어 채널을 통한 추가 페이로드 추정 시나리오
단순 정보 탈취에 그치지 않고 RAT 기능을 통해 공격자가 추가 명령을 내릴 수 있다면, 감염 시스템은 사실상 내부 거점이 된다. 분석에 따르면 악성코드는 외부 명령 제어(C2) 서버와 연결을 시도하며, 추가 모듈 다운로드, 파일 탐색, 그리고 권한 상승 시도가 가능할 것으로 평가된다. 다만 이러한 2차 행위 시나리오는 침해사고 조사 결과가 공개되지 않은 현재 시점에서는 추정 영역에 머무른다.
영향 범위와 위험도 평가
로컬 개발 환경 및 CI/CD 파이프라인에서 발생할 수 있는 잠재 피해
개발 조직의 가장 큰 노출 지점은 패키지가 실제로 설치되고 실행되는 지점이다. 단순 로컬 머신을 넘어 CI/CD 러너에서 빌드가 수행될 경우, 빌드 환경에 등록된 시크릿, 배포 토큰, 그리고 사설 레지스트리 인증 정보까지 함께 유출될 가능성이 존재한다. 현재 공개된 정보만으로도 위험 등급을 높음(High)으로 분류할 수 있으며, 감염 시점은 정확한 침해사고 조사(IoC 대조 및 포렌식)를 통해 사후적으로 확정해야 한다.
오염된 빌드 산출물을 통한 하위 서비스 사용자에 대한 2차 전파 가능성
악성코드가 포함된 빌드 결과물이 배포 단계까지 그대로 전달되면, 최종 사용자 환경에서도 동일한 페이로드가 동작할 가능성이 있다. 이는 이른바 의존성 2차 전파로 불리며, npm 패키지의 다운스트림 사용자 수에 비례해 잠재 피해 반경이 기하급수적으로 확대될 수 있다. 이러한 2차 피해 시나리오는 아직 공식적으로 확인된 피해 통계가 공개되지 않은 상태이므로 가능성 차원에서의 평가로 해석해야 한다.
대응 권고 사항
package-lock.json 해시 검증과 의존성 잠금 절차 강화
가장 먼저 조직 단위에서 점검해야 할 항목은 의존성 잠금(lock) 정책이다. package-lock.json에 기록된 무결성 해시(integrity 필드)와 실제 다운로드된 패키지의 해시가 일치하는지 빌드 파이프라인 단계에서 검증하도록 설정하면, 중간 경로에서 페이로드가 변조되더라도 차단이 가능하다. 또한 npm 9 이후 도입된 npm audit signatures 명령을 주기적으로 실행해 서명 상태를 점검하는 절차도 함께 권장된다.
사내 패키지 화이트리스트와 npm 서명 검증 도입을 통한 재발 방지
장기적 관점에서는 사내에서 허용된 패키지 화이트리스트를 운영체제 수준에서 관리하고, npm 신뢰 패키지 서명(trusted publishing) 기능을 적극적으로 활용할 필요가 있다. 신뢰할 수 있는 패키지 작성자에 대해 npm 측이 보장하는 서명 절차가 활성화되어 있다면, 이름만 유사한 위장 패키지가 정상 채널에 게재되더라도 검출 가능성이 높아진다. 본 사건은 공격자 비용 대비 잠재 피해가 매우 큰 전형적인 공급망 공격 사례이므로, 일회성 점검에 그치지 않고 의존성 보안 거버넌스를 정기 감사 항목으로 편입하는 것이 바람직하다.
참고 자료: Bleeping Computer 원문 기사, AsyncAPI 공식 프로젝트 페이지
핵심 요약 정리
- 사실: AsyncAPI 명목의 npm 패키지 5개 버전에서 RAT 및 정보 탈취 모듈이 포함된 채 공식 레지스트리로 배포되었다.
- 사실: 감염 경로는 별도의 피싱 없이 의존성 설치 명령만으로 자동 실행되는 형태로 보고되었다.
- 의견: 빌드 서버와 배포 파이프라인까지 영향을 줄 가능성이 있어 위험 등급을 높음으로 평가하는 것이 타당하다.
- 조치: package-lock 해시 검증과 npm 서명 감사, 사내 화이트리스트 운영을 즉시 점검 항목으로 편입해야 한다.
- 시사점: 공급망 공격의 표적이 공식 패키지로 이동하고 있으므로, 의존성 보안은 개발 조직의 상시 보안 업무로 전환되어야 한다.