▲

Shai-Hulud 테마 악성코드가 PyTorch Lightning AI 학습 라이브러리에서 발견됨 | Semgrep

 (semgrep.dev)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • PyPI lightning 2.6.2와 2.6.3 버전이 2026년 4월 30일 게시된 뒤 공급망 공격에 악용됐고, pip install lightning만으로 숨겨진 _runtime 디렉터리와 난독화된 JavaScript 페이로드가 실행될 수 있음
  • 악성 페이로드는 모듈 임포트 시 자동 실행돼 자격 증명, 인증 토큰, 환경 변수, 클라우드 비밀값을 탈취하며 GitHub 저장소 오염도 시도함
  • 이번 공격은 진입점이 PyPI이지만 웜 전파는 npm을 통해 이뤄지며, npm 게시 자격 증명을 찾으면 게시 가능한 패키지에 setup.mjs 드로퍼와 router_runtime.js를 주입하고 패치 버전을 다시 게시함
  • 데이터 유출은 HTTPS POST, GitHub 커밋 검색 데드드롭, 공격자 제어 공개 GitHub 저장소, 피해자 저장소 직접 푸시 등 4개 병렬 채널을 사용하며 EveryBoiWeBuildIsAWormyBoi 커밋 접두사와 "A Mini Shai-Hulud has Appeared" 저장소 설명이 지표로 남음
  • 악성코드는 Claude Code의 .claude/settings.json SessionStart 훅과 VS Code의 .vscode/tasks.json runOn: folderOpen 작업을 심어 저장소를 열 때마다 드로퍼를 실행하며, 영향 기간에 악성 패키지를 임포트한 머신은 완전 침해된 것으로 취급해야 함

영향받는 패키지와 확인 절차

  • lightning은 이미지 분류기 구축, LLM 파인튜닝, 확산 모델 실행, 시계열 예측기 개발 팀의 의존성 트리에 자주 포함되는 딥러닝 프레임워크임

  • 영향받는 패키지

    • lightning 버전 2.6.2
    • lightning 버전 2.6.3

  • Semgrep 고객 확인 절차

    • 최근 프로젝트 스캔을 수행하지 않았다면 새 스캔을 실행해야 함
    • advisories 페이지에서 프로젝트가 해당 패키지 버전을 최근 설치했는지 확인 가능함
    • dependency filter에서 일치 항목을 확인할 수 있으며, “No matching dependencies”가 표시되면 프로젝트에서 악성 의존성을 활발히 사용 중이지 않다는 뜻임
    • 일치 항목이 있으면 아래 침해 지표에 있는 .claude/와 .vscode/ 디렉터리의 예상치 못한 파일을 저장소에서 감사해야 함
    • 영향을 받은 환경에 있었을 수 있는 GitHub 토큰, 클라우드 자격 증명, API 키를 교체해야 함
    • 공급망 공격 대응과 대기 기간 관련 일반 조언은 $foo compromised in $packagemanager와 Attackers are Still Coming for Security Companies에서 다룸

PyPI에서 npm으로 확산되는 구조

  • mini Shai-Hulud가 npm을 직접 겨냥한 것과 달리 이번 공격의 진입점은 PyPI임
  • 악성 페이로드는 여전히 JavaScript이며, 웜 전파는 npm을 통해 발생함
  • 실행된 악성코드가 npm 게시 자격 증명을 찾으면 해당 토큰으로 게시 가능한 모든 패키지에 setup.mjs 드로퍼와 router_runtime.js를 주입함
  • 이후 scripts.preinstall을 드로퍼 실행으로 설정하고, 패치 버전을 올린 뒤 다시 게시함
  • 해당 패키지를 설치한 하위 개발자는 전체 악성코드를 자신의 머신에서 실행하게 되며, 토큰 탈취와 패키지 웜 감염이 이어짐

데이터 유출 방식

  • 탈취 기능은 이전 캠페인의 Mini Shai-Hulud 메커니즘과 설계를 공유하며, 개별 경로가 차단돼도 데이터가 빠져나가도록 4개의 병렬 채널을 사용함
  • 공격에는 EveryBoiWeBuildIsaWormBoi라는 공개 저장소 생성 등 Shai-Hulud 테마가 포함됨
  • 공격 지표 구조는 이전 mini Shai-Hulud 캠페인과 일치하며, 악성 커밋 메시지는 EveryBoiWeBuildIsAWormyBoi 접두사를 사용해 원래 Mini Shai-Hulud 공격과 구분됨

  • HTTPS POST를 통한 C2 전송

    • 탈취 데이터는 포트 443을 통해 공격자 제어 서버로 즉시 POST됨
    • 도메인과 경로는 페이로드 안에 암호화된 문자열로 저장돼 정적 분석을 어렵게 만듦

  • GitHub 커밋 검색 데드드롭

    • 악성코드는 GitHub 커밋 검색 API를 폴링해 EveryBoiWeBuildIsAWormyBoi 접두사가 붙은 커밋 메시지를 찾음
    • 커밋 메시지는 EveryBoiWeBuildIsAWormyBoi:<base64(base64(token))> 형식의 이중 Base64 인코딩 토큰을 운반함
    • 디코딩된 토큰은 이후 작업을 위한 Octokit 클라이언트 인증에 사용됨

  • 공격자 제어 공개 GitHub 저장소

    • 무작위로 선택된 Dune 단어 이름과 "A Mini Shai-Hulud has Appeared" 설명을 가진 새 공개 저장소가 생성됨
    • 이 설명은 GitHub에서 직접 검색 가능함
    • 탈취 자격 증명은 results/results-<timestamp>-<n>.json으로 커밋되며, API를 통해 Base64 인코딩되지만 내부는 일반 JSON임
    • 30MB를 넘는 파일은 번호가 붙은 청크로 나뉨
    • 커밋 메시지는 위장용으로 chore: update dependencies를 사용함

  • 피해자 저장소로 직접 푸시

    • 악성코드가 ghs_ GitHub 서버 토큰을 얻으면 피해자의 GITHUB_REPOSITORY 모든 브랜치에 탈취 데이터를 직접 푸시함

탈취 대상

  • 악성코드는 로컬 파일, 환경, CI/CD 파이프라인, 클라우드 제공자 전반의 자격 증명을 겨냥함

  • 파일 시스템

    • 80개 이상의 자격 증명 파일 경로를 스캔해 ghp_, gho_, npm_ 토큰을 찾음
    • 파일당 최대 5MB까지 처리함

  • 셸과 환경 변수

    • gh auth token을 실행함
    • process.env의 모든 환경 변수를 덤프함

  • GitHub Actions

    • Linux 러너에서 내장 Python으로 Runner.Worker 프로세스 메모리를 덤프함
    • "isSecret":true로 표시된 모든 비밀값과 GITHUB_REPOSITORY, GITHUB_WORKFLOW를 추출함

  • GitHub 조직

    • 토큰 범위인 repo, workflow를 확인함
    • GitHub Actions 조직 비밀값을 순회함

  • AWS

    • 환경 변수, ~/.aws/credentials 프로필, IMDSv2 169.254.169.254, ECS 169.254.170.2를 시도해 sts:GetCallerIdentity를 호출함
    • Secrets Manager의 모든 값과 SSM 파라미터를 열거하고 가져옴

  • Azure

    • DefaultAzureCredential을 사용해 구독을 열거하고 Key Vault 비밀값에 접근함

  • GCP

    • GoogleAuth로 인증함
    • Secret Manager의 모든 비밀값을 열거하고 가져옴
    • 대상 범위는 로컬 개발 환경, CI 러너, 3대 주요 클라우드 제공자를 모두 포함함
    • 영향을 받은 기간에 악성 패키지를 임포트한 모든 머신은 완전 침해된 것으로 취급해야 함

개발 도구를 통한 지속성 확보

  • 저장소 내부에 들어온 뒤 악성코드는 흔히 사용되는 개발 도구인 Claude Code와 VS Code를 겨냥해 지속성 훅을 심음

  • Claude Code

    • 악성코드는 저장소의 Claude Code 설정 파일인 .claude/settings.json에 matcher: "*"인 SessionStart 훅을 작성함
    • 훅은 node .vscode/setup.mjs를 가리킴
    • 개발자가 감염된 저장소에서 Claude Code를 열 때마다 실행되며, 세션 시작 외의 도구 사용이나 사용자 동작은 필요하지 않음

  • VS Code

    • VS Code 사용자를 겨냥해 .vscode/tasks.json에 runOn: folderOpen 작업을 심음
    • 프로젝트 폴더가 열릴 때마다 node .claude/setup.mjs가 실행됨

  • 드로퍼 setup.mjs

    • 두 훅은 모두 자체 포함형 Bun 런타임 부트스트래퍼인 setup.mjs를 호출함
    • Bun이 설치돼 있지 않으면 GitHub releases에서 bun-v1.3.13을 조용히 다운로드함
    • Linux x64, Linux arm64, Linux musl, macOS x64, macOS arm64, Windows x64, Windows arm64를 처리함
    • 이후 전체 14.8MB 페이로드인 .claude/router_runtime.js를 실행하고 /tmp에서 정리함

  • 악성 GitHub Actions 워크플로

    • 악성코드가 쓰기 권한이 있는 GitHub 토큰을 보유하면 피해자 저장소에 Formatter라는 워크플로를 푸시함
    • 모든 push에서 ${{ toJSON(secrets) }}를 통해 모든 저장소 비밀값을 덤프함
    • 결과를 format-results라는 다운로드 가능한 Actions 아티팩트로 업로드함
    • Actions는 정상처럼 보이도록 특정 커밋 SHA에 고정됨
    • CI에서 감염된 lightning 패키지를 받았고 쓰기 권한 토큰을 가진 저장소는 해당 파일들을 감사해야 함

침해 지표

  • 검색 가능한 지표

    • EveryBoiWeBuildIsAWormyBoi 접두사가 붙은 커밋 메시지는 데드드롭 토큰 운반자로 사용되며 GitHub 커밋 검색으로 찾을 수 있음
    • "A Mini Shai-Hulud has Appeared" 설명을 가진 GitHub 저장소는 공격자 유출 저장소이며 직접 검색 가능함

  • 패키지

    • lightning@2.6.2
    • lightning@2.6.3

  • 파일과 시스템 아티팩트

    • _runtime/start.py: 임포트 시 페이로드를 초기화하는 Python 로더
    • _runtime/router_runtime.js: 난독화된 JavaScript 페이로드이며 14.8MB Bun 런타임임
    • _runtime/: 악성 패키지 버전에 추가된 디렉터리
    • .claude/router_runtime.js: 피해자 저장소에 주입된 악성코드 복사본
    • .claude/settings.json: 피해자 저장소에 주입된 Claude Code 훅 설정
    • .claude/setup.mjs: 피해자 저장소에 주입된 드로퍼
    • .vscode/tasks.json: 피해자 저장소에 주입된 VS Code 자동 실행 작업
    • .vscode/setup.mjs: 피해자 저장소에 주입된 드로퍼

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 단순히 빈도 착각일 수도 있지만, 최근 주요 패키지에서 유명한 공급망 공격이 꽤 많이 보임
    지금 HN 첫 몇 페이지에도 서로 다른 사례를 다룬 글이 여러 개 있음
    10년 전 left-pad를 돌아보면, 지금 성공한 공격이 예전보다 더 많은가 싶고 아마 그럴 것 같음
    성공한 공격의 가치도 확실히 커졌을 텐데, 패키지 릴리스 전에 탐지하는 능력은 커뮤니티 전체로서 실제로 나아지고 있는지 궁금함
    상용 소프트웨어 회사는 더 잘해야 하지만, 취미/아마추어 코드로 시작했다가 많은 프로젝트의 의존성이 되는 경우를 위한 보편적이고 쉬운 도구는 아직 부족해 보임
    현재 SAP 공급망 공격 스레드에도 같은 댓글을 올렸음: https://news.ycombinator.com/item?id=47964003

    • 실제 현상임. 4월 초 기준으로 최근 12개월에 7건이 있었고, 그 전 20년 동안은 9건이었음: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
    • 사람들이 코드를 제대로 보지도 않고 여기저기 대량으로 밀어 넣고 있으니, 그에 따라 공급망 공격이 늘어나는 건 자연스러움
    • 이유는 자동 업데이트와 CI 도구가 임계 보급률에 도달해 모두가 쓰기 때문임
      예전에는 npm install을 수동으로 실행하는 경우가 더 많았고, 빌드가 깨졌을 때나 아주 가끔 실행했을 가능성이 큼
      공급망 공격은 사람들이, 더 정확히는 파이프라인이 새 릴리스가 나오자마자 아무 생각 없이 패키지를 자동 업데이트하는 데 의존함
    • 역사적으로 추가 보안 검사를 거친 산출물 처리는 유료 엔터프라이즈 옵션이었고, 덜 안전한 쪽이 훨씬 번거롭지 않은 기본값이었음
      이게 좋은 비즈니스 모델인지는 모르겠고, 아마 별로 아닐 것 같음
    • left-pad는 공격이 아니라 NPM의 버그였음
      이미 공개된 다른 패키지가 의존하는 패키지 버전을 삭제할 수 있어서는 안 됐고, 반대로 새 버전이면서 아무도 의존하지 않는 특정 패키지 버전은 삭제할 수 있어야 했음
      left-pad 작성자가 서비스를 떠나려는 의도로 모든 데이터를 지우려 했을 때 NPM은 오류 코드를 반환했어야 함
      Wikipedia에 따르면 Koçulu가 npm, Inc.의 결정에 실망해 플랫폼 일부로 남고 싶지 않다고 하자, NPM 작성자인 Schlueter가 그가 등록한 273개 모듈을 삭제하는 명령을 제공했음

  • 이상한 점은 보안 이슈 4개가 올라왔는데 모두 pl-ghost라는 봇이 자동 댓글을 달고 닫았다는 것임 [1][2][3][4]
    결국 이 중 [4]만 제대로 처리됐고 봇 댓글은 모두 삭제됨
    다른 보고서 [5]에서 봇 댓글을 볼 수 있는데, 원문보다 더 많은 정보를 줌
    [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [5] https://socket.dev/blog/lightning-pypi-package-compromised

    • Lightning의 Andy임. 맞음, PyPI 자격 증명은 침해된 pl-ghost 봇 계정을 통해 도난당했음
      공격자는 이 계정으로 새 Actions 워크플로를 만들었고, 실행된 워크플로에서 PyPI 비밀값을 파싱해 빼냈음
      패키지를 릴리스한 뒤에는 그 계정으로 댓글을 달며 우리를 약간 조롱했음

  • 의존성이 아예 없는 날이 빨리 왔으면 좋겠음
    극단적인 예로, 요즘 딸을 위한 인터랙티브 교육 앱을 만들 때는 Opus에게 순수 JavaScript와 HTML만 쓰게 함
    이중 진자부터 유체 시뮬레이션까지 한 번에 잘 동작하고, 예전에는 의존성이 수백 개였음
    MIT 라이선스 코드라면 Opus에게 필요한 부분만 정확히 추출해서 내 용도에 맞게 수정해 포함시키라고 할 수 있음
    취미 프로젝트에서는 지금까지 잘 됐고, 앞으로는 프로덕션 소프트웨어도 의존성이 없어지면 좋겠음

    • 그렇게 하면 모든 변화와 수많은 예외를 전부 직접 관리해야 함
      Chrome이 어떤 API 형태를 바꾸면 직접 찾아서 고쳐야 하고, 모로코가 일광절약시간 시작 시점을 바꾸면 날짜/시간 처리 코드도 직접 업데이트해야 함
      이런 것들은 라이브러리가 대신 처리해주기 때문에 당연하게 여겨왔던 부분임
      딸이 다음 주면 관심을 잃을 이중 진자 시뮬레이터에는 큰일이 아니지만, 앞으로 무기한 동작해야 하는 걸 만드는 회사라면 문제가 됨
    • 이제 진짜 의존성인 브라우저에 노출된 셈임
    • 물론 Opus가 만들어낸 코드의 모든 줄을 오픈소스 유지보수자에게 기대하는 수준으로 꼼꼼히 검토할 거지? 그렇지?
      MIT 라이선스 원격 접근 코드를 하나 공개해서 Opus 학습 데이터에 들어가게 해봐야겠음
    • Rust를 Go보다 좋아해서 고민됨. LLM 관점에서도 Rust가 더 낫지만, Rust의 의존성 철학은 사실상 보안 블랙홀이고 Go가 훨씬 나음
    • 공유 가능한 저장소나 포지에 올려둔 게 있나? 농장 동물 철자 맞히기 게임이 있어서 내 라이브러리를 확장하고 아이디어를 더 만들고 싶음

  • Fast.AI 딥러닝 과정을 들을 때, 머신러닝 프로젝트가 끌고 오는 Python 의존성 수에 놀랐음
    웹 프런트엔드 프로젝트는 항상 서드파티 의존성이 많다고 여겨졌지만, 내게는 머신러닝 생태계가 훨씬 더 얽혀 보임
    게다가 웹 개발은 보안에 민감하다고 여겨져 오랫동안 보안 관련 지혜와 관행이 쌓였지만, 머신러닝 개발은 훨씬 임시방편적이고 일반적인 소프트웨어 공학 관행도 많이 적용되지 않는 듯함
    예를 들어 당시 머신러닝 모델 배포 방식 중 하나가 Python pickle이었는데, 이는 기본 제한이 없는 실행 가능한 객체임
    이 형식의 모델은 가져오는 컴퓨터에서 무엇이든 할 수 있었고, 이런 초기 무법지대 생태계는 보안 침해와 공급망 공격을 더 쉽게 만들 수 있음

    • 그 생태계에는 원래 소프트웨어 엔지니어가 아닌 사람이 많음
      일부는 하다가 코딩을 조금 배웠고, 일부는 수학자이며, 일부는 AI에 취한 개발자 같은 경우도 있음
      “코드는 이제 중요하지 않고, 돌아가면 된다”는 사고방식도 있음
      많은 사람에게 제대로 된 의존성 관리는 신경 쓰고 싶지 않은 잡일일 뿐임
      여러 머신러닝 프로젝트에서 이런 요소들이 합쳐지는데, 사실 머신러닝 프로젝트야말로 재현성에 가장 집중해야 하는 분야 중 하나임

  • 저장소 검색을 해보니 지난 하루 동안 생성된 저장소 중 "A Mini Shai-Hulud has Appeared" 텍스트가 들어간 저장소가 2.2천 개 나옴: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

    • 저장소 이름이 모두 dune의 두 용어/단어, 예를 들면 harkonen, mentat, ornithoptor 같은 것에 숫자가 붙은 형태로 보임
      이는 계정, 아마도 GitHub 인증/Actions 토큰이 침해된 뒤 저장소 생성에 사용됐다는 신호로 보임
    • https://github.com/tinin46 이 계정은 키를 많이 저장해둔 것처럼 보이는데, 용도는 잘 모르겠음
    • GitHub가 왜 바로 대응해서 README가 정규식에 맞는 저장소를 차단하지 못하는지 모르겠음
      지난번에도 이런 일이 있었으니 교훈을 얻었을 줄 알았음
      이 악성코드는 별로 노력도 하지 않았고, Microsoft도 별로 노력하지 않는 듯함
    • 이게 대체 무슨 일임?

  • 면책하자면 pytorch를 써본 적도 없고 소프트웨어 보안 관행도 잘 모름
    하지만 pytorch에 네트워크 접근이 필요한 시나리오가 잘 떠오르지 않음
    코드베이스 어디서든 아무 모듈이나 가져와 그 API를 쓸 수 있는 건 잘못된 것 같음
    추가적인 import 제한이나 정적 분석이 필요해 보임
    언어가 이런 문제를 다룰 올바른 추상화를 갖고 있지 않은 듯함
    비교하자면 Rust에서는 함수 시그니처만 보고도 내부 코드를 이해하지 않고 가변성과 수명을 볼 수 있는 점이 좋음
    의존성에도 비슷한 게 필요하다고 느낌
    개발자가 하위 코드를 들여다보지 않고도 모든 의존성을 쉽게 감사해서 “아, 이 의존성은 eval()을 쓰네” 또는 “네트워크 접근을 하네”라고 볼 수 있어야 함
    모바일 앱은 권한을 강제하는데, 개발자도 특정 기능만 허용 목록에 넣고 온갖 기능을 통째로 받아들이지 않을 수 있어야 하지 않나 싶음

    • Python 생태계는 이런 걸 절대 허용하지 않겠지만, 이 주제가 그 안에서 더 잘 이해되고 인정받았으면 좋겠음
      일반화하기는 싫지만, 특히 AI 개발 커뮤니티는 다른 모든 고려보다 편의성을 선호하는 듯함
      예를 들어 프로젝트가 첫 실행 시 큰 모델을 자동 다운로드하는 게 표준처럼 되어 있음
      대개 비활성화할 수는 있지만, 여러 라이브러리에 걸친 코드 클래스의 깊은 계층 때문에 올바른 매개변수를 찾기가 정말 고통스러움
      복잡한 것들, 대개는 장난감에 가까운 것들을 너무 쉽게 시작할 수 있는 건 좋지만, 이 허용적인 분위기는 꽤 불편함
      첫 문제 해결 단계가 항상 “pip install …”인 것 같고, 일부 환경, 예를 들어 MacOS는 GPU 접근 가상화도 잘 되지 않음
    • 여러 컴퓨트 노드에 걸쳐 모델을 학습하는 경우가 있음. 그건 네트워크 접근이 필요한 큰 사례임

  • 이번 주에 Python 버전 관리를 위해 uv를 쓰는 게 좋은 생각인지 궁금했음
    웹사이트 [1]에는 “Python은 공식 배포용 바이너리를 제공하지 않으므로 uv는 Astral python-build-standalone 프로젝트의 배포판을 사용한다”고 되어 있음
    이 GitHub 저장소 https://github.com/astral-sh/python-build-standalone를 가리키고, 거기서는 또 https://gregoryszorc.com/docs/python-build-standalone/main/r...를 언급함
    내가 제대로 이해했다면 Python 빌드용 소스 코드를 python.org에서 직접 가져오지 않는 것 같은데, 이게 얼마나 안전한지 확신이 안 듦
    asdf [2]에도 같은 우려가 있지만, asdf는 pyenv [3]를 쓰고 그쪽이 더 공식에 가까운 느낌임
    Python 설치에는 uv와 asdf 중 어느 도구가 더 낫고 더 안전한지 누가 설명해줄 수 있나?
    [1] https://docs.astral.sh/uv/guides/install-python/
    [2] https://github.com/asdf-community/asdf-python
    [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

    • python-build-standalone은 CPython 소스를 python.org에서 직접 가져옴[1]
      애초에 다른 어디서 가져오겠나 싶음
      [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
    • uv와 cpython은 별로 걱정하지 않음. 프로세스가 견고하고, 대응도 빠르며, 이제 자금도 상당함
      걱정되는 건 예를 들어 mdformat처럼 널리 쓰이지만 주로 한 사람이 여가 시간에 관리하는 포매터나, 몇 년째 업데이트되지 않았고 의존성 트리 3단계 아래에 있는 아주 특정한 의존성임
      활발히 개발 중인 앱에서 모든 업데이트를 고정하고 수동 승인하고 싶지는 않지만, 진지한 앱이라면 이제 그게 필수처럼 보이기 시작함
      그동안 암호화되지 않은 .env 파일에서 API 키를 꺼내야겠음
      대규모 소비자용 웹앱에서 당하면 창피하지만 이해는 되는데, 같은 호스트와 시스템에 우연히 있는 장난감 데모 저장소의 간접 의존성 때문에 수백~수천 달러를 잃는 건 너무 아픔
      이런 식으로 키를 도난당하면 OAI나 Anthropic이 환불해 주는지 아는 사람 있나? 아니면 사용자 실수인가?
    • 애초에 uv는 컴퓨터에서 실행해서 Python 바이너리, 패키지, 그 안의 바이너리, 시스템 전역 도구 등을 관리하는 바이너리임
      Python 바이너리를 그들이 빌드하든 다른 누군가가 빌드하든 위험이 얼마나 달라지는지 모르겠음

  • 요즘 내 pip install의 대부분은 Claude Code가 제안하고 내가 그냥 Enter를 누르면서 생김
    모델은 몇 달 전 데이터로 학습됐으니 이번 주에 뭐가 침해됐는지 알 리가 없음
    “이 패키지가 지금 안전한가”를 판단하는 데 최악의 필터를 만든 셈임

    • 게으름과 실사 부족을 LLM 탓으로 돌리지 말아야 함
    • 무슨 필터를 말하는 건가?
      Claude Code가 인터넷에서 설치할 소프트웨어를 추천하게 하고, 그걸 그대로 설치한다고 한 것임
      Claude Code나 어떤 LLM도 “이 패키지가 지금 안전한가”를 판단하는 필터라고 제안하는 건 들어본 적이 없고, 말한 이유를 포함해 매우 나쁜 휴리스틱으로 보임
    • 오래된 학습 데이터도 일부 원인이지만, 최신 모델이라도 setup.py가 내 머신에서 무엇을 실행할지 알 수는 없음
      실행 전에 패키지를 실제로 검사하는 게 없기 때문임
      필요한 건 실행 전에 메타데이터를 가져와 어떤 훅이 있는지 확인하는 도구임
    • Enter를 누르지 않으면 쉽게 우회할 수 있음
    • “최악의 필터”라는 게 Claude가 시키는 대로 Enter를 누르는 걸 말하는 건가?

  • Claude Code는 거의 매일, 때로는 하루에 여러 번 업데이트됨
    언젠가 Anthropic이 침해되면 우리 모두 크게 당할 것임

    • “우리”가 누구를 말하는 건가?
    • 권한 없는 VM/컨테이너에서 제한된 네트워크 접근으로 실행한다면 그렇지 않음
      하지만 요즘은 모든 게 YOLO임
    • 이미 Polymarket 가격에 반영돼 있을 것 같음

  • GitHub에서 4월 20일에 올라온 이 메시지를 봤는데 좀 혼란스러움
    "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
    그때부터 문제를 알고도 지금까지 경고하지 않은 거라면 정말 싫을 것 같음
    더 아는 사람이 명확히 설명해주면 좋겠음
    https://github.com/Lightning-AI/pytorch-lightning/issues/216...

    • Lightning의 Andy임. 악성 패키지는 오늘 UTC 12:45 PM에 PyPI에 게시됐음
      그 전에는 영향받은 배포물이 없었고, 유출도 알지 못했음
      GitHub의 원래 릴리스에는 문제가 없었지만 혼란을 막기 위해 내려둔 상태임
    • uv를 쓰는 사람들을 위해: https://docs.astral.sh/uv/reference/settings/#exclude-newer
답변달기