Axios npm 패키지 해킹 사건에서 무슨 일이 있었나
Axios npm 패키지 해킹 사건은 현대의 소프트웨어 위험이 항상 기존의 CVE나 소스 코드에서 공개된 결함의 형태로만 나타나는 것은 아니라는 점을 상기시켜 줍니다. 때로는 진짜 문제는 보안이 침해된 패키지 릴리스, 손상된 의존성 체인, 그리고 일상적인 업데이트를 보안 사고로 바꿔버리는 설치 시 실행 경로 때문일 수 있습니다.
보안 및 IT 팀에게 있어 시급한 질문은 단순히 “Axios가 영향을 받았는가?”가 아닙니다. 하지만 “실제로 문제가 있는 버전은 어디에 있는지, 어떤 것이 실행되었는지, 그리고 지금 재빌드하거나 조사해야 할 것은 무엇인지?”
최근 업계 보도에 따르면( ), 공격자들이 유지보수 담당자의 계정을 탈취한 후 npm 에 악성 Axios 패키지 버전을 게시한 것으로 나타났습니다. 보도에 따르면, ‘ ’라는 악성 릴리스는 의 메인 및 레거시 버전 브랜치 모두에 영향을 미쳤으며, 주로 설치 시점에 실행을 유발하기 위해 존재하는 의존성을 도입했습니다.
의 핵심은 다음과 같습니다: Axios 자체는 원격으로 유발될 수 있는 소프트웨어 버그라는 전통적인 의미에서 “악용”된 것은 아닙니다. 오히려 위험은 소프트웨어 공급망에서 비롯되었습니다.
이 사건이 중요한 이유
Sonatype( )에 따르면, 2025,년 동안 주요 오픈소스 레지스트리 전반에서 454.600 개 이상의 새로운 악성 패키지가 확인된 생태계에서 Axios는 가장 널리 사용되는 자바스크립트 HTTP 클라이언트 중 하나입니다.
Axios는 다음에서 사용됩니다:
- 개발자용 워크스테이션
- CI/CD 실행기
- 빌드 서버
- 일시적인 클라우드 워크로드
- 의존성을 동적으로 설치하는 프로덕션 시스템
널리 사용되는 패키지가 침해당했을 때, 그 영향 범위는 단순히 패키지의 인기에 의해서만 결정되는 것이 아니라, 노출 기간 동안 실제로 해당 버전을 해결하여 설치한 환경의 수에 더 크게 좌우됩니다.
주간 다운로드 수 덕분에 Axios는 npm 생태계에서 가장 널리 사용되는 자바스크립트 HTTP 클라이언트 라이브러리 중 하나가 되었으며, 이는 ‘ 2026년 3월 ’ 공급망 공격 당시 짧은 노출 기간만으로도 막대한 잠재적 영향을 미칠 수 있었음을 의미합니다.
악성 버전이 보고된 사례
공개된 보고서를 바탕으로 볼 때, 악성 코드로 가장 자주 확인된 버전은 다음과 같습니다:
| 패키지 | 버전 |
|---|---|
| axios | 1,14,1 |
| axios | 0,30,4 |
공개 분석에 따르면, 이 타협안은 설치 후 동작을 유발하는 데 사용된 예상치 못한 종속성과도 관련이 있는 것으로 나타났다.
| 의심스러운 의존성 | 버전 |
|---|---|
| plain-crypto-js | 4,2,1 |
사용 중인 환경에 해당 패키지 버전이나 위에서 언급한 예상치 못한 종속성이 포함되어 있다면, 이는 추가 조사가 필요하다는 강력한 신호일 수 있습니다.
의 독립적인 리버스 엔지니어링 및 위협 분석에 따르면, 2026년 3월 공급망 침해 사건 당시 npm 생태계 내의 종속 패키지들이 Axios에 의존하고 있었던 것으로 나타났으며, 이는 악성 패키지 배포가 초래할 수 있는 잠재적 파급 효과를 보여줍니다.
Axios npm 패키지 해킹 사건이 일반적인 취약점과 다른 이유
대부분의 취약점 대응 프로그램은 알려진 결함, 영향을 받는 버전 범위 및 패치 지침을 중심으로 설계됩니다. 이번 행사는 몇 가지 중요한 측면에서 그 모델을 깨뜨립니다.
이는 단순한 코드 결함이 아니라 패키지 트러스트 문제였습니다.
이 위험은 악의적인 게시 이벤트에서 비롯되었습니다. 즉, 다음과 같은 뜻입니다:
- 대응 조치를 뒷받침할 CVE가 없을 수도 있습니다.
- 패키지 메타데이터는 소스 코드만큼이나 중요합니다
- 의존성 해결 방식이 공격 표면의 일부가 된다
- 설치 스크립트와 설치 후 후크가 결정적인 증거가 된다
의존성 경로를 대상으로 삼았다
여전히 많은 팀이 package.json에 명시된 직접적인 종속성에만 초점을 맞추고 있습니다. 하지만 많은 공급망 공격이 보안이 침해된 종속성을 통해 발생한다는 점을 고려할 때, 이와 같은 사건들은 전이적 종속성과 팬텀 종속성이 왜 중요한지를 보여줍니다.
따라서 기존의 앱 심사 방식만으로는 충분하지 않습니다.
여러 운영 체제를 아우르고 있습니다
공개된 연구 결과에 따르면, 이 설치 체인이 Windows, macOS 및 Linux에서 플랫폼별 동작을 유발한 것으로 나타났습니다. 이는 대응이 단순히 “개발자 노트북의 위험”이나 “리눅스 빌드 에이전트의 위험” 수준에서 그쳐서는 안 되기 때문입니다. 팀에게는 크로스 플랫폼에 걸친 가시성이 필요합니다.
보안 팀이 가장 먼저 해야 할 일
공급망 사고 발생 시, 팀들은 실제 상황을 확인하기도 전에 성급하게 추측에 빠지는 경우가 많습니다. 지표에 얽매이기 전에, 가장 간단한 질문부터 시작해 보세요:
환경 내 어디에든 문제가 있는 패키지 버전이 있나요?
그 순서가 중요합니다.
먼저 ‘존재감’부터 살펴보고, 다음으로 ‘행동’을 살펴본 뒤, ‘영향’을 평가하십시오.
실용적인 대응 모델은 다음과 같을 수 있습니다:
| Step | 질문 | 그것이 왜 중요한가 |
|---|---|---|
| 존재감 | 영향을 받는 Axios 버전이나 관련 종속성 아티팩트가 있나요? | 노출이 실제적인지 가설적인지 확인합니다 |
| 행동 | 설치 시 스크립트, 자식 프로세스 또는 외부 연결이 발생했습니까? | ‘잠재적 노출’과 ‘실행 가능성’을 구분한다 |
| Impact | 비밀 정보, 인증 정보 또는 지속적인 침투 경로가 유입되었는가? | 격리 및 재구축 범위를 결정합니다. |
이러한 접근 방식은 잡음을 줄여주고, 팀이 헤드라인에 과도하게 반응하는 것을 방지하면서도 실제 위험에 대해서는 신속하게 대응할 수 있도록 돕습니다.
주변 환경에서 무엇을 살펴봐야 할까요?
Axios npm 패키지 침해로 인한 잠재적 노출 위험을 평가하고 있다면, 엔드포인트, 서버 및 CI/CD 시스템을 전반적으로 검토하여 패키지 관련 증거, 프로세스 동작, 파일 아티팩트 및 네트워크 활동의 조합을 확인하십시오.
패키지 수준의 증거
다음 사항을 확인하십시오:
- axios 버전 1,14,1
- axios 버전 0,30,4
- plain-crypto-js 버전 4,2,1
- 예상치 못한 종속성 해결을 초래한 Lockfile 변경 사항
- 알려진 노출 기간 동안의 패키지 설치
엔드포인트 및 워크로드 관련 증거
플랫폼에 따라 조사자는 설치 시 스크립트 실행, 단계적 페이로드 다운로드, 또는 Node.js나 npm에서 생성된 의심스러운 자식 프로세스와 일치하는 징후를 찾아야 합니다.
유용한 카테고리로는 다음이 있습니다:
- npm 또는 node에 의해 생성된 쉘 또는 스크립트 실행
- 패키지 설치 후 예상치 못한 PowerShell, Python, curl 또는 셸 활동 발생
- 파일이 임시 디렉터리에 쓰입니다.
- 이름이 변경되었거나 위장된 바이너리 파일
- 분리된 백그라운드 프로세스
- 개발자 또는 빌드 시스템에서 발생하는 비정상적인 아웃바운드 트래픽
CI/CD 사례
빌드 파이프라인은 다음과 같은 특징을 자주 가지고 있기 때문에 각별한 주의를 기울여야 합니다:
- 광범위한 네트워크 접속
- 주입된 비밀
- 클라우드 인증 정보
- 배포 토큰
- 자동화된 패키지 해결
CI 실행기가 악성 패키지 버전을 설치한 경우, 이 사건을 단순한 개발 의존성 관련 우려 이상으로 간주해야 합니다. 리뷰:
- 워크플로우 로그
- 의존성 해결 시점
- 외부 네트워크 연결
- 해당 직무에서 확인할 수 있는 비밀
- 해당 기간 동안 생성된 빌드의 아티팩트 무결성
즉각적인 시정 조치
해당 버전이 사용 중임을 확인했다면, 신속하면서도 체계적으로 대응하십시오.
아래의 조치들은 Axios npm 패키지 침해 사건과 같은 공급망 사고 발생 시 일반적으로 취해지는 대응 조치를 반영한 것입니다. 이 조치들은 반드시 정해진 순서대로 실행되어야 하는 것은 아니며, 조직은 시스템의 중요도, 승인 요건 및 위험 허용 범위를 고려하여 이를 적용해야 합니다.
격리 점검 목록
| 액션 | 그것이 왜 중요한가 |
|---|---|
| 안전함이 확인된 Axios 버전에 고정하기 | 조사 기간 동안 다른 시스템에서 해당 릴리스를 확인하거나 설치하지 못하도록 방지합니다. |
| 의심스러운 종속성 아티팩트 제거 | 캐시된 설치나 락파일(lockfile)의 변동으로 인해 문제가 있는 종속성이 다시 도입되지 않도록 보장합니다. |
| 노출 기간 동안 npm install을 실행한 시스템을 검토하십시오 | 설치 시 스크립트가 실행되었을 가능성이 가장 높은 엔드포인트, CI 실행 환경 및 빌드 시스템에 조사 초점을 맞춥니다. |
| 영향을 받는 빌드 또는 런타임 컨텍스트에 노출된 자격 증명을 순환하여 사용 | 설치 시 실행 중에 시크릿에 접근할 수 있었던 경우, 폭발 반경을 제한합니다. |
| DNS 및 네트워크 계층에서 알려진 악성 도메인이나 IP를 차단합니다. | 실행은 이루어졌을 수 있으나 전체 재구성이 지연되는 경우, 이를 보완하는 제어 역할을 수행합니다. |
| 실행이 확인된 영향을 받은 시스템을 재구축하십시오 | 자체 정화 기능을 수행했거나 탐지하기 어려운 페이로드를 실행했을 가능성이 있는 시스템에 대한 신뢰를 회복합니다. |
| 노출 기간 동안 생성된 감사 소프트웨어 산출물 | 배포 또는 릴리스 전에 아티팩트의 무결성을 검증하여 다운스트림 환경을 보호합니다. |
안전한 포장 위생 관리 개선 사항
당면한 문제가 해결된 후에도 팀은 패키지 관리 체계를 더욱 강화해야 합니다:
- 중요한 종속성의 경우 정확한 버전 고정 방식을 선호합니다
- 코드 검토 시 잠금 파일 유효성 검사
- 가능한 경우 CI에서 설치 스크립트의 사용을 제한하십시오
- 빌드 시크릿을 일상적인 종속성 해결과 분리하기
- 패키지 게시 및 사용 시 출처 검증을 적용한다
- 매니페스트에는 포함되어 있지만 실제 애플리케이션에서는 사용되지 않는 패키지를 모니터링합니다.
타늄(Tanium)이 액시오스(Axios)의 공급망 사고 해결에 어떻게 도움을 줄 수 있는지
의 Tanium Guardian Axios 공급망 침해 대시보드는 보안 및 IT 팀이 해당 환경에 침해된 Axios 패키지가 존재하는지 신속하게 파악하고, 필요한 경우 잠재적인 영향을 조사할 수 있도록 지원합니다.
이 대시보드는 우선 노출 범위 파악에 중점을 두어, 팀이 의 Tanium SBOM( ) 데이터를 활용해 보안 취약점이 발견된 Axios 버전(v1,14,1 및 v0,30,4 레거시 버전)을 추적하고, 해당 패키지가 팀 환경 내 어디에 도입되었는지 확인할 수 있도록 지원합니다. 이를 통해 보안 및 IT 팀은 추측에 그치지 않고, 공급망 사고 발생 시 가장 시급한 질문, 즉 침해된 소프트웨어가 실제로 존재하는지 여부에 대한 답을 얻을 수 있습니다.
심층 조사 기능이 활성화된 조직의 경우, 이 대시보드는 macOS, Windows 및 Linux 전반에 걸친 크로스 플랫폼 Stage 2 조사를 지원하여, 악성 종속성과 관련된 RAT 흔적 및 잠재적인 명령 및 제어 활동을 식별할 수 있도록 돕습니다.
의 Tanium Threat Response( )를 사용할 수 있는 경우, 팀은 영향을 받은 엔드포인트를 격리하는 등의 대응 조치를 취할 수도 있습니다.
대시보드의 모든 기능을 활용하려면 Tanium SBOM 및 Tanium Threat Response가 구축되어 있어야 하며, Tanium의 노출 검증, 조사 및 대응에 대한 모듈식 접근 방식을 반영한 적절한 보고 및 조회 권한이 설정되어 있어야 합니다.
SBOM 데이터가 대응 방안을 어떻게 바꾸는가
소프트웨어 BOM(Bill of Materials) 은 때때로 규정 준수 관련 문서로 취급되기도 하지만, CISA, NSA 및 19 개 국제 파트너 기관 은 이 문서의 채택을 필수적인 보안 이정표로 선언한 바 있습니다. 이와 같은 사건들은 왜 그런 관점이 지나치게 편협한지 보여준다.
패키지 보안 침해 사고가 발생했을 때, SBOM 데이터를 활용하면 어떤 빌드 산출물에 해당 패키지가 포함되었는지, 어떤 버전이 포함되었는지, 그리고 관련 의심스러운 종속성이 선언되었는지 여부를 파악하는 데 도움이 될 수 있습니다. 해당 아티팩트가 어디에 배포되었는지, 또는 어떤 시스템에 해당 패키지가 설치되었는지 파악하려면 엔드포인트, 컨테이너 및 파이프라인에 대한 추가적인 텔레메트리 데이터가 필요합니다.
이러한 가시성이 확보되지 않으면, 팀들은 대략적인 지표에 의존하는 경향이 있습니다:
- 저장소 검색
- 개발자 자체 신고
- 불완전한 EDR 단서
- 수동 잠금 파일 검토
- 무엇을 설치해야 하는지에 대한 가정
그것들은 유용한 정보이긴 하지만, 환경 차원의 증거를 대체할 수는 없습니다.
SBOM 대 가정에 기반한 우선순위 결정
SBOM 기반의 우선순위 결정은 리포지토리나 경고만으로는 추론할 수 없는, 엔드포인트에 실제로 존재하는 내용을 바탕으로 이루어집니다.
| Approach | 금방 익힐 수 있는 것 | 제한 사항 |
|---|---|---|
| SBOM 기반 노출 검토 | 알려진 빌드 아티팩트에 포함된 패키지/컴포넌트 목록(대개 버전 정보 포함) | 여전히 최신 SBOM과 아티팩트에서 배포된 자산으로의 신뢰할 수 있는 매핑이 필요합니다. |
| 리포 전용 검토 | 의존성 의도 선언 | 오차, 전이적 해결, 런타임 현실 |
| IOC 전용 사냥 | 악의적인 행위의 징후 | 휴면 상태이거나 아직 실행되지 않은 노출을 놓칠 수 있음 |
| 개발자에 의한 수동 점검 | 지역적 맥락 | 속도가 느리고, 일관성이 없으며, 확장하기 어렵다 |
StepSecurity의 분석 보고서 에 따르면, 이번 보안 침해 사고는 Axios 소스 코드의 수정 때문이 아니라 예상치 못한 종속성(plain-crypto-js)의 주입에 기인한 것으로 나타났으며, 이는 SBOM과 같은 구성 요소 수준의 가시성이 공급망 사고에서 왜 중요한지를 잘 보여줍니다.
피해야 할 흔한 실수들
Axios npm 패키지 침해 사고에 대응하는 팀들은 몇 가지 예상 가능한 함정에 유의해야 합니다. 아래의 사례들은 이와 같은 공급망 사고에서 흔히 관찰되는 패턴을 반영하고 있지만, 실제 대응 결정은 각 조직의 아키텍처, 위험 허용 범위 및 운영 환경을 고려하여 내려야 합니다.
이 문제를 “단순히 개발자 문제”로 치부하는 것
만약 보안이 침해된 패키지가 CI 환경에서 실행된다면, 그 위험은 개별 개발자의 워크스테이션을 넘어 인증 정보, 빌드 아티팩트, 그리고 하류 환경까지 확대될 수 있습니다. 많은 조직에서 CI 시스템은 개발자 엔드포인트보다 더 광범위한 접근 권한과 더 높은 권한을 가지고 있습니다.
Axios의 직접적인 사용 사례만 찾고 있습니다
노출 범위는 Axios를 직접적인 종속성으로 명시적으로 선언한 애플리케이션에만 국한되지 않을 수 있습니다. 해당 패키지는 전이적 의존성 경로, 일시적인 빌드 컨텍스트 또는 초기 문제 분류 과정에서 간과하기 쉬운 단기적인 환경에 나타날 수 있습니다.
CVE가 없다고 가정하면 긴급도가 낮음을 의미합니다.
공급망 침해는 기존 의 취약점 관리 워크플로우에 명확히 부합하지 않으면서도 실질적인 운영 위험을 초래할 수 있습니다. CVE 기반의 우선순위 결정 방식에 익숙한 팀들은 알려진 취약점 식별자와 일치하지 않는 패키지 신뢰성 관련 사건을 과소평가할 수 있습니다.
실행 확인 후 현장 세척
특히 권한이 높은 환경이나 기밀 정보가 많은 환경에서 악의적인 행위가 확인된 경우, 현장에서 바로 정리를 시도하는 것보다 정상으로 확인된 상태로 시스템을 재구축하는 것이 대개 더 안전합니다. 적절한 대응 방안은 시스템 역할, 권한 수준, 그리고 민감한 인증 정보에 대한 노출 여부에 따라 달라집니다.
조사 워크플로우 예시
아래의 절차는 보안 및 IT 팀이 Axios npm 패키지 침해와 같은 사고에 대한 조사를 구성할 수 있는 한 가지 가능한 방법을 보여줍니다. 이는 예시일 뿐, 반드시 따라야 할 체크리스트가 아니며, 조직의 도구, 환경 및 위험 프로필에 따라 적절히 조정해야 합니다.
1단계: 노출 확인
- 해당 Axios 버전이 포함된 재고 관리 시스템
- 의심스럽거나 예상치 못한 관련 종속성의 존재 여부를 확인하십시오.
- 노출 기간 동안 패키지 설치가 발생한 위치를 표시합니다.
2단계: 실행 조사
- npm 및 Node.js 자식 프로세스 검토
- 임시 파일 생성 및 셸 실행 확인
- 의심스러운 스크립트 인터프리터와 분리된 프로세스를 찾아보세요
- 영향을 받은 호스트의 아웃바운드 네트워크 연결을 상호 연관 짓는다
3단계: 하류에 미치는 영향 평가
- 인증 정보나 비밀 정보에 접근할 수 있었는지 확인하십시오
- 노출 기간 동안 생성된 빌드 아티팩트의 변경 사항을 검토하십시오
- 지속성 또는 2차 페이로드 전달의 지표를 평가한다
- 확신도와 위험도를 고려하여 정리와 재구축 중 하나를 선택하십시오.
4단계: 강화
- 의존성을 안전성이 확인된 버전에 고정하기
- 가능한 한 설치 스크립트의 노출을 줄이십시오
- 의존성 및 SBOM 적용 범위 개선
- CI 비밀 정보 관리 강화
- 출판사의 신뢰도 및 출처 관리 체계 검토
이러한 유형의 대응 방안을 체계화하는 조직의 경우, 보다 포괄적인 취약점 노출 관리 및 규정 준수 관행 을 통해 영향을 받는 자산 전반에 걸쳐 취약점 탐지, 우선순위 지정 및 수정 조치를 연계할 수 있으며, 동시에 환경별 위험에 따라 유연성을 확보할 수 있습니다.
Axios 사건에 관한 자주 묻는 질문
Axios 자체도 취약점이 있었을까?
익스플로잇 경로와 패치가 있는 일반적인 의미의 소프트웨어 결함은 아닙니다. 이 문제는 악의적인 패키지 게시와 관련된 공급망 침해 사건이었습니다.
어떤 버전의 Axios가 영향을 받은 것으로 보고되었나요?
공개된 보도 자료들은 이번 사건과 관련된 악성 npm 릴리스로 ‘axios 1,14,1 ’과 ‘axios 0,30,4 ’를 지속적으로 지목해 왔습니다.
Axios npm 패키지의 보안 침해 사건이 일시적인 것이었음에도 불구하고, 왜 중요한 것일까요?
노출 기간 동안 문제가 있는 버전을 해결하고 설치하게 되면, 일시적인 패키지 보안 침해라도 여전히 고가치 시스템에 영향을 미칠 수 있기 때문입니다. 빠른 제거 기능은 이미 완료된 설치를 되돌리지 않습니다.
조직은 자격 증명을 순환하여 사용해야 할까요?
영향을 받은 패키지가 비밀 정보, 토큰, 클라우드 인증 정보 또는 배포 키에 접근할 수 있는 시스템에 설치된 경우, 대응 조치의 일환으로 인증 정보를 검토하고 주기적으로 갱신해야 합니다.
소스 저장소를 확인하는 것만으로도 충분할까요?
아닙니다. 리포지토리 검토는 도움이 되지만, 엔드포인트, 빌드 에이전트 및 워크로드 전반에 실제로 무엇이 설치되었는지를 입증해 주지는 않습니다. 환경 수준의 가시성 은 필수적이며, Tanium과 같은 도구는 엔드포인트 파일 및 프로세스 텔레메트리 데이터를 제공할 수 있지만, 패키지 존재 여부는 종종 추가적인 아티팩트, 리포지토리 및 파이프라인 데이터를 통해 확인해야 합니다.
Axios npm 패키지 해킹 사건에서 얻을 수 있는 더 큰 교훈
성숙한 사고 대응은 단순히 취약점 정보만으로는 이루어지지 않습니다. 다음과 같은 세 가지 근거에 기반한 질문에 신속하게 답할 수 있는 능력이 필요합니다:
- 문제가 발생한 패키지는 실제로 어디에 있나요?
- 설치 후 어떤 현상이 발생했습니까?
- 그로 인해 어떤 운영상의 영향이 발생했나요?
보안 팀의 입장에서 볼 때, 이는 뉴스 헤드라인에 반응하는 것과 사실에 근거해 대응하는 것의 차이입니다. 최근 발생한 공급망 사고들( )에서도 이와 유사한 교훈( )이 드러났습니다. 예를 들어, , XZ Utils( ), 3CX(), 등의 사례에서 신뢰할 수 있는 개발자의 접근 권한이나 빌드 인프라가 악용되어 백도어가 삽입된 바 있습니다. 이는 팀들이 CVE만을 기준으로 소프트웨어 위험을 지나치게 협소하게 평가하는 것을 피해야 하는 이유를 다시 한번 강조해 줍니다.
추가 자료
- Tanium Guardian Axios 공급망 침해 대시보드
- Axios 웹사이트
- OpenSourceMalware 커뮤니티 위협 데이터베이스 ‘Axios’ 침해 사건 분석
- Elastic Security 기술 분석
팀이 소프트웨어가 실제로 설치 및 실행되는 엔드포인트, 서버, 빌드 환경 전반에 걸쳐 종속성 노출을 검증하는 방식을 재검토하고 있다면, Tanium은 팀이 실제 배포 현황을 기반으로 시작하고, 체계적인 접근 방식으로 동작을 분석하며, 검증된 실시간 엔드포인트 인텔리전스를 활용해 대응할 수 있도록 지원합니다. 귀사의 환경에 맞춰 제공되는 무료 데모 를 예약하세요.
