AURパッケージが情報窃取マルウェアとルートキットに感染
(discourse.ifin.network)- AURパッケージリポジトリ は、メンテナンスされていないパッケージを誰でも引き取り、PKGBUILDや関連ファイルの変更を提出できる仕組みであり、今回の事案では408件以上のパッケージが感染した形跡がある
- 新しいAURパッケージメンテナーが信頼されたメンテナーになりすましてパッケージを引き取り、他のAURメンテナーが感染パッケージの削除作業を進めた
- 初期の感染パッケージは、preinstallスクリプトで
npmを実行し、悪性ペイロードであるatomic-lockfileをインストールするよう改変されていた - その後の感染では、Bunで悪性の
js-digestをインストールしており、NPMは当該パッケージを削除した - 多くのパッケージは使用頻度が低いものの、影響範囲が広く、情報窃取の挙動に加えて eBPFルートキット まで含むサプライチェーン攻撃である点が重要
事案の状況
-
何が起きたのか
- 新しいAURパッケージメンテナーが信頼されたメンテナーになりすまし、408件以上のパッケージを引き取って感染させた形跡がある
- 侵害が報告された後、他のAURメンテナーが感染したパッケージを削除する作業を進めた
- 2026-06-12T17:30:00Z時点で、AURメンテナーは すべての悪性コミットを削除したと報告している
- AURメンテナーは、パッケージ引き取り機能を含む一部機能に統制と制限を適用する方針
- Arch Linuxは Active AUR malicious packages incident の告知を出した
-
悪性依存関係
- 攻撃には少なくとも2つの別個の悪性依存関係が含まれる
- 初期に影響を受けたパッケージは、preinstallスクリプトで
npmを使って悪性ペイロードであるatomic-lockfileパッケージをインストールするよう改変されていた premake-gitパッケージには、その変更の コミット例 がある- その後の感染では、Bunを使って悪性の
js-digestをインストールしており、NPMはjs-digestを削除した - 攻撃分析については、Preliminary analysis of AUR malware に詳しい分析がある
対応と侵害指標
-
推奨される対応
- Archを使っていない場合、今回のAURパッケージ侵害の直接的な影響対象ではない
- Archユーザーは、影響を受けたパッケージ一覧を確認し、露出有無確認スクリプトでシステムを点検すべき
- 原文でリンクされている
aur_check.shは古いバージョンであり、最新の確認対象は該当Gistの案内に従う必要がある - 侵害指標が見つかった場合は、適切なフォレンジック調査のためにシステムを保全すべき
- 感染パッケージが見つかった場合は、一般的な侵害対応手順に従い、すべての認証情報を置き換え、Archの再インストールを検討すべき
- ルートキットの可能性があるため、システムの信頼性は保証できなくなる
- すべてのユーザーは、ネットワーク上で outbound Torトラフィックを遮断する対策を取るべき
-
侵害指標
js-digestに組み込まれた悪性Linux実行ファイルのSHA256は7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316であるbpftool map listで不審な eBPF Maps を検出できる- 不審なmap名には
hidden_pids、hidden_names、hidden_inodesがある
-
追加の確認事項
- 既存のメンテナーアカウントが悪性コミットを行ったのではなく、既知のメンテナーアカウントがなりすまされたものである
- 多くのパッケージは使用頻度が低いが、408件以上という感染範囲は大きい
- 情報窃取の挙動に加えてeBPFルートキットまで含むサプライチェーン攻撃はまれな事例である
- Socket.devの
atomic-lockfileページでは、悪性NPMパッケージのダウンロード数が134回と表示されている - NPMパッケージはユーザー
herbsoberingがメンテナンスしている - GitHubで
herbsoberingというユーザー名を検索すると、リバースシェル／プロキシツールとみられる単一コンテナイメージherbsobering430がある - AURパッケージリポジトリでは、パッケージが未管理状態と表示されると、誰でもそのパッケージを引き取り、PKGBUILDおよび関連ファイルの変更を提出できる
- 放置されたパッケージを自動的に見つけて引き取る方法は珍しいことではなく、関連する背景は Mastodonスレッド にある
1件のコメント
Hacker Newsの意見
AUR はユーザーが作成した PKGBUILD の集まりにすぎない、ということを受け入れるべきだ
AUR からインストールするすべての PKGBUILD のソースは必ず確認すべきで、アップデートも例外ではない。これは 10年以上前からずっと議論されてきた前提であり、
yayのような公式 AUR ヘルパーが存在しない理由もここにあるArch Linux がエリート主義的だという不満も多いが、現実には自分が何をしているかを理解していて、各段階で手取り足取り案内されることを望まない人向けのディストリビューションだ。無作為な AUR パッケージをインストールしてシステムを壊したり侵害されたりしたなら、それは自己責任だということでもある
ただし、誰でも AUR パッケージを引き継げる時代は終わるかもしれない。毎回影響を受けたパッケージを差し戻すコストだけ見ても大きすぎる。代案としてすべての引き継ぎ依頼を審査するのも負担が重く、毎回役に立つ保証もない
インターネットアクセスがない、あるいは公開されても構わないものにしかアクセスしない環境で実行しない限り、その通りだと思う
AUR はそうではないかもしれないが、他のエコシステムは権限モデルやサンドボックスで理論上は改善可能だ。ブラウザー拡張にはその選択肢がすでにあるが、「一般」ユーザーはほとんど使っていない
残念ながら 99.99% の人はすべてを確認できないか、その時間がない。信頼されたメンテナーがいるディストリビューションのパッケージや、権限とある程度の審査がある iOS App Store のような場所が最も安全に見える
今回は PKGBUILD の中でかなり雑に
npm installしているので少し異例だ。今では AUR 以外のほぼすべてのパッケージリポジトリも同じ問題を抱えており、依存関係の連鎖全体を手作業で監査するのは現実的ではないもちろん、私にも解決策はない
人々は SELinux を無効にし、
--privilegedは seccomp と AppArmor を無効化し、サンドボックス脱出の CVE も存在する最終的には
username/packagename-bin|gitのような構造になってほしい。そうすれば、人々が実際に何を誰からインストールしているのかがずっと明確になるはずだこのキャンペーンはまだ進行中だ。たった今、昔の自分のパッケージのひとつが引き継がれたというメールを受け取ったが、それは何年も動いておらず、しばらく孤児パッケージになっていたものだ。引き継ぎ直後に 悪意あるコミット が入った
今は npm の代わりに bun を使っているようなので、npm ベースの回避策は効果がない可能性が高い
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
不便ではあるだろうが、他人が放棄したパッケージを引き継がせる代わりに、AUR が新規投稿を強制し、一定期間が過ぎた孤児パッケージを定期的に削除するほうがよいかもしれない
AUR から何かをインストールするときに注意が必要なのは当然で、以前から怪しいパッケージ、つまりビルドが壊れていたりパッケージ化が不適切だったりするものは常にあったが、能動的な悪意の挿入 を目にするのは懸念される
AUR には大きな問題が 2 つあると思う。第一に、サードパーティーのコードをおおむね信頼できた、もう少し平等主義的だったオープンソース時代の名残だという点。第二に、孤児パッケージを誰でも既存の履歴と検証実績をそのまま引き継いで取得できるという点だ
第一の時代はすでに過ぎ去っており、第二は AUR アカウントにより厳格な統制を設けるか、AUR ヘルパー側に追加の保護措置を入れることで緩和できる。たとえば最近所有者が変わったパッケージなら、大きくて怖い警告を表示するような形だ。それでもただ
yを押して進む人はいるだろうが、ないよりはましだあるいは AUR ヘルパー自体を避け、必要なパッケージを PKGBUILD から直接確認してビルドする方法もある
確認するよう積極的に促し、最後にリスクを受け入れたあとで変更があったかどうかも知らせてくれる
ただし、「AUR は有害だ」という見方は新しいものではない。AUR を使う人はここにあるリスクを理解すべきで、実質的には StackOverflow で見つけたものを
curl | bashするより一段階ましな程度だこの件から7時間以上経っているのに、archlinux.org や aur.archlinux.org ではまだ何の言及もない。なぜなのか分からない。ユーザーがこの件を認識していると示す措置を取るまでは、AUR を止めるべきだった
例えば AUR API の URL を少し変更して、yay/yaourt ユーザーが何が起きたのか調べるように仕向けることはできる。新しい API には、ユーザーへ通知し、続行前にメッセージを読んだことを確認する仕組みが必要だ。特に、すべてのマルウェアを見つけられたかも確実でない状況ならなおさらだ
また、取り下げられた、または侵害された AUR コミットのデータベースが必要で、ユーザーがそのパッケージをインストールしたことがあれば警告する仕組みも必要だ
名前そのものにも入っているし、Wiki にも AUR はユーザーリポジトリであり、盲目的に信頼してはならないと明確に案内されている
すぐ上の大きな赤い枠にもそのまま書かれている: https://wiki.archlinux.org/title/Arch_User_Repository
AUR には絶対にインストールしないものがたくさんあり、そのすべてをメーリングリストで流すのが最善だとは思わない
悪意あるパッケージをインストールしたユーザーへ警告するというアイデア自体は嫌いではないが、実現性は低い。AUR には商用ツールにあるようなインストール追跡がないからだ。誰がどのパッケージをインストールしたか、どうやって分かるのか？ AUR は基本的にパッケージの場所を示す電話帳に近く、ログインや認証情報すら要求しない
だから警告は、ユーザーが注意を払っていれば実行できるツールから出るべきで、実際に注意を払うことが求められる。例: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
新しい API がユーザーに通知して、読んだことまで確認するというのは、いったいどう動くべきなのか？ AUR パッケージはただの git リポジトリであり、AUR ヘルパーが何をするかしないかを Arch メンテナーが制御することはできない
既知の影響パッケージを全部列挙したくないとしても、少なくとも AUR パッケージを使う人は、自分が使うすべてのパッケージのすべてのファイルを読むべきだという公式見解くらいは勧告すべきだ
それももっともではある。影響リストの一部のパッケージは知っているが、ひどく古く、上流プロジェクトももう保守されていない
全体の被害者数がどれくらいかは分からないが、AUR チームは正確な数字を持っている可能性が高い。影響度に応じて最善を尽くして対処しているのだろうと思う
こういうことは結局避けられなくなっていて、変化がなければ今後さらに頻繁に起きる可能性が高い。AUR PKGBUILD システムはとても気に入っていて、自分で書くときにもよく活用している
最も深刻で、しかも直しやすい問題は、孤児パッケージを誰でも引き取れるのに、その事実がエンドユーザーにまったく知らされないことだ
パッケージを削除させるのは、かかる手間の割に得るものが少ないので、管理権を手放す最適な方法が孤児パッケージ化になってしまう。これは逆であるべきだと思う。少なくともユーザーには、パッケージが孤児になったことを明確に知らせるべきだ
この負担は paru や yay のような AUR ヘルパー側により大きくあるのかもしれず、そうした変更をしてくれることを勧めたい
侵害されたパッケージをスキャンする簡単なスクリプトがある
https://cscs.pastes.sh/aurvulntest20260611.sh
私のスクリプトではないが、読んで把握しやすい。絶対にスクリプトをそのまま bash にパイプしてはいけない
comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)comm(1)を学ぶのに悪いタイミングというものはないたぶん自分みたいにしばらく、数か月
yay -Syuを実行していなかったなら大丈夫なんだろう？ …そうだよね？くそっ、Arch を再インストールする羽目にはしないでくれ。前回は1週間かかった
更新: archinstall は良い。15分くらいで復旧できた
常に PKGBUILD とソースを確認すべきだ。AUR はそもそも信頼の置けるものではない。むしろ、こうした侵害がもっと早く起きなかったことの方が驚きだ
9 Junを検索する方法は英語ロケールや似た形式を使うロケールでしか動かない自分の環境向けに直した後は
jd-guiが引っかかったが、実際には侵害の約2時間前にjd-gui-binをインストールしていた。その晩、ソースのコンパイル待ちをしたくなくて怠けて-binパッケージを選んだおかげで運が良かったようだArchコミュニティがスクリプトやツールを素早く公開している。
現在、感染の有無を確認するための最新の統合ユーティリティはこれ。
https://github.com/lenucksi/aur-malware-check
また、aur-requestメーリングリストには、悪意あるコミットを巻き戻すための削除依頼や孤児化依頼が多数投稿されている。
https://lists.archlinux.org/archives/list/aur-requests@lists...
そのスクリプトには理解しづらい部分が多く、コードを読むだけで安全かどうかを簡単には判断できない。
公式のArch開発者側からの反応や解決策を期待してしまう。
こうした大規模マルウェア攻撃にまつわる切迫感と重要度がよく伝わる。
10年ほど前にArch LinuxでエミュレータのMednafenをインストールした記憶がある。プログラムは起動しなかったが、それは自分のシステムにないライブラリにリンクされていたためだった。
調べてみると、メンテナが自分のシステムでソフトウェアをビルドしており、そのシステムにあったライブラリが使われていたのに、依存関係には記載されていなかった。
それは公式メンテナンス対象のパッケージで、こういうものは専用のビルドサーバーで作られるものだとずっと思っていたので、任意のボランティアや自宅のコンピュータでビルドされるとは考えてもいなかった。Archが今でも同じ方式でビルドしているのかは分からないが、その出来事は十分に怖く、ディストリビューションを乗り換えるきっかけになった。
pkgctl buildを使っていても、こうしたことは起こりうる。makedepends=が推移的に共有ライブラリをビルド環境へ持ち込んでいたのに、depends=には入っていないケースだ。.so依存関係が検出されると警告は出るが、それを見て対処するのはメンテナの役目だ。安全性とセキュリティの観点では、Arch Linuxは再現可能ビルドプロジェクトを牽引する一角であり、OSのかなりの部分について、そのバイナリが本当にソースコードからビルドされたものかを独立に検証できる。公式パッケージの監査体制はNixOSより強く、Debianと同程度だ。
https://reproducible.archlinux.org/
ただし、これらすべては今回のAURの件とはまったく別の話だ。
pkgctlだ。メンテナであれば、公開前にこうしたツールを必ず使うべきだ。
この問題の解決策は何だろうか。こうしたパッケージは、ネットワークアクセスのないDockerコンテナ内でインストールすべきなのだろうか。これがAURにだけ限られると考えるべきではないと思う。
2026年には、すべてのソフトウェアの出所を疑うべきだ。特にバイブコーディングが広がっている状況ではなおさらで、クローズドソースのソフトウェアはブラックボックスなので、オープンソース以上にひどい混沌になっている。
本気で乗り換えた場合、バッテリー持ちがどれほど悪化するのか知っている人はいるだろうか。
関連ニュースがさらに出てきている。
https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
実行されると単にメールを送るか通知を表示するカナリアバイナリを作って、それを
npmと呼ぶというアイデアを考えたことがある。この時点で、npmバイナリの名前を変えないのは大きなリスクだ。