npm 공급망 공격 axios 악성 패키지 사태와 국내 개발자 대응법

2026년 3월, 국내 수백만 개 프로젝트에 깔려 있는 axios가 악성 패키지로 오염됐어요. 주간 다운로드 수 5,000만 건이 넘는 패키지가 공격자 손에 들어갔고, 짧은 시간 동안 원격 접근 트로이목마(RAT)가 실제로 배포됐죠. npm 공급망 공격 axios 악성 패키지 사태는 “언젠가 올 일"이 아니라 “이미 일어난 일"이 됐어요.

핵심 요약

• 2026년 3월, axios 유지관리자 계정이 탈취되면서 [email protected]과 [email protected] 두 버전에 RAT(원격 접근 트로이목마)가 심어진 채 배포됐어요.
• 악성 패키지는 배포 직후 Socket.dev와 Aikido Security의 자동 탐지 시스템에 의해 수 시간 내 발견됐고, npm 레지스트리에서 즉시 내려졌어요.
• 공격의 진입점은 취약한 MFA 설정이었어요. 계정 보안 단 하나의 구멍이 전 세계 의존성 트리를 오염시킬 수 있다는 걸 다시 증명했죠.
• package-lock.json 무결성 검증과 npm audit만으로는 부족해요. 공급망 수준의 모니터링 도구가 필요한 시점이에요.
• 국내 개발자와 기업은 의존성 고정(pinning), SCA 도구 도입, 빌드 파이프라인 서명 검증 세 가지를 지금 점검해야 해요.

이번 공격, 정확히 무슨 일이 있었나요

공격 타임라인

axios는 JavaScript 생태계에서 HTTP 요청을 처리하는 가장 대표적인 라이브러리예요. npm 주간 다운로드 5,000만 건 이상, GitHub 스타 10만 개 이상. Node.js 백엔드, React 프론트엔드, React Native 앱 가릴 것 없이 거의 모든 프로젝트에 들어가 있다고 봐도 돼요.

공격자는 axios 유지관리자 중 한 명의 npm 계정 자격증명을 탈취했어요. MFA(다단계 인증)가 충분히 설정되지 않은 상태였다고 Aikido Security가 분석했죠. 계정을 손에 넣자마자 두 버전 — [email protected]과 [email protected] — 을 정식 릴리스처럼 배포했어요.

패키지 안에는 외부 서버에서 추가 스크립트를 내려받아 실행하는 코드가 숨어 있었어요. 전형적인 RAT 드롭퍼 패턴이에요. 설치 시점에 postinstall 스크립트가 실행되면서 감염이 이뤄지는 구조였고요.

Socket.dev의 자동 분석 엔진이 이상 행동을 탐지한 건 배포 후 수 시간 이내였어요. npm 레지스트리에서 해당 버전이 내려간 뒤 axios 공식 GitHub 이슈(#10604)를 통해 공개 공지가 나왔죠. 발견이 빨랐던 덕에 대규모 피해는 막았지만, 그 짧은 시간 동안 얼마나 많은 CI/CD 파이프라인이 해당 버전을 당겨 갔는지는 여전히 추적 중이에요.

이게 지금 문제인 이유

이번 사건이 특별한 건, 피해 대상이 “보안에 무감각한 개발자"가 아니라는 점이에요. axios를 쓰는 개발자라면 대부분 npm install, npm audit, package-lock.json 정도는 이미 알고 있거든요. 그런데도 뚫렸어요.

이유는 하나예요. 공격이 코드 수준이 아니라 공급망 계정 수준에서 일어났기 때문이에요. 코드 리뷰도, 정적 분석도, npm audit도 “공식 유지관리자가 직접 올린 버전"은 기본적으로 신뢰해요. 여기가 맹점이에요.

공격 방식 비교: 전통적 취약점 vs. 공급망 탈취

국내 개발자 대응법을 논하기 전에, 두 가지 공격 방식의 차이를 짚어볼게요. 대응 전략이 완전히 달라지거든요.

표에서 가장 눈에 띄는 건 “탐지 방법” 열이에요. 전통적 취약점은 npm audit 하나로 어느 정도 커버되지만, 공급망 탈취는 행동 분석 — 패키지가 실제로 어떤 행동을 하는지 실시간으로 보는 도구 — 없이는 잡기 어렵죠.

Socket.dev가 이번 사태를 빠르게 잡은 것도 바로 이 행동 분석 엔진 덕분이에요. npm 레지스트리에 새 버전이 올라오는 순간 자동으로 코드 패턴을 분석해서 “이 패키지가 갑자기 외부 URL에 접근하려 해요"라는 신호를 잡아낸 거예요.

국내 개발자 대응법: 지금 당장 할 것 세 가지

1단계: 버전 고정부터

package.json에 "axios": "^1.6.0" 이렇게 캐럿(^)이 붙어 있으면 npm은 마이너 버전을 자동으로 올려요. 1.14.1 같은 악성 버전이 릴리스되는 순간 CI/CD가 자동으로 당겨 갔을 거예요.

지금 당장 할 일:

• package.json에서 ^, ~ 기호 제거, 정확한 버전으로 고정
• package-lock.json을 Git에 반드시 커밋하고 CI에서 npm ci 사용 (의존성 변경 시 빌드 실패 유도)
• Renovate Bot 같은 도구로 업데이트를 수동 검토 프로세스로 전환

2단계: SCA 도구 파이프라인에 붙이기

npm audit의 한계는 이미 CVE가 등록된 취약점만 잡는다는 거예요. 이번 axios 악성 패키지처럼 신규 공급망 공격은 CVE 등록 전에 이미 피해가 나요.

국내 개발 환경에서 당장 적용 가능한 도구들:

• Socket.dev: npm 패키지 행동 분석 특화. GitHub Actions에 직접 붙일 수 있어요. 무료 플랜도 꽤 괜찮아요.
• Snyk: SCA + SAST 통합. 국내 기업 도입 사례가 많고, CI/CD 플러그인이 잘 정비돼 있어요.
• OSSF Scorecard: 오픈소스 패키지의 보안 관행(MFA 설정, 코드 리뷰 여부 등)을 점수화해줘요.

GitHub Actions에 Snyk 붙이는 건 30분이면 돼요. 안 하는 이유가 없어요.

3단계: 빌드 아티팩트 서명 검증

조금 더 인프라 수준의 얘기예요. npm provenance(출처 증명) 기능이 2023년부터 공식 지원되기 시작했어요. 패키지가 어떤 소스코드에서, 어떤 CI 환경에서 빌드됐는지를 암호화 서명으로 증명하는 방식이에요.

axios 공식 팀이 앞으로 provenance를 적용한다면, npm install 시점에 “이 패키지는 정말 axios/axios GitHub 저장소에서 빌드됐나?“를 검증할 수 있게 돼요. 국내 내부 패키지를 운영하는 팀이라면 지금부터 적용해볼 만한 방향이에요.

앞으로 6개월, 뭘 봐야 하나요

요약하면 이렇게 됐어요:

• axios 유지관리자 계정 탈취 → RAT 심은 버전 두 개 배포
• 수 시간 내 탐지, 삭제됐지만 자동 업데이트 환경은 취약 노출
• npm audit만으로는 이런 공격을 막을 수 없다는 게 확인됐어요
• 의존성 고정 + 행동 분석 도구 + 빌드 서명이 실질적 방어선이에요

앞으로 6개월 안에 npm 레지스트리 차원의 MFA 강제화 정책이 더 넓어질 가능성이 있어요. npm은 이미 상위 패키지 유지관리자에 대한 MFA 의무화를 단계적으로 확대 중이거든요. axios 같은 고영향 패키지가 이번 사태를 계기로 더 빠르게 그 범위에 포함될 거예요.

국내 기업 입장에서는 내부 보안 정책에 “타사 패키지 버전 고정 및 행동 분석 도구 의무화"를 공식 항목으로 넣을 타이밍이 왔어요.

자, 마지막 질문 하나만요. 지금 여러분 프로젝트의 package.json을 열어보면, axios 버전 앞에 ^가 붙어 있나요? 국내 개발자 대응법의 첫 번째는 그 캐럿 기호 하나 지우는 것에서 시작해요.

참고 자료

• Socket.dev, Supply Chain Attack on Axios Pulls Malicious Dependency, 2026
• Aikido Security, axios compromised on npm: maintainer account hijacked, RAT deployed, 2026
• axios GitHub Issue #10604, [email protected] and [email protected] are compromised, 2026

참고자료

1. Supply Chain Attack on Axios Pulls Malicious Dependency from…
2. axios compromised on npm: maintainer account hijacked, RAT deployed
3. [email protected] and [email protected] are compromised · Issue #10604 · axios/axios

Photo by P. L. on Unsplash