## 更新履歴
| 日付 | 内容 |
|---|---|
| 2026-06-15 | 初版作成 |
---
## 背景
2026年6月、 Arch Linux (Linux ディストリビューション) の AUR (Arch User Repository - Arch ユーザーのためのリポジトリ) において、1000件を超える AUR パッケージがマルウェアの影響を受けたとネット上のメディアで報じられた。これは、"Atomic Arch" と呼ばれるものである。
これをふまえ、以下の点で事実収集・考察を行い、まとめたものである。
- "Atomic Arch" の概要レベルでの事実収集
- 「どうしてこうなった」のか
- Arch Linux 利用者側で、どうすれば防ぐことができたか
> **調査方法**
> 本稿は一次情報（Sonatype 公式ブログ、npm registry のメタデータ、Arch Linux メーリングリスト〔aur-general〕の原文、ArchWiki、コミュニティが公開した横断検知リストの原本）を優先的に直接参照し、報道・解説記事などの二次情報は複数ソースで相互に裏付けたうえで用いた。確認された事実と、筆者の推測・分析・提言は、本文中で「（事実）」「（解釈）」「仮説（要検証）」等として明示的に区別している。本稿の限界については末尾の「調査上の制約」を参照されたい。
> **【筆者注記】利害関係の開示**
> 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。
> 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。
> **本記事の作成プロセス**
> 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。
---
## 概要
| 項目 | 内容 |
|---|---|
| 事象名 | Atomic Arch（Sonatype 命名）[^1] |
| 対象 | Arch User Repository（AUR）のユーザー投稿パッケージ |
| 発覚日 | 2026-06-11 |
| 攻撃種別 | サプライチェーン攻撃（孤児パッケージ乗っ取り → 悪性依存注入） |
| 追跡番号 | Sonatype-2026-003775（CVSS 8.7）[^1] |
| 影響規模 | 最終リスト 1,579 件（「全てではない」と注記）[^14][^2] |
| 公式リポジトリへの影響 | なし（被害は AUR 利用者に限定）[^3] |
> **注**：本件に CVE は割り当てられていない（2026-06-13 時点）。Sonatype は独自参照番号で追跡している。[^1]
---
## 攻撃の概要（事実）
攻撃者は、元のメンテナが手放した「孤児化（orphaned / disowned）パッケージ」を、AUR の正規の引継ぎ（adoption）プロセスで乗っ取った。[^1] その後、パッケージ本体ではなく**ビルド指示**（`PKGBUILD` / `.install` / `.hook`）を改変し、ビルド時に悪性 npm パッケージ（`atomic-lockfile` ほか）を取得・実行させた。[^4]
パッケージ本体を変えずビルド指示だけを変える点が要点で、これにより従来型のマルウェア検知（パッケージ署名・内容比較）を回避している。[^5]
一部のパッケージでは、攻撃者が **Git コミットの author / committer メタデータ**——Git が認証しない自己申告のテキストフィールド——を詐称し、正規メンテナ（例：arojas）になりすました。AUR のリポジトリやサーバーが侵害されたわけではなく、push は攻撃者自身の正規アカウントで行われ、コミット内の「作者」表示のみを別人名にした手口である（`git commit --author` 等で誰でも任意の名前・メールを名乗れる）。この挙動は AUR 公式ガイドライン自身が明記しており、「コミットは push 者の global な Git 名・メールで author 付けされる」「別の資格情報で AUR に push したい場合は `git config user.name` / `user.email` をパッケージ単位で変更できる」と案内されている。[^20] 実際、rtspeccy-git の報告者 movq は、攻撃者が元作者の本名を Git コミットに流用し続けている点を指摘している。[^9] Arch 開発者 David Runge は後に「arojas はコミット偽造によるなりすましの被害者であり、悪意あるメンテナではない」と明確化している。[^2]
### 補足：AUR の引継ぎ（adoption）とは（事実）
adoption は AUR のメンテナ引き継ぎの正式な仕組みであり、本攻撃の成立を理解する鍵となる。
1. **放棄（disown）**：メンテナが AUR の web インターフェース（および／または AUR メーリングリストへの投稿）で保守をやめる。あるパッケージの全メンテナが放棄すると、そのパッケージは「orphaned（孤児）」状態になる。[^18]
2. **引き取り（adopt）**：孤児化した（または保守されていない・メンテナが非応答の）パッケージは、別の利用者が adopt（引き取り）でき、引き取った者がそのまま新メンテナとなり PKGBUILD の更新権限を得る。AUR の PKGBUILD は公式に「十分に精査されておらず、利用は自己責任」と明記されている。[^19]
3. **非応答メンテナの場合**：「orphan request（孤児化要請）」を出すと、現メンテナが2週間反応しなければ承認される。out-of-date フラグが180日以上立っているパッケージは、孤児化要請が自動承認される。[^18]
**急所（事実）**：孤児パッケージの adoption には人的な審査・承認・投票がない。AUR アカウントさえあれば、ワンクリックでメンテナ権限が移る。Package Maintainer（Arch スタッフ）の承認が要るのは公式リポジトリ（extra）への昇格の場面であって、AUR 内の孤児引き取りは利用者の自己申告で完結する。[^18]
**解釈**：この「ゲートキーパー不在の引き継ぎ」が、本キャンペーンがルール違反なしにスケールした構造的理由である。攻撃者は孤児パッケージを正規手順で次々と adopt できた。なお、adoption（空席に正規手順で座る）と、前述のコミット偽造によるなりすまし（在席者になりすます）は性質が異なる悪用であり、本件では両者が混在していた。
---
## ペイロードの実態（事実）
- **窃取対象**：Discord トークン、GitHub PAT、npm トークン、SSH 鍵、ブラウザ Cookie 等。[^2]
- **持ち出し（exfiltration）**：temp.sh へのアップロードおよび Tor onion サービス経由の C2。[^2]
- **永続化**：systemd サービス（`Restart=always`）。[^2]
- **ルートキット様挙動**：root かつ CAP_BPF で動作する場合、`scales.bpf.c` を読み込み、eBPF によりプロセス・ファイル・ソケットを隠蔽。アンチデバッグ機能も具備。[^6]
- **配信元の同一性**：`atomic-lockfile` と `js-digest` は同一 npm パブリッシャ（herbsobering）が公開。[^7]
- **配信元の現状（事実）**：悪性版 `atomic-lockfile` v1.4.2 は 2026-06-10 15:05 UTC に npm registry へ公開され、2026-06-12 11:39 UTC に npm 側が security holding package（`0.0.1-security`、説明文 "security holding package"）へ差し替えて削除。registry 上のメンテナ登録も除去されている。[^22]
---
## 攻撃段階（サイバーキルチェーンとしての整理）
> 本件はサプライチェーン型のため、古典的 Cyber Kill Chain と異なり **Delivery（配送）以降の主語が「攻撃者」から「利用者」へ移る**。攻撃者は供給物に毒を仕込むだけで、運搬・実行は利用者がビルドで肩代わりする。そこで本節は **攻撃者フェーズ／利用者フェーズ** の2部に分けて整理する。後続の対策検討で「どの継ぎ目に介入できるか」を見るための土台とする。
### 攻撃者フェーズ（事実）
| # | 行為 | 古典キルチェーン対応 | 出典 |
|---|---|---|---|
| A-1 | 悪性 npm パッケージ（`atomic-lockfile` ほか）を準備し npm registry へ公開（v1.4.2 を 2026-06-10 公開、パブリッシャ herbsobering）。第2波では Bun 経路用に `js-digest` も併用 | Weaponization | [^7][^22] |
| A-2 | AUR の引継ぎ（adoption）プロセスで多数の孤児パッケージの正規メンテナ権を取得。一部は disown 直後の隙に別アカウントが所有権を奪取。**いずれも「空席に座る」型**で、人的審査・承認・投票はない | （供給元の汚染：古典モデルに対応物なし） | [^1][^15][^18] |
| A-3 | 取得したパッケージの **ビルド指示**（`PKGBUILD` / `.install` / `.hook`）を改変し、ビルド時に悪性パッケージを `npm install`（第1波）／ `bun install`（第2波）で取得・実行させる。パッケージ本体・署名は変えないため内容比較・署名検証を回避 | Weaponization（仕掛けの埋込） | [^4][^5][^8] |
| A-4 | **（一部のパッケージのみ）** コミットの author / committer（Git が認証しない自己申告フィールド）を元メンテナ名・メールに詐称し、来歴を偽装。push 自体は攻撃者の正規アカウントで実施＝権限取得ではなく**痕跡の隠蔽レイヤー** | （隠蔽：Defense Evasion 寄り） | [^9][^20] |
> A-2〜A-4 は **波状**に展開された（第1波＝npm、検知・削除開始後の第2波＝Bun）。「攻撃準備完了」は一度きりの点ではなく、対応の進行に重なって再投入された。
**――― 攻撃者フェーズ完了／以降は利用者の操作が起点 ―――**
### 利用者フェーズ（事実）
| # | 行為 | 古典キルチェーン対応 | 出典 |
|---|---|---|---|
| U-1 | 利用者が AUR helper（`yay` / `paru` 等）で対象パッケージを取得・ビルド。helper は `PKGBUILD` を提示するが、そこから引かれる外部依存の中身までは目視審査が届かない | Delivery（**主語＝利用者**） | [^5][^15] |
| U-2 | ビルド時に悪性 npm / Bun パッケージが取得・実行される | Exploitation / Installation | [^4][^5] |
| U-3 | マルウェアが活動：**窃取**（Discord トークン・GitHub PAT・npm トークン・SSH 鍵・ブラウザ Cookie）→ **持ち出し**（temp.sh・Tor onion C2）→ **永続化**（systemd `Restart=always`）→ **隠蔽**（root かつ CAP_BPF 時に eBPF でプロセス・ファイル・ソケットを秘匿、アンチデバッグ具備） | C2 / Actions on Objectives | [^2][^6] |
### 対策検討に向けた継ぎ目（解釈）
この段階整理から、介入余地のある「継ぎ目」が読み取れる（いずれも解釈であり、適用可否は別途検証を要する）。
- **A-2 の急所**：引継ぎに人的ゲートキーパーが不在。ここが本キャンペーンが規模化できた構造的理由であり、最上流の介入点。
- **A-3／U-1 の死角**：審査の目が `PKGBUILD` 本体までしか届かず、外部依存（npm/Bun）の中身に及ばない。「適度な非効率＝継ぎ目」が機能すべき箇所の死角。
- **U-1 の主語転換**：配送を利用者自身が肩代わりする構造。利用者側のビルド環境（ネットワーク隔離・依存固定・ビルドサンドボックス）が事実上の最終防壁になる。
- **A-4 の限界**：来歴偽装は author 表示のみで、push 元アカウントや署名までは詐称していない。**「誰が書いたか」を author 表示で判断する慣行**の脆さを示す一方、コミット署名・push 元の検証が識別の手がかりになりうる。
---
## 主な時系列（一次情報で確認できる範囲）
> メーリングリスト記載の時刻はタイムゾーン明記がないため、相対順序の根拠として扱う。Phoronix 記事は EDT、npm registry は UTC、gr.ht リストは PDT 明記。
| 日時 | 事象 | 出典 |
|---|---|---|
| 2026-06-10 15:05 UTC | 悪性 npm パッケージ `atomic-lockfile` v1.4.2 が npm registry に公開（AUR 側から取得・実行される版） | [^22] |
| 2026-06-11 13:50 | `gnome-randr-rust`：新メンテナが install ファイルに `npm install atomic-lockfile yargs` を追加と報告 | [^8] |
| 2026-06-11 14:04 | `rtspeccy-git`：孤児パッケージが引き継がれ atomic-lockfile・chalk・minimist を導入。元作者の本名を Git コミットに流用と報告 | [^9] |
| 2026-06-11 15:11 | `pypiserver` ほか：前日に disown 直後、別アカウントが所有権取得・なりすましコミット。atomic-lockfile が Telegram の tdata 等を参照する情報窃取と推定、と詳細報告 | [^10] |
| 2026-06-11 15:32 | `zathura-gruvbox-git` 等：複数アカウントによる悪性更新を一括報告 | [^11] |
| 2026-06-11 16:19 | `alvr`：新メンテナがnpm パッケージを追加、旧メンテナのメールを自分のものに差し替えと報告 | [^12] |
| 2026-06-11 17:47 | Arch 開発者が「AUR REPORT THREAD」を開設。悪性コミットの reset/削除とアカウント BAN を開始、追加発見の集約を呼びかけ | [^13] |
| 2026-06-11（同日） | Sonatype が本件を Atomic Arch として追跡開始（Sonatype-2026-003775, CVSS 8.7） | [^1] |
| 2026-06-12 06:39 EDT | Phoronix が「400+ パッケージ」と報道 | [^3] |
| 2026-06-12 07:36 PDT | gr.ht 上に横断検知リストが公開。`git log --all -S 'bun add'`／`-S atomic-lockfile` で全 AUR を走査した影響コミット一覧（数百件規模） | [^21] |
| 2026-06-12 11:39 UTC | npm が `atomic-lockfile` を security holding package（`0.0.1-security`）へ差し替え＝takedown。メンテナ登録も削除 | [^22] |
| 2026-06-12（日中） | 第2波出現。Bun ベースの導入経路（`bun install js-digest`）を併用。累計で約900件に拡大（第2波単独の規模ではない） | [^1][^7] |
| 2026-06-12（日中） | David Runge が arojas はコミット偽造によるなりすましと明確化 | [^2] |
| 2026-06-12 20:55 EDT | 開発者が把握分の悪性コミットを全削除と報告。影響リスト 1,579 件（「多くを含むが全部ではない」） | [^2][^14] |
---
## 「どうしてこうなったのか」（構造的要因）
### 事実
攻撃が成立した直接の理由は、AUR が「**いま誰が保守しているか**」より「**パッケージの名前と履歴**」を信頼する設計にある。[^15] 孤児パッケージは「何を書いたか」の履歴（=信頼）だけが残り、「誰が保守しているか」が空席になる。攻撃者はその空席に座り、なりすまし（名前流用・コミット偽造）で「誰が」の疑念すら消した。同種の引継ぎ手口は 2018 年の PDF ビューアパッケージでも確認されており、2026 年版はそれを規模拡大したものである。[^15]
### 解釈
実改竄が `PKGBUILD` 本体ではなく「ビルド時に取得される外部依存（npm / Bun）」側に置かれた点が、検知回避の核心である。[^5] AUR helper（yay / paru）が install 前に `PKGBUILD` を表示する仕組みはあっても、そこから引かれる外部依存の中身までは利用者の目視審査が届かない。これは「適度な非効率＝継ぎ目」が機能すべき箇所に死角があったと整理できる。
この事象は「コード原理主義の脆弱性」——「誰が書いたか」より「何を書いたか」を重視する OSS 文化——が、そのまま攻撃面として顕在化した一例とみなせる。
なお事後の一斉検知は、この外部依存の痕跡——`bun add`／`atomic-lockfile` という導入命令の文字列——を AUR 全リポジトリの git 履歴に対し `git log -S` で横断 grep することで成立した。[^21] 攻撃が「ビルド指示への文字列追加」という単純な改変であったことが、結果的に検知シグネチャの明確さにつながっている（解釈）。この横断検知リストは、開発者把握分の 1,579 件リスト（[^2][^14]）とは別系統・別時点（2026-06-12 07:36 PDT 生成）の独立した部分集合であり、相互の照合材料になる。
### 仮説（要検証）
preinstall で埋め込みバイナリを実行する手口は、別キャンペーン IronWorm の `atomic-notes` と類似する。ただし Sonatype は両者の関連を確認していない。[^16] 同一犯か模倣かは現時点で未確定である。
---
## 対策検討（どうすれば防ぐことができたか）
> 本章は「どうすれば防げたか／防げるか」を、前掲「攻撃段階」の各層に対応づけて検討する。記述は提言＝**解釈**であり、各環境での適用可否は別途検証を要する。本稿では、**現時点の Arch／AUR の仕組みで利用者側にできること** を扱う。
### 利用者側にできること
#### 前提：利用者の介在点と「効きを誤認しやすい点」（事実＋解釈）
攻撃段階で利用者が介在できるのは U-1（取得・ビルド）以降である。ここで射程を誤りやすいのが makepkg の root 実行禁止（[^23]）。これは PKGBUILD の任意コードからシステム全体（/usr・/etc・他ユーザ・カーネル）を守る設計であって、**実行ユーザ自身のホーム配下で完結する情報窃取——`~/.ssh` の鍵、各種トークン、ブラウザ Cookie——には効かない**。攻撃コードはビルドユーザ権限で走り、そのユーザは自分の機密に到達できるからである。root かつ CAP_BPF を要する eBPF 隠蔽（U-3）のみ通常ビルドで不発化するが、これは「予防」ではなく「隠蔽されない＝事後に気づける」という検知性の改善にとどまる。**本件の主目的である窃取は、標準的な yay／paru ビルドでは止まらなかった。**
| 攻撃段階 | 利用者側の対策 | 効く層 |
|---|---|---|
| A-2（引継ぎ直後・公開直後） | AUR 最小化（必要なものに絞る） | 確率低減 |
| U-1 取得・ビルド | PKGBUILD・`.install` の差分確認 | 検知（限定的） |
| U-2 ビルド時実行 | 隔離ビルド（clean chroot 等） | 被害局限 |
| U-3 窃取・持出・永続化・隠蔽 | 機密を隔離外に置く／egress 制限／非 root（隠蔽のみ不発） | 被害局限 |
#### 第一の層：AUR 利用の最小化（被害に遭う確率を下げる）
公式リポジトリ（core／extra）・Flatpak・信頼できる配布元で代替できるものは AUR を使わず、AUR は「**必要かつ、最悪は利用者自身がフォーク・固定・代替に動けるもの**」に絞る。AUR には保守者が誰であるかを問う枠組み自体がなく（アカウントと個人、前任と後任、コミットの author 表示と push 元アカウント——いずれも紐付けられていない）、「保守者を信頼する手法」が存在しない。よって、利用者は、信頼の所在を、他者から自分が対処に動ける範囲へ移すほかない。AUR の PKGBUILD は公式に「精査されない・自己責任」とされている（[^19]）。この層は被害の母数そのものを縮める（解釈）。
#### 第二の層：隔離ビルド（被害を局限する）
clean chroot（devtools の `makechrootpkg`）、専用ビルドユーザ、コンテナのいずれかでビルドする。ArchWiki も clean chroot ビルドを推奨している（[^25]）。効果の技術的根拠は、`makechrootpkg` では chroot 内で `~`／`$HOME` が `/root/` に解決され、母艦ユーザのホーム（鍵・トークン・Cookie）が chroot 内から見えない点にある（[^24]）。ゆえに U-2 で悪性 postinstall が走っても、窃取対象に到達できず空振りになりうる。守るべきは特権昇格ではなく**機密データへの到達経路**であり、効果の前提は「窃取対象を隔離の外に置いたままビルドする」運用である（解釈）。**あくまで本件に限れば、隔離ビルドは窃取防御として効果的だった**と評価できる。ただしそれは、(1) 窃取対象が母艦ホームの平文資産（鍵・トークン・Cookie）であり、(2) 窃取が「ビルド時実行」（U-2）を起点とし、(3) 隔離環境にそれらの機密が無い——という三条件が揃った「隔離が最も効く型」だったことによる。窃取が成果物本体に仕込まれ `pacman -U` 後に動く型や、隔離内に機密を置く運用では同じ効果は得られない（解釈）。
#### 隔離層の限界（過信しないために）（事実＋解釈）
1. **隔離内に機密があれば窃取される**。CI トークンやデプロイ鍵をビルド環境に置けば、chroot でも持ち出される。隔離の価値は「何を隔離の外に出しておくか」の運用とセット。
2. **生成物は最終的に母艦へ入る**。隔離はビルド時実行（U-2）を封じるが、ビルド済みパッケージ本体に毒が仕込まれていれば `pacman -U` で母艦に入る。本件は「ビルド時の外部取得・実行」起点なので隔離が効くが、「本体に毒」型には U-1 の検知や最小化が別途要る。
3. **egress は別問題**。隔離は窃取の「読み取り」を絞るが、隔離環境からの持ち出し通信（temp.sh／Tor）を止めるにはビルド環境のネットワーク制限が別途要る。AUR ビルドは外部ソース取得で通信を要するものが多く、完全遮断は副作用が大きい。
#### 小結（解釈）
利用者側の実効策は「最小化（確率を下げる層）」と「隔離ビルド（被害を局限する層）」の二層に集約され、どちらも単独では完結しない。最小化をすり抜けた毒入りパッケージを引いても隔離が窃取を空振りさせ、隔離内に残した機密は最小化と運用で守る。各層が自工程で守りつつ、突破されても全体として粘る——本件で利用者が取りうる構えは、この二層の併用に尽きる。
---
## 利用者側の対応（報道ベース・参考）
- 2026 年 6 月前後に AUR パッケージをインストール／更新した利用者は、システムを点検すべきとされる。[^17]
- 最近引き継がれたパッケージ、または突然 install フックが追加されたパッケージは、見知らぬ第三者のパッケージと同等に疑うべき、との指摘がある。[^15]
- 感染が疑われる場合は電源を落とさず、信頼できる媒体でのフォレンジック取得が推奨されている。[^7]
> 上記は外部報道・コミュニティ資料の記載であり、各環境での適用可否は別途検証を要する。
---
## 調査上の制約
本稿の記述には、以下の制約がある。
1. **件数は執筆時点のスナップショット**：影響を受けたパッケージ件数は、報道の推移の中で 400 件超 → 約 900 件 → 1,579 件 と増加し、最終的に「多くを含むが全部ではない」と注記されたリストで 1,579 件とされた（[^14][^2]）。本稿の件数は 2026-06-15 時点の報道に基づくものであり、調査の進行や追加発見により変動しうる。
2. **二次情報の性質**：本稿は一次情報を優先したが、一部の技術的詳細や経緯の把握には、個人運営のセキュリティブログやコミュニティが集約したリスト（[^2][^7] 等）も参照した。これらは可能な範囲で一次情報により裏付けたが、編集・査読体制が一次情報源と同等とは限らない点に留意されたい。
3. **時刻の扱い**：メーリングリスト掲載の時刻はタイムゾーンの明記がないため、本稿では絶対時刻ではなく相対的な前後関係の根拠として扱った（「主な時系列」節の注記参照）。一部スレッドの分単位の時刻は個別に突き合わせていない。
4. **対策検討の位置づけ**：「対策検討」章の評価・提言は、確認された事実を踏まえた筆者の解釈であり、各環境での適用可否・有効性は別途検証を要する。特に隔離ビルドの有効性評価は、本件の窃取手口に固有の前提（同章に明記した三条件）に依存する。
---
## 脚注
[^1]: Sonatype, "Atomic Arch: Attackers Hijack Trusted AUR Packages..." https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency (2026-06-15 閲覧)
[^2]: lenucksi/aur-malware-check（コミュニティ集約・タイムライン／IOC） https://github.com/lenucksi/aur-malware-check (2026-06-15 閲覧)
[^3]: Phoronix, "Arch Linux's AUR Sees More Than 400 Packages Compromised With Malware" https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised (2026-06-15 閲覧)
[^4]: StepSecurity, "400+ AUR Packages Hijacked: What the 'Atomic Arch' Campaign Means..." https://www.stepsecurity.io/blog/400-aur-packages-hijacked-atomic-arch-campaign (2026-06-15 閲覧)
[^5]: Privacy Guides, "Around 1,500 AUR Packages Compromised with 'Rootkit-Like' Malware" https://www.privacyguides.org/news/2026/06/12/around-1-500-aur-packages-compromised-with-rootkit-like-malware/ (2026-06-15 閲覧)
[^6]: Hackread, "Atomic Arch Campaign Hijacks 20+ Linux AUR Packages to Deliver Malware" https://hackread.com/atomic-arch-hijacks-linux-aur-packages-malware/ (2026-06-15 閲覧)
[^7]: The CyberSec Guru, "Atomic Arch: 900+ AUR Packages Backdoored with eBPF Rootkit" https://thecybersecguru.com/news/atomic-arch-aur-supply-chain-attack-ebpf-rootkit/ (2026-06-15 閲覧)
[^8]: Arch Linux aur-general, "Malicious update to gnome-randr-rust"（Mark Wagie, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/L2JXQNYBGWOQQQXDEPEAICBHKFEFANUC/ (2026-06-15 閲覧)
[^9]: Arch Linux aur-general, "Suspicious/malicious activity on rtspeccy-git"（movq, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/OKMAWCX73IH4HXUCBGUNAW3SQJ3H4OWE/ (2026-06-15 閲覧)
[^10]: Arch Linux aur-general, "Malicious commits: pypiserver, anythingllm-cli-bin, python-dbapi-compliance"（Ilaï Deutel, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/EAVGB55YBS4HRVU5N6NTYCGGMDDOJAM6/ (2026-06-15 閲覧)
[^11]: Arch Linux aur-general, "Malicious updates zathura-gruvbox-git, python2-mutagen, fastoggenc etc"（Fabio Loli, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/E5QPKBGL3QKLBOJ5HWUAS6AGZKHNTLG7/ (2026-06-15 閲覧)
[^12]: Arch Linux aur-general, "Suspicious/malicious update to alvr"（Kusoneko, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/2LGBF2AZBPVCCY4VTN6DOVUNNBURFJ2J/ (2026-06-15 閲覧)
[^13]: Arch Linux aur-general, "AUR REPORT THREAD"（Jonathan Grotelüschen, 2026-06-11） https://lists.archlinux.org/archives/list/
[email protected]/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/ (2026-06-15 閲覧)
[^14]: Phoronix, "Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages" https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500 (2026-06-15 閲覧)
[^15]: The Hacker News, "Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit" https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html (2026-06-15 閲覧)
[^16]: （[^7] に同じ）The CyberSec Guru, "Atomic Arch: 900+ AUR Packages Backdoored with eBPF Rootkit" https://thecybersecguru.com/news/atomic-arch-aur-supply-chain-attack-ebpf-rootkit/ (2026-06-15 閲覧)
[^17]: Tech2Geek, "Over 400 Arch Linux AUR Packages Compromised in 'Atomic Arch' Malware Campaign" https://www.tech2geek.net/over-400-arch-linux-aur-packages-compromised-in-atomic-arch-malware-campaign/ (2026-06-15 閲覧)
[^18]: ArchWiki, "AUR submission guidelines"（disown / orphaned / orphan request の規定。2週間ルール・180日自動承認を含む） https://wiki.archlinux.org/title/AUR_submission_guidelines (2026-06-15 閲覧)
[^19]: ArchWiki, "AUR submission guidelines"（AUR の PKGBUILD は "not been thoroughly vetted ... used at your own risk" と明示。unmaintained／非応答パッケージは adopt して更新できる旨の記載） https://wiki.archlinux.org/title/AUR_submission_guidelines (2026-06-15 閲覧)
[^20]: ArchWiki, "AUR submission guidelines" §Publishing new package content（コミットは push 者の global Git 名・メールで author 付けされ、`git config user.name` / `user.email` でパッケージ単位に変更可能と明記） https://wiki.archlinux.org/title/AUR_submission_guidelines (2026-06-15 閲覧)
[^21]: aur_pkg_list.txt（gr.ht 上で公開された横断検知リスト。ファイル冒頭に生成日時 `Fri Jun 12 07:36:44 AM PDT 2026` と抽出方法 `git log --all --since="7 days ago" -p -S 'bun add' --decorate=full` ／ `git log --all --since="48 hours ago" -p -S atomic-lockfile --decorate=full` を明記。影響コミットのハッシュとパッケージ名を列挙。gr.ht ドメインから sodiboo の作と目されるが、ファイル本文に著者名の明記はない） https://gr.ht/aur_pkg_list.txt (2026-06-15 閲覧)
[^22]: npm registry metadata, `atomic-lockfile`（悪性版 v1.4.2 公開 2026-06-10T15:05:45Z、security holding package `0.0.1-security` への差し替え 2026-06-12T11:39:55Z、メンテナ登録の除去を確認） https://registry.npmjs.org/atomic-lockfile (2026-06-15 閲覧)
[^23]: ArchWiki, "makepkg"（root での実行は禁止＝"Running makepkg itself as root is disallowed"。PKGBUILD は任意コードを含むため root でのビルドは不可） https://wiki.archlinux.org/title/Makepkg (2026-06-15 閲覧)
[^24]: ArchWiki, "DeveloperWiki:Building in a clean chroot"（`makechrootpkg` による clean chroot ビルド。chroot 内では `~`／`$HOME` が `/root/` に解決される旨を明記） https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot (2026-06-15 閲覧)
[^25]: ArchWiki, "Creating packages"（clean chroot でのビルドを推奨＝"It is recommended to follow Building in a clean chroot"） https://wiki.archlinux.org/title/Creating_packages (2026-06-15 閲覧)