Axios npm 공급망 공격 분석

서론

2026년 3월 말 공개된 Axios 공급망 공격은 단순한 패키지 오염 사건이 아니라, 널리 사용되는 오픈소스 배포 경로가 실제 침해 지점이 될 수 있음을 다시 보여준 사례다. 이번 이슈에서는 npm 배포 계정 침해, 악성 버전 게시, 후속 페이로드 실행, 그리고 대응 과정까지 한 흐름으로 이어졌다는 점이 중요하다. 이 글은 공개된 분석 자료를 기준으로 사고 경과와 기술적 포인트, 실무 대응 관점에서 확인해야 할 사항을 정리한다.

핵심 포인트

분류: Supply Chain Attack / npm / RAT
심각도: Critical
행위자: UNC1069로 공개 귀속
핵심 버전: axios@1.14.1, axios@0.30.4

• 공격자는 npm 배포 경로를 악용해 악성 Axios 버전을 실제 레지스트리에 게시했다.
• 악성 패키지는 추가 의존성을 통해 설치 후 실행 흐름을 유도했다.
• 공개 분석 기준 Windows, macOS, Linux 전반을 노린 다중 플랫폼 행위가 확인됐다.
• 노출 시간이 길지는 않았지만, 생태계 영향력 때문에 파급도는 매우 컸다.

사고 타임라인

기술 분석

배포 경로 침해

이번 사례의 핵심은 애플리케이션 취약점이 아니라 공급망 자체가 공격면이 되었다는 점이다. 정식 패키지 배포 권한이 악용되면 사용자나 CI 환경은 평소와 동일한 설치 동작만으로 악성 코드 실행 경로에 들어갈 수 있다.

설치 후 실행 흐름

공개된 분석에 따르면 악성 의존성은 postinstall 계열 흐름을 통해 추가 스크립트를 실행했고, 운영체제별로 서로 다른 페이로드를 받아오는 방식이 사용됐다.

{
  "scripts": {
    "postinstall": "node setup.js"
  }
}

이 구조는 코드 리뷰만으로 탐지하기 어렵고, 이미 설치가 이뤄진 뒤에야 흔적이 남는다는 점에서 대응 난도를 높인다.

운영체제별 행위

영향 범위

영향 범위는 단순히 Axios를 직접 사용하는 프로젝트로 끝나지 않는다. 간접 의존성 체인 안에 포함된 경우에도 동일한 설치 경로를 따라 감염 가능성이 생긴다. 특히 CI/CD, 개발자 워크스테이션, 빌드 캐시 서버처럼 패키지 설치가 반복적으로 이뤄지는 환경은 우선 점검 대상이다.

IOC 및 점검 포인트

점검 시에는 아래 항목을 함께 보는 것이 좋다.

• 개발자 PC와 CI 로그에서 해당 버전 설치 흔적 확인
• 빌드 스크립트 및 lockfile 변경 이력 확인
• 설치 시점 전후의 비정상 네트워크 통신 점검
• 노출된 토큰, API 키, 배포 자격 증명 전면 교체

대응 방안

1. npm ls axios 또는 lockfile 기준으로 영향 버전 사용 여부를 우선 확인한다.
2. 영향 버전이 설치된 환경은 정상 버전으로 교체하고 캐시를 함께 정리한다.
3. 설치 시점에 사용된 npm 토큰, CI 비밀값, 클라우드 자격 증명을 회전한다.
4. EDR, 프록시, DNS 로그 기준으로 공개 IOC와 연관된 흔적을 재조사한다.
5. 장기적으로는 Trusted Publishing, 최소 권한 토큰, 패키지 무결성 검증 정책을 강화한다.

결론

이번 사건은 오픈소스 생태계에서 신뢰의 단위가 코드 저장소만이 아니라 배포 권한, 레지스트리 태그, 설치 자동화 전반으로 확장되어야 한다는 점을 보여준다. 공급망 공격은 짧은 노출 시간만으로도 큰 파급 효과를 만들 수 있기 때문에, 패키지 버전 통제와 자격 증명 보호, 설치 행위 모니터링이 모두 함께 갖춰져야 한다.

참고 자료

• Google Threat Intelligence Blog
• Socket
• Huntress
• Vercel