Axios npm 패키지 침해 사고에서 발생한 일
Axios npm 패키지 침해 스토리는 최신 소프트웨어 위험이 항상 기존 CVE 또는 소스 코드에서 공개된 결함으로 도착하지는 않는다는 것을 상기시켜 줍니다. 때때로 실제 문제는 침해된 패키지 릴리스, 중독된 종속성 체인 및 일상적인 업데이트를 보안 사고로 전환하는 설치 시간 실행 경로입니다.
보안 및 IT 팀의 경우, 긴급한 질문은 단순히 “Axios가 영향을 받았습니까?”가 아닙니다. 하지만 실제로 영향을 받는 버전이 있는 곳은 어디이고, 무엇을 실행했으며, 지금 재구성하거나 조사해야 하는 것은 무엇입니까?
최근 업계 보고 에 따르면 공격자는 유지 관리 계정을 손상시킨 후 악성 Axios 패키지 버전을 npm에 게시했습니다. 악성 릴리스는 메인 버전 분기와 레거시 버전 분기 모두에 영향을 미쳤으며 주로 설치 시간 실행을 트리거하기 위해 존재했던 종속성을 도입한 것으로 보고되었습니다.
[Linux 관리자: 권한 없는 사용자에게 루트에 대한 실질적인 경로를 제공하는 커널 권한 에스컬레이션 취약성인 Copy Fail에 대해 알아야 할 사항은 다음과 같습니다.]
중요한 점은 다음과 같습니다.Axios 자체 는 원격 트리거 가능한 소프트웨어 버그라는 고전적인 의미에서 '익스플로팅'되지 않았다는 것입니다. 대신 소프트웨어 공급망에서 위험이 발생했습니다.
이 사고가 중요한 이유
Axios는 Sonatype에 따르면 2025년에 주요 오픈 소스 레지스트리에서 454.600 개 이상의 새로운 악성 패키지가 식별된 에코시스템에서 가장 널리 사용되는 JavaScript HTTP 클라이언트 중 하나입니다.
Axios는 다음 분야에서 사용됩니다.
- 개발자 워크스테이션
- CI/CD 러너
- 서버 구축
- 에페메랄 클라우드 워크로드
- 종속성을 동적으로 설치하는 프로덕션 시스템
광범위한 채택을 가진 패키지가 침해되면, 블래스트 반경은 패키지의 인기만으로는 덜 형성되고 노출 기간 동안 실제로 영향을 받는 버전을 해결 및 설치한 환경의 수에 의해서 더 많이 형성됩니다.
주간 다운로드를 통해 Axios는 npm 에코시스템에서 가장 널리 사용되는 JavaScript HTTP 클라이언트 라이브러리 중 하나가 되었으며, 이는 2026년 3월 공급망 공격 중에 짧은 노출 기간조차도 엄청난 잠재적 영향을 미쳤다는 것을 의미합니다.
보고된 악성 버전
공개 보고에 따르면 가장 빈번하게 악성으로 식별된 버전은 다음과 같습니다.
| 패키지 | 버전 |
|---|---|
| 옥시오스 | 1,14,1 |
| 옥시오스 | 0,30,4 |
또한 공개 분석은 설치 후 동작을 트리거하는 데 사용되는 예기치 않은 종속성과 침해를 연결했습니다.
| 의심스러운 의존성 | 버전 |
|---|---|
| 일반-암호-js | 4,2,1 |
환경에 이러한 패키지 버전 또는 위의 예기치 않은 종속성이 포함되어 있는 경우, 이는 추가 조사를 위한 강력한 신호일 수 있습니다.
독립적인 리버스 엔지니어링 및 위협 분석은 npm 생태계의 종속 패키지가 2026년 3월 공급망 침해 당시 Axios에 의존했음을 보여주며, 이는 악성 패키지 발행물의 잠재적인 폭발 반경을 보여줍니다.
Axios npm 패키지 침해가 일반적인 취약성과 다른 이유
대부분의 취약성 프로그램은 알려진 결함, 영향을 받는 버전 범위 및 패치 지침을 중심으로 설계되었습니다. 이 이벤트는 몇 가지 중요한 방식으로 모델을 끊습니다.
단순한 코드 결함이 아니라 패키지 신뢰 문제였다
위험은 악성 게시 이벤트에서 비롯되었습니다. 이는 다음을 의미합니다.
- 응답을 고정할 CVE가 없을 수 있음
- 패키지 메타데이터는 소스 코드만큼 중요합니다
- 종속성 해결 동작이 공격 표면의 일부가 됨
- 설치 스크립트 및 설치 후 후크가 중요한 증거가 됨
종속성 경로를 대상으로 함
많은 팀은 여전히 package.json의 직접적인 종속성에 집중하고 있습니다. 그러나 침해된 종속성을 통해 발생하는 많은 공급망 공격으로 인해 이와 같은 사고는 일시적인 가상 종속성이 중요한 이유를 보여줍니다.
이로 인해 기존 앱 검토가 저절로 불충분해집니다.
운영 체제를 넘었습니다
공개 연구에 따르면 설치 체인이 Windows, macOS 및 Linux에서 플랫폼별 동작으로 이어졌습니다. 이는 '개발자 노트북 위험' 또는 'Linux 빌드 에이전트 위험'에서 대응을 중지할 수 없기 때문에 중요합니다. 팀은 교차 플랫폼 가시성이 필요합니다.
보안 팀이 먼저 해야 할 일
체인 사고를 확대할 때 팀은 실제로 존재하는 것을 확인하기 전에 추측으로 넘어가는 경우가 많습니다. 지표를 추적하기 전에 가장 간단한 질문으로 시작합니다.
환경에 영향을 받는 패키지 버전이 있습니까?
그 순서는 중요합니다.
프레즌스로 시작한 다음 행동으로 이동하고 영향을 평가합니다
실제 대응 모델은 다음과 같을 수 있습니다.
| 단계 | 질문 | 중요한 이유 |
|---|---|---|
| 프레즌스 | 영향을 받는 Axios 버전 또는 관련 종속 아티팩트가 있습니까? | 노출이 실제인지 또는 가상인지 확인 |
| 행동 | 설치 시간 스크립트, 하위 프로세스 또는 아웃바운드 연결이 발생했습니까? | 휴면 노출을 실행 가능성과 구분 |
| Impact | 비밀, 자격 증명 또는 영구 발판이 도입되었습니까? | 억제 및 재구축 범위 결정 |
이러한 접근 방식은 소음을 줄이고 팀이 실제 노출에서 빠르게 움직이면서 헤드라인에 대한 과잉 반응을 피하는 데 도움이 됩니다.
환경에서 찾아야 할 사항
Axios npm 패키지 손상으로 인한 잠재적 노출을 평가하는 경우, 엔드포인트, 서버 및 CI/CD 시스템에서 패키지 증거, 프로세스 동작, 파일 아티팩트 및 네트워크 활동의 조합을 확인합니다.
패키지 수준 증거
다음을 확인합니다.
- axios 버전 1,14,1
- axios 버전 0,30,4
- 일반-암호-js 버전 4,2,1
- 예기치 않은 종속성 해결을 도입한 Lockfile 변경 사항
- 알려진 노출 기간 동안 패키지 설치
엔드포인트 및 워크로드 증거
플랫폼에 따라 조사관은 설치 시간 스크립트 실행, 단계적 페이로드 다운로드 또는 Node.js 또는 npm에서 발생한 의심스러운 하위 프로세스와 일치하는 표지판을 찾아야 합니다.
유용한 범주는 다음과 같습니다.
- npm 또는 노드에 의해 셸 또는 스크립트 실행 발생
- 패키지 설치 후 예기치 않은 PowerShell, Python, curl 또는 셸 작업
- 임시 디렉터리에 파일 쓰기
- 이름 변경 또는 가짜 바이너리
- 분리된 백그라운드 프로세스
- 개발자 또는 빌드 시스템의 비정상적인 아웃바운드 트래픽
CI/CD 증거
빌드 파이프라인은 다음과 같은 경우가 많기 때문에 특별한 주의를 기울여야 합니다.
- 광범위한 네트워크 액세스
- 주입된 비밀
- 클라우드 자격 증명
- 배포 토큰
- 자동화된 패키지 해상도
CI 러너가 악성 패키지 버전을 설치한 경우 이벤트를 개발 종속성 스커 이상으로 취급합니다. 검토:
- 워크플로 로그
- 종속성 해결 타이밍
- 아웃바운드 네트워크 연결
- 작업에 사용할 수 있는 비밀
- 윈도우 동안 생성된 빌드에 대한 아티팩트 무결성
즉각적인 복구 단계
영향을 받는 버전의 존재를 확인하는 경우 빠르고 체계적으로 이동합니다.
아래 작업은 Axios npm 패키지 침해와 같은 공급망 사고 중에 사용되는 일반적인 억제 조치를 반영합니다. 이는 고정된 순서로 실행되도록 의도되지 않았으며, 조직은 시스템 중요도, 승인 요구 사항 및 위험 허용 오차를 기반으로 이를 적용해야 합니다.
방지 체크리스트
| 작업 | 중요한 이유 |
|---|---|
| 알려진 안전한 Axios 버전에 대한 핀 | 조사 중에 추가 시스템이 영향을 받는 릴리스를 해결하거나 설치하지 못하도록 방지 |
| 의심스러운 종속성 아티팩트 제거 | 캐시된 설치 또는 잠금 파일 드리프트를 통해 중독된 종속성이 다시 도입되지 않도록 보장 |
| 노출 중 npm 설치를 실행한 시스템 검토 | 엔드포인트, CI 러너 및 설치 시간 스크립트를 실행했을 가능성이 가장 높은 시스템 구축에 대한 조사 집중 |
| 영향을 받는 빌드 또는 런타임 컨텍스트에 노출되는 자격 증명 회전 | 설치 시간 실행 중에 비밀에 액세스할 수 있는 경우 블래스트 반경을 제한합니다. |
| DNS 및 네트워크 계층에서 알려진 악성 도메인 또는 IP 차단 | 실행이 발생했을 수 있지만 전체 재구축이 지연되는 경우 보상 통제 역할을 합니다. |
| 실행이 확인된 영향을 받는 시스템 재구축 | 자체 세척 또는 관찰하기 어려운 페이로드를 실행했을 수 있는 시스템에 대한 신뢰 회복 |
| 노출 기간 동안 생성된 소프트웨어 아티팩트 감사 | 프로모션 또는 릴리스 전에 아티팩트 무결성을 검증하여 다운스트림 환경 보호 |
안전한 패키지 위생 변경
즉각적인 사고가 해결된 후에도 팀은 패키지 제어를 강화해야 합니다.
- 중요한 종속성에 정확한 버전 고정 선호
- 코드 검토에서 잠금 파일 검증
- 가능한 경우 CI에서 설치 스크립트 제한
- 일상적인 종속성 해결에서 빌드 비밀 분리
- 패키지 게시 및 소비에 대한 산지 확인 시행
- 매니페스트에 존재하지만 실제 애플리케이션 사용이 없는 패키지 모니터링
Tanium이 Axios 공급망 사고를 지원하는 방법
Tanium Gaurdian Axios 공급망 침해 대시보드는 보안 및 IT 팀이 침해된 Axios 패키지가 환경에 존재하는지 여부를 신속하게 이해하고 해당하는 경우 잠재적 영향을 조사하는 데 도움이 됩니다.
대시보드는 먼저 노출 범위 조정에 중점을 두고, 팀은 Tanium SBOM 데이터를 사용하여 침해된 Axios 버전(v1,14,1 및 v0,30,4 레거시)을 추적하여 영향을 받는 패키지가 환경의 어느 곳에든 도입되었는지 여부를 확인할 수 있습니다. 이를 통해 보안 및 IT 팀은 추측을 넘어 공급망 사고에서 가장 즉각적인 질문, 즉 침해된 소프트웨어가 존재하는지 여부에 답변할 수 있습니다.
심층 조사 기능이 활성화된 조직의 경우 대시보드는 macOS, Windows 및 Linux에서 교차 플랫폼 단계 2 조사를 지원하여 RAT 아티팩트 및 악성 종속성과 관련된 잠재적 명령 및 제어 활동을 식별하는 데 도움이 됩니다.
Tanium Threat Response 를 사용할 수 있는 경우 팀은 영향을 받는 엔드포인트 격리와 같은 대응 작업도 수행할 수 있습니다.
대시보드의 전체 기능은 노출 검증, 조사 및 대응에 대한 Tanium의 모듈식 접근 방식을 반영하여 적절한 보고 및 보기 역할을 가진 Tanium SBOM 및 Tanium Threat Response를 마련하는 데 달려 있습니다.
SBOM 데이터가 응답 대화를 변경하는 이유
CISA, NSA 및 19 개의 국제 파트너가 채택을 필수적인 보안 이정표로 선언한 경우에도 소프트웨어 재료표 는 때때로 규정 준수 아티팩트로 취급됩니다. 이와 같은 사고는 해당 보기가 너무 좁은 이유를 보여줍니다.
패키지 침해가 발생하면 SBOM 데이터는 영향을 받은 패키지가 포함된 구축된 아티팩트, 포함된 버전 및 관련된 의심스러운 종속성이 선언되었는지 여부에 대한 답변을 제공합니다. 이러한 아티팩트가 배포된 위치 또는 패키지를 설치한 시스템을 확인하려면 추가 엔드포인트, 컨테이너 및 파이프라인 원격 측정이 필요합니다.
이러한 가시성이 없으면 팀은 대략적인 프록시에 의존하는 경향이 있습니다.
- 저장소 검색
- 개발자 자체 보고
- 불완전한 EDR 단서
- 수동 잠금파일 검토
- 설치해야 하는 것에 대한 가정
이는 유용한 입력 요소이지만 환경 수준의 증거를 대체하지는 않습니다.
SBOM 대 가정 중심 분류
SBOM 지원 분류는 리포지션 또는 경고만으로 추론되지 않고 엔드포인트에 실제로 존재하는 것에 기반합니다.
| 접근법 | 빠르게 배우는 것 | 제한 사항 |
|---|---|---|
| SBOM 지원 노출 검토 | 종종 버전 세부 정보와 함께 알려진 빌드 아티팩트에 패키지/구성 요소 존재 | 여전히 현재 SBOM과 아티팩트에서 배포된 자산에 대한 신뢰할 수 있는 매핑이 필요합니다. |
| Repo 전용 검토 | 선언된 종속성 의도 | 드리프트, 일시적 해결 및 런타임 현실을 놓침 |
| 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 및 0,30,4 를 일관되게 강조했습니다.
Axios npm 패키지가 단기간 지속된다면 왜 손상 중요합니까?
노출 기간 동안 불량 버전을 해결 및 설치하는 경우, 수명이 짧은 패키지 침해는 여전히 고부가가치 시스템에 영향을 미칠 수 있기 때문입니다. 빠른 제거는 이미 발생한 설치를 실행 취소하지 않습니다.
조직은 자격 증명을 회전해야 합니까?
해당 패키지가 비밀, 토큰, 클라우드 자격 증명 또는 배포 키에 액세스할 수 있는 시스템에 설치된 경우 자격 증명 검토 및 순환이 응답의 일부가 되어야 합니다.
소스 리포즈를 확인하는 것이 충분합니까?
아니요. Repo 검토가 도움이 되지만 엔드포인트, 빌드 에이전트 및 워크로드에 실제로 설치된 것을 입증하지는 못합니다. 환경 수준 가시성 이 필수적이며 Tanium과 같은 도구는 엔드포인트 파일 및 프로세스 원격 측정을 제공할 수 있지만 패키지 존재는 종종 추가 아티팩트, 저장소 및 파이프라인 데이터로 확인해야 합니다.
Axios npm 패키지의 더 큰 교훈은
성숙한 사고 대응은 취약성 피드 이상에 따라 달라집니다. 이를 위해서는 세 가지 기본 질문에 빠르게 답변할 수 있는 능력이 필요합니다.
- 영향을 받는 패키지는 실제로 어디에 있습니까?
- 설치 후 어떤 동작이 발생했습니까?
- 어떤 운영상의 영향을 따랐습니까?
보안팀의 경우, 이는 헤드라인에 대한 대응과 사실에 대한 대응의 차이입니다. XZ Utils 및 3CX 과 같이 신뢰할 수 있는 개발자 액세스 또는 구축 인프라가 백도어를 도입하기 위해 남용된 최근 공급망 사고에서도 유사한 교훈이 드러났습니다. 이를 통해 팀은 CVE 전용 렌즈를 통해 소프트웨어 위험을 너무 좁게 평가하는 것을 피해야 하는 이유를 강화했습니다.
추가 리소스
- Tanium Guardian Axios 지원 체인 침해 대시보드
- Axios 웹사이트
- OpenSourceMalware 커뮤니티 위협 데이터베이스 Axios 침해 분석
- Elastic Security 기술 분석
팀이 엔드포인트, 서버 및 소프트웨어가 실제로 설치되고 실행되는 빌드 환경 전반에서 종속성 노출을 검증하는 방법을 재고하고 있는 경우 Tanium은 팀이 실제 존재로 시작하고, 규율에 따라 행동을 조사하고, 검증된 실시간 엔드포인트 인텔리전스를 사용하여 대응할 수 있도록 지원합니다. 사용자 환경에 맞춤화된 무료 데모 를 예약합니다.
