파이토치 라이트닝 패키지 `lightning` 2.6.2·2.6.3에 공급망 악성코드 심어짐

무슨 일이 터졌나

• PyPI의 딥러닝 프레임워크 패키지 lightning이 공급망 공격에 감염됨

  • 영향 버전은 2026년 4월 30일 게시된 lightning 2.6.2와 2.6.3
  • 이미지 분류기, 대규모 언어 모델(LLM) 파인튜닝, diffusion 모델, 시계열 예측 모델을 만드는 팀이면 의존성 트리 어딘가에 lightning이 들어가 있을 확률이 꽤 높음

• 실행 조건이 무섭게 낮음. pip install lightning 후 모듈 import만 해도 악성코드가 돈다는 얘기임

  • 패키지 안에는 숨겨진 _runtime 디렉터리가 있고, 난독화된 JavaScript 페이로드가 들어 있음
  • 훔치는 대상은 자격 증명, 인증 토큰, 환경변수, 클라우드 시크릿, GitHub 저장소 권한까지 넓게 걸쳐 있음

• 공격 테마는 이전 Mini Shai-Hulud 캠페인과 이어지는 형태로 보임

  • 커밋 메시지 prefix로 EveryBoiWeBuildIsAWormyBoi를 사용함
  • 공개 GitHub 저장소 설명에 A Mini Shai-Hulud has Appeared 같은 문구를 남기는 식으로 IOC가 이어짐

PyPI에서 시작해서 npm으로 번지는 구조

• 이번 공격의 진입점은 PyPI지만, 전파는 npm 생태계까지 건너감

  • 이전 Mini Shai-Hulud가 npm을 직접 노렸다면, 이번엔 파이썬 패키지에서 시작해 JavaScript 페이로드로 움직이는 구조임
  • ML 파이프라인에서 파이썬만 본다고 끝나는 문제가 아니라는 게 포인트

• 악성코드가 npm publish 자격 증명을 찾으면, 해당 토큰으로 배포 가능한 모든 패키지에 드로퍼를 심음

  • setup.mjs와 router_runtime.js를 주입함
  • scripts.preinstall을 바꿔서 설치 시 드로퍼가 실행되게 만듦
  • patch 버전을 올린 뒤 다시 publish함
  • downstream 개발자가 그 npm 패키지를 설치하면 같은 악성코드가 실행되고, 다시 토큰 탈취와 패키지 오염이 반복됨

sequenceDiagram
    participant 개발자환경 as 개발자/CI 환경
    participant PyPI as PyPI lightning
    participant 악성코드 as 악성 JavaScript 페이로드
    participant GitHub as GitHub/클라우드
    participant npm as npm 패키지

    개발자환경->>PyPI: lightning 2.6.2 또는 2.6.3 설치
    개발자환경->>악성코드: 모듈 import 시 자동 실행
    악성코드->>GitHub: 토큰, 환경변수, 시크릿 탈취
    악성코드->>npm: npm publish 토큰 확인
    악성코드->>npm: preinstall 드로퍼 주입 후 재배포
    npm->>개발자환경: downstream 설치자에게 재감염

빼가는 데이터가 너무 넓다

• 파일 시스템에서는 80개가 넘는 credential 경로를 훑음

  • ghp_, gho_, npm_ 토큰을 찾고, 파일당 최대 5MB까지 읽음
  • 로컬 개발자의 홈 디렉터리나 프로젝트 내부에 남은 토큰도 대상임

• 셸과 환경변수도 그대로 털림

  • gh auth token을 실행해 GitHub CLI 토큰을 가져오려 함
  • process.env 전체를 덤프해서 앱 설정, API 키, 배포 시크릿을 한 번에 수집함

• GitHub Actions 러너에서는 한 단계 더 나감

  • Linux 러너에서 Runner.Worker 프로세스 메모리를 embedded Python으로 덤프함
  • isSecret:true로 표시된 시크릿과 GITHUB_REPOSITORY, GITHUB_WORKFLOW 같은 컨텍스트를 추출함
  • 토큰 scope가 repo, workflow를 갖고 있으면 org secrets까지 훑으려 함

• 클라우드 3사도 전부 직접 겨냥함

  • AWS는 환경변수, ~/.aws/credentials, IMDSv2, ECS 메타데이터를 통해 sts:GetCallerIdentity를 호출하고 Secrets Manager·SSM 파라미터를 가져오려 함
  • Azure는 DefaultAzureCredential로 구독을 열거하고 Key Vault 시크릿에 접근함
  • GCP는 GoogleAuth로 인증한 뒤 Secret Manager 시크릿을 열거하고 가져옴

탈취 데이터를 빼내는 방식도 여러 겹임

• 공격자는 데이터 유출 경로를 4개로 나눠 둠

  • 하나가 막혀도 다른 경로로 빠져나가게 만드는 식이라, 단순 방화벽 로그 하나만 보고 안심하면 안 됨

• 첫 번째는 공격자 C2 서버로 HTTPS POST를 날리는 방식임

  • 도메인과 path는 페이로드 안에 암호화된 문자열로 들어 있어 정적 분석을 어렵게 함
  • 포트 443을 쓰기 때문에 일반 HTTPS 트래픽처럼 보일 수 있음

• 두 번째는 GitHub commit search API를 dead-drop처럼 쓰는 방식임

  • EveryBoiWeBuildIsAWormyBoi:<base64(base64(token))> 형태의 커밋 메시지를 검색함
  • 토큰을 double-base64로 디코딩한 뒤 Octokit 클라이언트 인증에 사용함

• 세 번째는 공격자 소유 공개 GitHub 저장소에 훔친 데이터를 커밋하는 방식임

  • Dune 관련 단어로 무작위 이름의 public repo를 만들고 설명에 A Mini Shai-Hulud has Appeared를 넣음
  • results/results-<timestamp>-<n>.json 파일로 credential을 올림
  • 30MB가 넘는 파일은 여러 chunk로 쪼갬
  • 커밋 메시지는 chore: update dependencies처럼 평범하게 위장함

• 네 번째는 피해자 본인 저장소에 훔친 데이터를 밀어 넣는 방식임

  • ghs_ GitHub server token을 얻으면 피해자의 GITHUB_REPOSITORY 모든 브랜치에 데이터를 push하려 함
  • 이 경우 공격자 인프라만 찾는 식의 대응으로는 놓칠 수 있음

개발 도구까지 지속성 확보에 악용함

• 악성코드는 저장소 안에 Claude Code와 VS Code용 자동 실행 훅을 심음

  • 원문은 실제 공격에서 Claude Code hook 시스템이 악용된 초기 문서화 사례일 수 있다고 봄
  • AI 개발 도구가 보안 경계 안쪽으로 들어오면서 새 공격면이 생겼다는 신호로 봐도 됨

• Claude Code 쪽은 .claude/settings.json을 건드림

  • SessionStart hook을 matcher: "*"로 설정함
  • 개발자가 감염된 저장소에서 Claude Code를 열기만 하면 node .vscode/setup.mjs가 실행됨
  • 별도 도구 호출이나 명령 실행 없이 세션 시작만으로 트리거된다는 게 빡센 부분임

• VS Code 쪽은 .vscode/tasks.json을 이용함

  • runOn: folderOpen task로 node .claude/setup.mjs를 실행하게 만듦
  • 폴더를 여는 평범한 행동이 재감염 트리거가 되는 셈임

• setup.mjs는 Bun 런타임까지 알아서 부트스트랩함

  • Bun이 없으면 GitHub Releases에서 bun-v1.3.13을 조용히 다운로드함
  • Linux x64/arm64/musl, macOS x64/arm64, Windows x64/arm64를 처리함
  • 이후 .claude/router_runtime.js를 실행하는데, 이 전체 페이로드 크기가 14.8MB임
  • 실행 후 /tmp에서 흔적을 정리함

지금 확인해야 할 것

• 우선 [email protected], [email protected] 설치 여부를 확인해야 함

  • lockfile, CI 로그, dependency scanner, artifact cache를 같이 봐야 함
  • 최근 스캔이 없다면 새로 돌리는 게 맞음

• 감염 가능성이 있으면 저장소 안의 이상 파일을 확인해야 함

  • .claude/와 .vscode/ 디렉터리에 예상 못 한 settings.json, tasks.json, setup.mjs, router_runtime.js가 있는지 봐야 함
  • Formatter라는 GitHub Actions workflow가 생겼는지도 확인해야 함
  • 이 workflow는 push마다 ${{ toJSON(secrets) }}로 저장소 시크릿을 덤프하고 format-results artifact로 올리려 함

• IOC도 GitHub에서 검색할 만함

  • EveryBoiWeBuildIsAWormyBoi prefix가 붙은 커밋 메시지
  • A Mini Shai-Hulud has Appeared 설명을 가진 공개 저장소
  • chore: update dependencies로 위장한 의심스러운 credential commit

• 대응은 토큰 폐기와 재발급까지 가야 함

  • GitHub 토큰, npm publish 토큰, 클라우드 credential, API 키를 회전해야 함
  • 감염된 CI 러너나 개발 머신은 단순 파일 삭제보다 재프로비저닝 관점으로 보는 게 맞음
  • npm publish 권한이 있었던 계정은 자신이 배포 가능한 패키지 전체가 오염됐는지 확인해야 함

기술 맥락

• 이번 공격의 핵심은 파이썬 패키지 하나가 아니라, ML 개발 환경이 가진 권한 묶음이에요. 모델 학습 코드는 보통 데이터, 클라우드, 실험 추적, 배포 파이프라인까지 연결돼 있어서 패키지 import 한 번이 단순 로컬 실행으로 끝나지 않거든요.

• PyPI에서 시작해 npm으로 번진 것도 중요해요. 공격자는 lightning을 쓰는 파이썬 개발자를 먼저 잡고, 그 환경에 npm publish 토큰이 있으면 JavaScript 생태계 패키지까지 오염시켰어요. 언어별 패키지 매니저를 따로 보는 보안 모델이 현실에서는 잘 안 맞는다는 얘기예요.

• GitHub Actions를 노린 부분은 CI가 사실상 비밀 저장소 역할을 하기 때문이에요. 배포 토큰, 클라우드 권한, 패키지 publish 권한이 CI에 몰려 있으니, 러너에서 프로세스 메모리와 secrets 컨텍스트를 뽑아내면 이후 공격자가 할 수 있는 일이 확 늘어나요.

• Claude Code와 VS Code 훅 악용은 개발 도구 설정 파일도 실행 경로라는 점을 보여줘요. 저장소를 열거나 AI 코딩 세션을 시작하는 행동만으로 코드가 돌 수 있다면, .vscode/나 .claude/ 같은 폴더도 리뷰와 보안 스캔 대상에 들어가야 해요.

• 그래서 대응도 패키지 버전만 내리는 걸로는 부족해요. 어떤 환경에서 import됐는지, 그 환경이 어떤 토큰을 갖고 있었는지, 그 토큰으로 어떤 저장소와 패키지를 쓸 수 있었는지까지 따라가야 실제 피해 범위가 보여요.