Arch Linuxユーザー必読：AURコミュニティパッケージ約1900個がマルウェアに感染、「Atomic Arch」攻撃の全容と完全復旧マニュアル

SafeDepのキャンペーンページとコミュニティが集約したリストによると、最終的に1,937個の影響を受けたAURパッケージ名が列挙されており、攻撃の甚大な規模が浮き彫りになりました 。なお、公式のArch Linuxリポジトリ（core、extra、community）は一切影響を受けておらず、本件はAURのみに限定されたインシデントです 。

攻撃手法：信頼ベースのワークフローを悪用

Atomic Arch攻撃は、Archのインフラに対する侵害ではありませんでした。その代わりに、AURの孤立パッケージ（orphaned packages）の引き継ぎワークフロー、つまりコミュニティメンバーが放棄されたパッケージの所有権を主張できる仕組みを、外科的に悪用したものです 。

攻撃は検出回避のために手口を巧妙化させながら、明確に異なる二つの波で展開されました。

第1波：npmを利用したフック（6月11日）

攻撃者はまず、孤立パッケージを組織的に引き継ぎました。メンテナ権限を取得した後、彼らが改変したのはソフトウェアのソースコードそのものではありません。ソースコードの変更はチェックサムを破綻させ、警告を発する可能性があるからです。代わりに、彼らはビルドスクリプトであるPKGBUILDファイルに、悪意のあるnpm依存関係を注入しました。使用されたのは atomic-lockfile (v1.4.2) と js-digest (v4.2.2) です 。これらはmakepkgプロセスの途中で自動的に実行されるように設定されました。悪意のあるコードは、.installスクリプトにも埋め込まれ、シェルの文字列分割、引用符の混在、16進数エスケープなどを使って隠蔽され、手動レビューを回避しようとしました 。

第2波：Bunへの切り替え（6月12日）

わずか1日後、第2波が出現しました。今回は、npmのインストールパスがBunベースのインストールプロセスに置き換えられ、lockfile-js (v1.4.2) という別の悪意あるパッケージが使用されました 。この変化は検出を複雑にしました。第一波の兆候（IoC）の多くがnpmレジストリに注目していたため、セキュリティツールは新しいランタイムと依存関係を監視するために更新が必要になったのです 。

ソフトウェア自体ではなくビルド手順だけを汚染することで、攻撃者は従来の完全性チェックを巧みに回避しました。上流のソースコードはクリーンに見え、マルウェアはビルド時に初めて取得・実行されるため、PKGBUILDスクリプトを手動で検査しないユーザーには見えなかったのです 。

悪意あるペイロード：情報窃取とルートキット

侵害されたパッケージをビルドしたマシンには、スパイ活動と永続化のために設計された2段階のペイロードが配信されました。

• Rust製の認証情報スティーラー: ブラウザセッション、SSHキー、GitHubトークン、npmトークン、Slack/Teamsセッション、Vaultトークン、Docker/Podman認証情報、クラウドアクセスキーなど、開発者の機密情報を収集することに特化したバイナリでした 。
• eBPFルートキット（root権限時のみ）: パッケージがroot権限でビルドされた場合、マルウェアはeBPFルートキットを展開し、自身のファイル、プロセス、ネットワーク活動をpsやhtopといった標準の検出ツールから隠蔽できました。このルートキットは /sys/fs/bpf/ を永続化に利用するため、削除が極めて困難です 。

認証情報スティーラーとカーネルレベルのルートキットという組み合わせは、特に重要なアクセスキーや機密データを保持することの多い開発者のワークステーションにとって、深刻な脅威となりました。

コミュニティと開発者の対応

Arch Linuxコミュニティとセキュリティ業界は迅速に対応しましたが、その対応は攻撃の規模によって複雑化しました。

• Archチームの対応: Archのコントリビューターは6月11日にAUR報告スレッドを開設し、悪意あるコミットの差し戻し、攻撃者アカウントの追放、孤立パッケージプールのクリーンアップを開始しました。Arch Linuxは翌週の月曜日に、更なる悪用を防ぐためAURでの新規アカウント登録を一時停止しました 。ArchのパッケージメンテナであるJonathan Grotelüschen氏は、チームが「すべての悪意あるコミットの復元または削除、および責任あるアカウントの追放」に取り組んでいることを確認しました 。
• コミュニティ内の議論: この攻撃は激しい議論を引き起こしました。PrivacyGuidesフォーラムのようなプラットフォームでは、一部のコミュニティメンバーが、この規模の侵害において信頼ベースのモデルは根本的に破綻していると主張し、AURの完全な閉鎖を求める声も上がりました 。
• サードパーティの対応: Sonatype、Corgea、Cloud Security Alliance (CSA)、TrueSecなどのセキュリティ企業は、詳細な分析レポート、IoC（Indicators of Compromise）、そしてユーザーが自身のシステムを監査するためのコミュニティ検出スクリプト（aur-malware-check など）を公開しました 。

対応における主要な摩擦点の一つは、公式のArchチームが影響を受けた全パッケージの単一かつ正規のリストを即座に公開しなかったことでした。このため、ユーザーはSafeDepやCorgeaといった第三者によるマニフェストに頼らざるを得ませんでした 。

Linuxエコシステムへの教訓

Atomic Arch攻撃は、ボランティアによるメンテナンスに依存する信頼ベースのコミュニティリポジトリが持つ構造的な弱点を露呈させました。

• 「孤立パッケージ」の罠はシステムリスク: 本人確認や必須のコードレビューなしに、誰でも放棄されたパッケージを即座に引き継ぎ、変更できる仕組みは、利便性の高い機能を、影響力の大きな攻撃ベクトルへと変貌させました 。
• ビルド時インジェクションは完全性チェックを回避する: 従来の防御メカニズムは、ソースコードのtarballの整合性検証に依存しています。Atomic Archはソースコードではなくビルドスクリプトを汚染したため、標準のチェックサムは全く役に立ちませんでした 。
• エコシステムを跨ぐサプライチェーンが新たなフロンティア: この攻撃は、npmとBunのレジストリを武器化してLinuxエコシステムにマルウェアを配布しました。これは、ある一つのレジストリで侵害されたパッケージが、プラットフォームを超えて連鎖的な影響を及ぼしうることを証明しています 。

影響を受けたユーザーが今すぐ取るべき対応

セキュリティ研究者とArchコミュニティのガイダンスは一致しています。これは、単一のパッケージを削除するだけでは不十分なケースです。

1. 完全な侵害を前提とする: 2026年6月9日から12日の間にAURパッケージをビルドまたはアップデートしたホストは、完全に侵害されているとみなしてください 。
2. クリーンメディアから再インストール: 単純なマルウェアスキャンは信頼できません。eBPFルートキットが検出ツールから隠蔽するように設計されているからです。唯一保証された対策は、影響を受けたシステムを信頼できるインストールメディアから再構築することです 。
3. 全認証情報を直ちにローテーション: 認証情報スティーラーは、マシン上でアクセス可能なあらゆる秘密情報、すなわちSSHキー、GitHubトークンとnpmトークン、Vaultトークン、クラウドアクセスキー、ブラウザセッション、Docker/Podman認証情報を窃取したと考えてください 。
4. AURの履歴を監査:

   pacman -Qm

   コマンドを実行し、システムにインストールされている公式リポジトリ外のパッケージをリストアップし、コミュニティが公開している悪意あるパッケージのマニフェストと照合してください 。
5. 侵害の痕跡を調査: atomic-lockfile、lockfile-js、js-digestといった痕跡がビルドキャッシュにないか、また /sys/fs/bpf/ 配下に不審なエントリがないかを検索してください 。
6. 本件をインシデント対応事案として扱う: 組織は、これを単なるスキャン作業と捉えるべきではありません。攻撃発生期間中にAURからパッケージを取得したArch開発者のワークステーションやCI/ビルドサーバーはすべて、完全な対応を要するセキュリティインシデントとして扱う必要があります 。