ハクソク

世界を動かす技術を、日本語で。

AURパッケージがインフォスティーラーとルートキットに侵害される

2026年6月12日原文(discourse.ifin.network)

概要

Arch LinuxのAURで、信頼されたメンテナーを装った攻撃者による大規模なサプライチェーン攻撃が発生。 408以上のパッケージがマルウェアに感染し、現在も影響が拡大中。 主な手口はpreinstallスクリプトでnpm経由の悪意あるパッケージ導入。 感染確認時は証拠保全とシステム再構築が推奨。 攻撃の詳細や対策方法は公式ブログやGitHubのスクリプト参照。

Arch Linux AURパッケージへの大規模攻撃

  • AURパッケージメンテナー を装った攻撃者による サプライチェーン攻撃 発生

  • 408以上のパッケージ が感染、現在も 攻撃継続中

    • 主な感染手法
      • preinstallスクリプトで npm を利用し、 atomic-lockfile などの悪意あるパッケージ導入
      • 別バリアントでは bun 経由で js-digest パッケージをインストール
      • js-digest 内に埋め込まれたLinux実行ファイルのSHA256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

  • 被害状況と拡大傾向

    • 感染パッケージは主に利用頻度の低いもの中心
    • 一部は eBPF rootkit や infostealer として動作
    • 攻撃者は herbsobering 名義でNPMやGitHubにも悪意ある成果物を公開

  • 攻撃の背景

    • AURは パッケージの引き継ぎ（adopt） が容易
    • 放棄されたパッケージを自動で探し、乗っ取る行為が一般化
    • 信頼されたメンテナー のなりすましによるコミットも発生

Archユーザー向け対応策

  • Arch Linux未使用者 ：影響なし
  • Arch Linux利用者 ：
    • 感染パッケージ一覧の確認 と aur_check.shスクリプト （GitHub）での自動調査推奨
    • Ioctlブログ 掲載の IoC（Indicators of Compromise） の確認
    • 感染発見時は 証拠保全 を行い、 通常の侵害対応手順 を実施
    • 全ての認証情報のローテーション および システム再インストール 推奨
    • rootkit感染の可能性により、 システム信頼性喪失

追加情報・参考リンク

攻撃の教訓と今後の対策

  • サプライチェーン攻撃 の深刻化傾向
  • パッケージ管理体制 の見直しと 信頼性向上 の必要性
  • 自動化によるパッケージ乗っ取りリスク への警戒強化

Hackerたちの意見

こっちに、侵害されたパッケージをスキャンする簡単なスクリプトがあるよ： https://cscs.pastes.sh/aurvulntest20260611.sh これは俺のスクリプトじゃないけど、読みやすいし解析もしやすい。スクリプトを直接bashにパイプするのはやめとけ。

└

このリストが完全だとは限らないから、PKGBUILDやソースは必ず確認してね。AURは基本的にあまり信用できないよ。実際、こんな侵害がもっと早く起こらなかったことに驚いてる。

└

もっと手軽な方法もあるよ：comm -1 -2。comm(1)について学ぶのはいつでも悪くないからね。

└

pacmanは日付ロケールをサポートしてるから、'9 Jun'で検索するのは英語ロケール（または似たようなフォーマットのロケール）でしか機能しないよ。修正したら、俺の場合は「jd-gui」がフラグされたけど、実際には侵害の2時間前に「jd-gui-bin」をインストールしてたんだ。運が良かったのは、その夜は怠けたくてソースがコンパイルされるのを待たずに-binパッケージを選んだことだね。

明らかにAURから何かをインストールするのは慎重にやらなきゃいけないし、過去には怪しい（ちゃんと作られてない）パッケージもあったけど、悪意のある注入が見られるのは心配だね。AURには主に2つの問題があると思う：1. それはオープンソースの歴史の中で、もう少し平等な時代の名残で、一般的にサードパーティのコードを信頼できたこと、2. 孤児パッケージはその履歴と審査を保持したまま誰でも引き取れること。もう(1)は過ぎ去ったと思うけど、(2)はAURアカウントへの厳しい管理やAURヘルパーからの追加の安全策で軽減できるかも。最近オーナーが変わったパッケージには大きな警告を表示するとかね。もちろん、それでも「y」を押して進む人はいるだろうけど、何もしないよりはマシだよ。あるいは、AURヘルパーを完全に避けて、自分でPKGBUILDから必要なパッケージを確認・ビルドするのもいいかも。

└

#2が合理的なポリシーだった時代なんてなかったよ。

このキャンペーンはまだ続いてるよ。俺の古いパッケージの一つ（何年も動いてなくて、しばらく孤児だったやつ）が引き取られたってメールが来たんだけど、すぐに悪意のあるコミットがプッシュされたみたい。今はnpmの代わりにbunを使ってるみたいだから、npmベースの回避策は効果がないだろうね。 https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

10年くらい前にArch Linuxでエミュレーター（Mednafen）をインストールしたのを覚えてる。プログラムが動かなかったのは、システムにないライブラリにリンクされてたから。メンテナーが自分のシステムでソフトウェアをビルドして、彼のシステムにあったライブラリを使ってたけど、依存関係には載ってなかったんだ。公式にメンテナンスされているパッケージで、これらはランダムなボランティアやホームコンピュータではなく、専用のビルドサーバーでビルドされていると思ってた。今もArchが同じようにビルドしてるかは分からないけど、この出来事で怖くなってディストロを変えたんだ。

└

これが普通から変わったのは最近のことだよね。Debianは長い間この方法で運営してたし、完全に禁止したのは2019年になってからだよ。

└

クリーンなイメージでパッケージのビルドやインストールをテストするためのツール（例えばpkgctl）があるんだから、メンテイナーは公開する前にこれを使うべきだよね。

└

pkgctl buildを使っても、makedepends=がビルド環境に共有ライブラリを引っ張ってくることがあるけど、depends=はそうじゃない場合もあるんだ。もし.soの依存関係が検出されたら警告が出るけど、それに気づいて行動するのはメンテイナー次第。安全性やセキュリティの観点から、Arch Linuxは再現可能なビルドプロジェクトの推進力の一つで、OSの大部分については、そのバイナリが実際にソースコードからビルドされたことを独立して確認できるんだ。公式パッケージの監査の話はNixOSよりも強力で、Debianと同じくらいだよ：https://reproducible.archlinux.org/ でも、これらはAURの事件とは全く関係ないけどね。

これに対する解決策って何だろう？ネットワークアクセスなしでDockerコンテナにこういうパッケージをインストールするの？AURだけに限らないと思うんだ。2026年には、すべてのソフトウェアソースが怪しいと考えるべきだよ。特にバイブコーディングが普及しているし、クローズドソフトウェアはオープンソースよりももっと厄介だよね。だって、ブラックボックスなんだから。

Hacker Newsで議論の続きを見る