Rust 크레이트 arrayref, 빌드 시점에 악성 페이로드 실행
Malicious Rust Crate Arrayref Runs a Build-Time Payload
2026년 8월 20일, 인기 Rust 크레이트 arrayref의 손상된 릴리스 0.3.10이 crates.io에 등장했다. 이 버전은 typosquatting된 proc-macro1 크레이트에 의존성을 추가했고, 해당 크레이트의 빌드 스크립트가 프로젝트 컴파일 중 원격 바이너리를 다운로드해 실행한다. 단순히 컴파일만 해도 트리거되며, crates.io 팀은 악성 버전을 제거했다. arrayref는 tiny-skia, winit 등을 통해 많은 GUI 프로젝트에 전이적으로 포함되며, 총 다운로드 수는 약 2억 4500만 회에 달한다.
빌드 스크립트는 소스에 원시 문자열을 남기지 않기 위해 서버 주소를 base64 조각으로 나눠 빌드 시점에 재조립한다.
HN 토론
510- cube00
GitHub는 이런 사고가 발생했을 때 저장소가 아예 없었던 것처럼 처리하는 것보다 더 세밀한 조치가 정말 필요합니다. [1]
문제의 패키지 버전도 crates.io에서 그냥 사라져 버렸고 [2], yank되었다는 표시도 없습니다. 보안 권고도 없습니다 [3] "이 크레이트에 대한 권고를 찾을 수 없습니다."
crates.io는 이런 보안 사고에 대비가 되어 있지 않았던 것 같습니다. 그들이 대응을 관리하고 있기 때문입니다 [4]
[1]: https://web.archive.org/web/20260820145918/https://github.co...
[2]: https://crates.io/crates/arrayref/versions
[3]: https://crates.io/crates/arrayref/security (Wayback 링크를 걸고 싶지만 그것도 깨져 있습니다 https://web.archive.org/web/20260820150747/https://crates.io...)
[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...
- cosmic_cheese
저는 언어와 라이브러리 설계에 있어 더 "배터리 포함" 방식으로 접근해야 한다고 생각합니다. 우리가 이 난장판에 빠진 이유는 표준 라이브러리가 지나치게 얇아서 기본 언어가 거의 사용 불가능에 가깝다는 것을 괜찮거나 오히려 선호한다고 결정했기 때문입니다.
저는 5개 이하의 최상위 의존성만으로도 매우 기능적이고 사용하기 pleasant한 Apple 플랫폼 앱을 쉽게 만들 수 있습니다. 많은 경우, 저는 총 0~2개만 사용합니다.
이것이 다른 곳에서도 재현되지 못할 이유가 없습니다. 핵심은 프로그래밍 언어를 일반적인 비UI 개발 요구의 최소 80%를 내장하여 합리적으로 견고하게 만들고, 나머지 20%와 UI 부분은 소규모의 잘 지원되고 커뮤니티에서 수용되며 가능하면 퍼스트파티 라이브러리 계열에 넣는 것입니다.
그렇게 하면 대부분의 프로젝트에서 외부 의존성을 가져올 필요가 없어집니다. 가져오게 되는 소수의 것들은 가볍고 쉽게 검증할 수 있는 syntactic sugar 또는 목적이 너무 niche하여 표적이 될 가치가 없는 라이브러리가 될 것입니다.
물론 이 접근 방식도 잘못될 수 있습니다. Boost와 같은 괴물을 쉽게 만들 수 있지만, 이는 프로젝트 관리가 크리프를 통제하고 적절한 모듈식 설계를 유지하는 데 달려 있습니다.
- ramimac
메인 러스트 블로그의 게시물에 대한 스레드: https://news.ycombinator.com/item?id=49372853
직접 게시물 링크: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
최초 보고: https://github.com/rustsec/advisory-db/issues/3161
다른 공급업체 게시물:
* https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-...
* https://research.jfrog.com/post/arrayref-proc-macro1-crates-...
* https://www.aikido.dev/blog/two-popular-rust-crates-arrayref...
- jakubadamw
Cargo에는 build.rs 스크립트를 위한 샌드박싱이 절실히 필요합니다. 이전에 시도된 적이 있지만 별로 진전이 없었습니다¹.
¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
- hbbio
Rust는 JS 생태계와 같은 결함을 가지고 있습니다. 중요한 크레이트는 수백, 수천 개의 의존성을 가져옵니다. 작성자 중 한 명이 AI 지원 공격의 표적이 될 확률이 너무 높습니다.
또한 이러한 의존성의 대부분은 최종 패키지가 필요로 하지 않을 기능의 폭을 제공합니다.
- fidotron
엄격한 컨테이너화 밖에서 소프트웨어 개발을 하는 것은 점점 재앙에 가까워 보입니다.
네, 패키지 관리 문화에 대해 논쟁할 수 있습니다(특히 npm에 대해 처음부터 논쟁해 온 일부 사람들처럼), 하지만 이미 끝난 일이고, 동료나 AI 사이드킥이 무엇이든 다운로드해서 빌드하고 실행하려고 시도하지 않을 것이라고 믿을 수 없습니다. 할 수 있는 일은 효과적인 폭발 반경을 제한하는 것뿐입니다.
- tancop
우리는 지금 효과 기반 언어가 필요합니다. 라이브러리가 컴파일되기 전에 네트워크 없음, 파일 접근 없음, 안전하지 않은 코드나 FFI 없음과 같은 정책을 보장할 수 있는 유일한 방법입니다. Epic의 누군가가 이 글을 읽고 있다면 Verse 컴파일러를 오픈소스화하는 일정을 알려주세요.
그동안 Cargo를 해킹하고 모든 빌드 스크립트를 microVM에서 실행하는 것이 가능하다고 생각합니다. 폭발 반경은 CI 비밀을 모두 업로드하고 하드 드라이브를 삭제하는 대신 바이너리의 악성 코드로 제한될 것입니다.
- vatsachak
의존성을 업데이트하라고 말하는 모든 사람들, 이것이 제가 업데이트하지 않는 이유입니다. 게으름이 아니라 부인할 수 없는 선견지명입니다.
- tsimionescu
> arrayref는 네 개의 매크로로 구성된 작은 크레이트입니다.
왜 많은 언어들이 이 끔찍한 관행에 빠지는 걸까요?
- hoppp
Rust 생태계는 NPM 생태계처럼 악성 코드에 타격을 입을 것입니다. 저는 몇 년 동안 말해 왔습니다. 그들은 같은 실수를 저질렀거나 더 심한 실수를 저질렀습니다. 왜냐하면 손상된 serde 하나가 전체 생태계를 무너뜨릴 수 있기 때문입니다.