# Arch Linux, 이제 악성코드 사고가 통제됐다고 판단: 1,500개 이상 패키지 영향 > Clean Markdown view of GeekNews topic #30485. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30485](https://news.hada.io/topic?id=30485) - GeekNews Markdown: [https://news.hada.io/topic/30485.md](https://news.hada.io/topic/30485.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-15T08:36:04+09:00 - Updated: 2026-06-15T08:36:04+09:00 - Original source: [phoronix.com/news](https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500) - Points: 1 - Comments: 1 ## Topic Body - Arch Linux의 **AUR 사용자 기여 저장소**에서 악성코드 감염 패키지가 처음 400개 이상으로 확인된 뒤 최종적으로 1,500개 이상으로 늘어남 - 몇 시간 전 업데이트에서는 이번 주 사고로 감염된 패키지가 약 **900개**로 파악됐음 - 이후 Arch Linux 개발자들은 인지한 **악성 커밋**을 모두 삭제했으며, 영향받은 패키지 수는 1,579개로 집계됨 - 1,579개 목록도 영향받은 패키지의 **많지만 전체는 아닌 목록**으로 표시돼 전체 범위가 더 클 수 있음 - 사용자 유지 관리 저장소의 많은 소프트웨어가 이번 **보안 사고**의 영향을 받았으며, 별도 업데이트에서는 더 정교한 악성코드 공격이 다시 발생함 --- ### 사고 개요 - Arch Linux 사용자를 위한 **AUR 사용자 기여 저장소**에서 악성코드에 감염된 패키지가 400개 이상 발견되며 사고가 시작됨 - 하루가 끝날 무렵 Arch Linux 측은 영향받은 커밋이 모두 처리됐다고 판단했지만, 영향받은 패키지 수는 1,500개 이상으로 늘어남 - 이번 사고는 사용자 유지 관리 Arch Linux 저장소의 많은 소프트웨어에 영향을 준 **보안 사고**였음 ### 영향 범위 변화 - 몇 시간 전 업데이트에서는 이번 주 사고로 약 **900개 패키지**가 악성코드에 감염된 것으로 파악됐음 - 이후 보안 사고 스레드의 마지막 메시지 기준으로 Arch Linux 개발자들은 인지한 악성 커밋을 모두 삭제함 - 인용된 목록은 악성코드 영향을 받은 패키지 수를 **1,579개**로 표시함 ### 남은 불확실성 - 1,579개 패키지가 표시된 목록도 “영향받은 패키지의 많지만 전체는 아닌 목록”으로 표시됨 - 따라서 공개된 숫자는 확인된 대규모 영향 범위를 보여주지만, 목록 자체가 전체 패키지를 포괄하지는 못함 ### 후속 업데이트 - 별도 업데이트로 Arch Linux AUR이 더 정교해진 악성코드 공격의 또 다른 물결을 맞았다는 내용이 이어짐 ## Comments ### Comment 59639 - Author: neo - Created: 2026-06-15T08:36:05+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48516379) - AUR 팀에서 **사후 분석**을 낸 적이 있는지 궁금함 이번 대응은 인상적으로 빨랐지만, 솔직히 AUR 정책이든 래퍼든 변화가 필요해 보임 pnpm처럼 최소 패키지 나이를 설정할 수 있어야 하고, 고아 패키지를 아무나 입양할 수 있으면 안 됨 입양에는 전역 속도 제한을 둬서 공격 신호로 삼을 수도 있고, NPM에서 여러 회사가 하듯 게시 시점에 취약점 스캔도 필요함 다만 이런 변화의 대부분은 AUR 유지보수자보다 패키징 도우미와 제3자가 해야 할 일에 가까움 - AUR 패키지를 **이름공간**으로 나누는 편이 더 나음 그러면 소유권이 사라지지 않아서 고아 처리 자체가 필요 없어짐 - AUR 저장소를 내려받는 공식 도구는 없으니, 그 부분은 각자 쓰는 방식에 달려 있음 - pnpm에서 영감을 받아 pakku에 **최소 AUR 나이**를 두는 패치 [1]를 최근 만들어 봤음 [1] [https://github.com/gavinhungry/patches/blob/main/pakku/pakku...]() [2] [https://github.com/zqqw/pakku]() - 고아 패키지 입양을 너무 막으면 제대로 유지보수될 수 있는 것들도 방치될 수 있음 제한은 필요하지만, 예를 들어 일정 기간 이전에 가입한 사용자에게 **월 1개 입양** 정도로 제한하는 식이 적당해 보임 어차피 로컬에 설치된 AUR 패키지에 자동·무검토 업데이트를 적용하는 사람은 없을 테니, 공격면은 이미 꽤 작음 - 단순 **취약점 스캔**으로는 못 잡았을 가능성이 큼 miasma 웜의 핵심이 바로 서명과 도우미 방식이 너무 빨리 바뀐다는 점임 암호화된 악성 임플란트는 업로드된 GitHub 위치마다 달라지는 AES-128-GCM 키로 페이로드를 복호화하고, 코드의 메서드 이름도 동적으로 바뀌며 암호화된 심볼 오프셋도 섞어 재사용함 변이형 악성코드라 서명 기반 도구에는 최악의 상대임 APT28/29는 GitHub에서 C2 인프라로 쓰이는 사용자와 저장소를 Microsoft가 자동 차단하는 속도가 느리다는 점에 어느 정도 의존하는 것으로 보임 이게 보안 전략에 무엇을 뜻하는지 생각해 볼 필요가 있음 서명이나 문자열을 스캔할 수 있을 때쯤이면 이미 완전 자동화된 봇넷과 고양이쥐 게임을 하는 단계이고, 이길 수 없음 지난주 동안 이 임플란트 변화를 따라간 공급망 도구는 socket.dev 정도뿐이었고, 다른 도구들은 Miasma를 알지도 못한 채 새 캠페인으로 재발견했음 새 생태계용 어댑터가 24시간마다 나오는 속도를 따라갈 만큼 페이로드를 빠르게 역공학할 인력과 도구체인이 부족했음 여기서 완전 자동화란 다른 패키지 생태계에서 48시간도 안 된 시점에 훔친 자격 증명을 이미 쓰고 있다는 뜻임 이메일 주소와 이름이 계속 등장하는데, 이 자기 전파 웜의 영향을 이해하지 못했을 가능성이 큰 사람들로 보임 예를 들어 bun에 의존하는 패키지를 찾는 침해 지표도 큰 도움이 안 됨 악성코드는 외부 수단으로 다시 내려받으면 그만임 두 번째 PyPI 캠페인에서는 RedHat 캠페인의 첫 악성 드로퍼 물결이 PyPI 유지보수자에게 표시된 뒤, 압축 WHL 파일과 자동 실행되는 setup.pth 파일로 드로퍼를 내려받도록 바꿨음 이 생태계들의 패키지 관리자가 chroot, 샌드박스, 네트워크·도메인 로그, 항목별 허용 목록을 전제로 처음부터 다시 작성되지 않는 한, 공급망 공격을 통한 악성코드 배포 전략은 계속 현실적일 것임 완화 도구 저장소는 [1]이고, 기술적 세부사항은 블로그 글 [2]에 있음 Composer, Rubygems, NPM, PyPI, Go도 모두 영향을 받는 등 모든 패키지 관리자 전반의 문제임 패키지 관리자 전반에 얼마나 많은 부주의와 외부 신뢰를 얹고 있는지 더 공개적으로 논의해야 하고, 이건 정말 바뀌어야 함 [1] [https://github.com/cookiengineer/antimiasma]() [2] [https://cookie.engineer/weblog/articles/malware-insights-mia...]() - AUR에서 직접 설치할 수 있는 **pacman 래퍼**가 나오기 시작했을 때 정말 불편했음 AUR에서 뭔가 설치한 적은 있지만, 대부분은 중간 단계를 건너뛰고 프로젝트 웹사이트로 직접 가는 쪽을 선호함 미리 만들어진 PKGBUILD가 오타 선점이나 npm·pip 의존성 악용 위험을 감수할 만큼 편리하지는 않음 - `yay` 같은 래퍼는 업데이트 때마다 **PKGBUILD 차이**를 보여줌 처음 설치할 때 URL을 확인하고 설치 스크립트 등이 타당한지 보며, 이후 업데이트는 대부분 버전 번호와 체크섬만 바뀜 오타 선점 공격은 꽤 명확하게 드러날 것임 첫 설치에는 조금 취약하지만, 프로젝트 웹사이트에 가서 다운로드를 누르는 방식도 마찬가지임 - Arch가 엘리트주의적이거나 일반 사용자를 막는다는 비판을 계속 받지만, **위험한 일을 쉽게 만들지 않는 것**에는 분명한 장점이 있음 삶의 여러 측면에서도 마찬가지임 Void Linux를 쓰고 난 뒤 Arch에서도 비슷한 분리를 위해 `aurutils`로 바꿨음 직접 빌드해 로컬 AUR 저장소를 쉽게 유지하고, `pacman`으로 설치·관리할 수 있어 전체 업그레이드 과정이 나아짐 - 이 절충은 나에게는 가치가 없음 Linux로 옮긴 이유가 Windows 사용자처럼 웹사이트에 가서 “download”를 누르며 프로그램 업데이트에 시간을 낭비하려는 건 아니었음 다만 언급한 pacman 래퍼들은 위험해 보임 - AUR과 다른 배포판의 비슷한 저장소들은 정말 무섭게 느껴짐 이런 저장소를 쓰는 튜토리얼이 너무 널리 퍼져 있어서, 거의 동료 검토도 없는 낯선 사람에게 무기한 **root 권한**을 주고 싶지 않은 내가 이상한 사람처럼 느껴질 정도임 업데이트가 필요 없거나 드문 패키지 한 버전을 설치하려고 그런 위험을 감수하는 셈임 - 빠르게 읽어보니 npm에서 `atomic-lockfile`, `js-digest`, `lockfile-js`를 설치한 것으로 보임 영향을 받은 패키지 목록은 [1]에 있음 시스템 확인 방법을 바로 찾지 못해서, 외부 패키지와 날짜 관련 정보를 찾으려고 `pacman -Qmi`를 실행했음 출력 결과를 영향 받은 패키지 목록과 대조하면 됨 또 여러 위치에서 다음처럼 파일을 검색할 수 있음 `grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"` `grep -rl "atomic-lockfile" ~/.npm 2>/dev/null` `grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null` 실행 후 패키지가 자신을 삭제하는지는 모름 다른 정보들이 별 도움이 되지 않아 기본 명령어라도 공유하고 싶었음 [1] [https://md.archlinux.org/s/SxbqukK6IA]() - 내가 한 방식은 이렇음 `yay`로 AUR에서 온 설치 패키지 목록을 얻음: `yay -Qam > packages_aur.last` [https://md.archlinux.org/s/SxbqukK6IA#]()에서 목록을 받음: `curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt` 그다음 `grep -wFf compromised.txt packages_aur.last`를 실행하면 두 파일에 모두 있는, 즉 어느 시점에 손상됐던 패키지가 나올 것 같음 - 공격자는 최소 세 가지 **Node 의존성**을 사용했으니 `atomic-lockfile`만 확인해서는 부족함 `js-digest`와 `lockfile-js`도 사용됐고, 어느 시점에는 npm 대신 bun으로 바꿨음 - 이것도 참고할 만함: [https://github.com/lenucksi/aur-malware-check]() - Arch Linux AUR에 악성코드를 넣으려는 상황에서도 악성코드는 여전히 **NPM**을 통해 배포된다는 점이 웃김 전설적인 플랫폼임 - `emacs-magit`은 어떻게 영향을 받은 건지 모르겠음 내가 알기로는 JavaScript가 전혀 없음 - 검토 없이 임의의 서드파티 패키지·라이브러리·애플리케이션을 설치하지 말라는, 늘 그렇듯 공정한提醒가 됨 다행히 이번 일은 AUR에 국한됐고, AUR은 사실상 누구나 올릴 수 있는 패키지 저장소이며 공식 저장소와 달리 설치 전 검토가 필수라고 여러 번 경고되어 있음 `rua`와 비슷한 명령줄 도구들은 AUR에서 설치하기 전에 패키지를 검토하기 쉽게 해 줌 같은 컴퓨터에서 은행 업무를 한다면 의존하는 소프트웨어를 검토하지 않을 변명은 없음 패키지 수를 낮게 유지하고 필요한 것만 쓰면 업그레이드할 때도 훨씬 단순해짐 - “검토”를 어떻게 하라는 건가 설치하기 전에 코드 한 줄 한 줄을 전부 읽으라는 뜻인가 바이너리 패키지라면 어떻게 하나 설치하는 모든 것에 **재현 가능한 빌드**를 만들라는 건가, 아니면 소스 기반 배포판으로 옮기라는 건가 이 책임을 사용자에게 떠넘기는 건 지속 가능한 해법이 아님 상식이 들어갈 여지는 있지만, 이걸 사용자 탓으로 돌리는 건 말이 안 됨 - 그럴듯하게 들리지만 결국 실행 불가능한 조언이라서, 오히려 무용한 것을 넘어 해로움 세상에는 한 사람이 평생 읽을 수 있는 양보다 훨씬 많은 코드가 있음 본인도 자기 컴퓨터에서 현재 실행 중인 소스 코드의 1%도 읽지 않았을 가능성이 큼 그렇다면 컴퓨터 사용을 멈췄나 그 안에서 일어나는 일을 어떻게 신뢰할 수 있나 - “설치 전 반드시 검토하라”는 입장은 다시 평가해야 한다고 봄 Arch Linux 개발자들은 훌륭한 일을 하고 있고 개인적으로 감사하지만, 공급망 공격이 이렇게 늘어나는 요즘에는 **사용자 경고**만으로는 이미 오래전에 한계가 왔다고 느낌 쉬운 해법은 보이지 않지만, 게시 전 동료 검토나 유예 기간 같은 통제가 문제를 어느 정도 완화할 수는 있을 것임 - AUR은 예전부터 Arch의 큰 장점으로 높게 평가됐지만, 그 편의성에는 대가가 따랐음 패키지를 고아로 표시하고 2주 기다린 뒤 원 유지보수자가 휴가 중이라 응답하지 못하면, 공격자가 유지보수자로 배정되어 매운 업데이트를 배포할 수 있다는 게 말이 안 됨 - **불변 시스템 파일**, 기본 사용자 로컬 설치, 구성요소와 프로그램에 최소 권한만 주는 조합을 강하게 뒷받침하는 사례라고 봄 불변 배포판, Wayland, Flatpak에 일부 조각은 있지만 중요한 구멍이 남아 있음 가장 큰 문제는 샌드박싱이 패키지 형식에 묶여 있다는 점인데, 이건 실수라고 생각함 샌드박싱과 접근 권한은 시스템 수준의 기능이어야 해서 임의 바이너리도 쉽게 빈틈을 빠져나가지 못해야 함 문제를 완전히 해결하지는 못해도 피해 범위를 크게 줄이고 배포판 사용자를 덜 매력적인 표적으로 만들 수 있음 - 걱정되는 사람들을 위해 최신 스크립트와 패키지 목록을 모아 감염 여부 확인에 도움 되는 저장소를 찾았음: [https://github.com/lenucksi/aur-malware-check]() - 같은 목록([https://md.archlinux.org/s/SxbqukK6IA]())을 Claude에 주고 **악성코드 확인**을 해 봤는데, 이 스크립트가 하는 것과 본질적으로 같은 검증을 수행했음 어느 쪽이든 충분할 것 같음 - Arch Linux 사용자는 아니지만 NodeJS를 많이 쓰는데, 여기도 비슷한 공격을 자주 겪음 요즘 **패키지 관리**를 제대로, 안전하게 하는 곳이 어디인지 궁금함 - AUR은 사용자 지원 기반이라 악성코드가 종종 패키지에 섞여 들어감 이번처럼 큰 규모는 아니었지만, 애초에 안전하지 않다는 점이 분명했고 곳곳에 위험 경고가 붙어 있었음 - Linux 배포판들은 잘하고 있음 모두 패키지를 검토하고 책임지는 유지보수자가 있음 Arch Linux도 마찬가지임 AUR의 본질적인 불신뢰성은 Arch Wiki와 주변 문화에서 늘 명시적으로 드러났고, npm이나 pip 같은 프로그래밍 언어 패키지 관리자와는 다름 - AUR을 쓰지 않으면 Arch는 괜찮음 AUR을 쓴다면 전부 확인해야 함 대부분의 배포판도 괜찮고, 큰 배포판들은 꽤 좋은 기록을 갖고 있음 - Node 생태계에는 특히 취약하게 만드는 뭔가가 있는 것 같음 지나친 **DRY 문화** 때문일 수도 있고 다른 이유일 수도 있음 내가 써 본 것 중 비슷한 수준의 의존성 트리 악몽은 없었음 - AUR에는 **고아 패키지 1만 5천 개**가 있음 오늘 아침 인기순으로 정렬해서 거의 업데이트되지 않는 3개를 입양해 빌드했음 고아 패키지를 쓰고 있다면 나쁜 사람들이 가져가기 전에 직접 입양하는 걸 고려해 볼 만함 - 틀릴 수도 있지만, 이번 상황은 **데스크톱 Linux 채택 증가**의 신호처럼 보임 - AUR이 필요했던 적이 없음 공식 저장소에 없는 패키지가 필요하면 직접 빌드하거나, 바이너리 릴리스가 있으면 내려받음 이렇게 하면 빌드할 때 root를 쓸 필요가 없고, 프로그램을 단일 사용자용으로 로컬 설치할 수 있어 대부분의 데스크톱 사용 사례에는 오히려 맞는 방식임 최소한 개발자 → 사용자 경로에 비해 개발자 → 유지보수자 → 사용자라는 한 단계의 **악성 코드 삽입 가능성**이 줄어듦 - `makepkg`는 root로 실행하면 적극적으로 거부함 굳이 `env EUID=123 makepkg ...` 같은 식으로 우회하지 않는 한 root로 돌지 않음 다만 pacman이 사용자 수준 설치를 지원하면 좋겠음 현재는 root가 아니면 설치를 거부하고, 사용자 이름공간으로 자신을 root에 매핑하는 식으로 우회할 수는 있음 - 이번이 AUR이었다는 건 이해함 AUR 여부와 관계없이 패키지를 설치할 때 어떤 단계를 거치는지, 설치하려는 패키지와 의존성이 악성코드가 아님을 어떻게 보장하는지 공유해 주면 좋겠음 나쁜 패키지를 설치하고 나면 정말 되돌리기 어려워 보임