2026年6月11日、Arch User Repository（AUR）で放置パッケージの悪意ある引き取りが相次ぎ、PKGBUILDやインストールスクリプトにマルウェアが注入された。
報告では、第1波に krisztinavarga、第2波に custodiatovar や veramagalhaes といったアカウントが関与したとされる。当初は arojas というユーザー名が関与したと報じられたが、Arch LinuxのTrusted User（David Runge氏）は、これはgitコミットの偽造による正規メンテナーへのなりすましであり、当該アカウント自体は侵害されていないと明らかにした。Sonatypeはこのキャンペーンを「Atomic Arch」と命名し、Sonatype-2026-003775、CVSSスコア8.7として報告した。侵害パッケージは当初408個、その後900個超と報じられ、Sonatypeは暫定的に約1500個に達した可能性があるとした。攻撃にはnpmパッケージ atomic-lockfile（バージョン1.4.2）と js-digest が用いられた。preinstallフックでRust製ELFバイナリ deps（3,040,376バイト）を実行し、第2波ではハッシュの異なる別のELFが使われた。depsはSSHキー、GitHubトークン、npm認証情報、ブラウザのCookieなどを窃取し、CAP_BPF保有時にeBPFルートキットを読み込んでプロセスとソケットを隠蔽し、Tor onionサービスへC2通信を行う。
【編集部解説】
「Atomic Arch」と名づけられたこの事件は、一見するとよくある「マルウェア入りパッケージが見つかった」というニュースに見えます。しかし本質は別のところにあります。攻撃者は、信頼を新たに作り出したのではなく、すでにある信頼を「相続」したのです。ここに、私たちが今これを報じる理由があります。
まず、攻撃の起点となったAURの仕組みを押さえておきましょう。Arch User Repository（AUR）は、Arch Linuxの公式リポジトリにないソフトを、有志がビルド手順書（PKGBUILD）の形で共有する場です。利用者やyay・paruといった補助ツールは、このPKGBUILDを取得し、自分のマシン上でビルド・インストールします。つまり手順書の中の命令は、利用者のマシンで直接実行されます。ここがWindowsのアプリストアなどとは決定的に違う点です。
そのAURには「orphan（放置）パッケージの引き取り」という制度があります。メンテナーが管理を手放したパッケージは、別の誰かが名乗り出て引き継げます。良心的なユーザーが有用なソフトを延命させるための、本来は健全な仕組みです。攻撃者はこの引き取りを自動化し、信頼と利用実績だけを残したまま、中身の管理権だけを奪い取りました。Sonatypeはこの構図を、タイポスクワッティング（打ち間違いを突く手口）でもブランドジャッキング（知名度の悪用）でもなく、「所有権の悪用」と整理しています。利用者から見れば、いつものパッケージをいつものように更新しているだけ。そこが恐ろしいのです。
混入したマルウェアの正体は、Rust製のLinux向け認証情報窃取プログラム「deps」です。SSHキー、GitHub・npm・HashiCorp Vaultのトークン、Docker/Podman、ブラウザのCookie、SlackやTeams・Discordといった業務ツールの認証情報まで、開発者のマシンに眠る秘密を網羅的に狙います。一般ユーザーのPCではなく、開発者やCI/ビルド環境を標的に設計されている点が、この攻撃の戦略性を物語っています。開発者の鍵束は、その先にある本番環境やクラウド、ひいては所属企業全体への入口になりうるからです。
ここで、私たちが各社報道を読み比べて気づいた重要な論点を共有します。今回の「目玉」とされたeBPFルートキット（カーネル内部に潜んで自身のプロセスやソケットを隠す機能）について、The Hacker Newsは「初期の記事はeBPFルートキットを過大に喧伝した（oversold）」と整理しています。実際、最初に技術解析を行った独立研究者Whanosの報告（ioctl.fail）でも、この機能は「root権限がある場合に限る任意の（optional root-only）」ものと位置づけられています。元記事は「あなたには見えない」と劇的に描写していますが、解析は静的（コードを読んだだけで、稼働中の挙動を確認したわけではない）であり、しかもこの機能は実行時にroot権限がある場合に限って起動する条件付きのものです。脅威を軽視する必要はありませんが、「すべてのArchユーザーが透明なルートキットに侵されている」という像は正確ではありません。innovaTopiaとしては、ここは冷静に線を引いておきます。
なお元記事の元になったioctl.failのレポート自体、執筆者が「AIツールのCodexで急いで書き、IDAの逆コンパイル結果と照合した」と但し書きしている点も付記しておきます。一次情報であっても、生成AIを介した速報には検証の余地が残る——これは私たち自身の生成AI使用ポリシーとも重なる教訓です。
被害規模の数字にも注意が必要です。各社で数字が割れており、報道を整理すると次のようになります。CyberSec Guruは「当初408、執筆時900超、追記で約1500」と段階的に報じ、The Hacker NewsやBleepingComputerは「400超」、byteiotaは「408」、PrivacyGuidesは「約1500」としています。一方、一次情報であるSonatypeのブログは、当初の確認規模を「数十パッケージ程度」と表現しており、これをBleepingComputerは「少なくとも20の放置パッケージ」と報じています。1500という数字についてSonatypeは「複数の攻撃の波を合わせて計約1500に達した可能性がある（暫定）」と慎重に記しています。つまり「1500」はSonatypeが断定した確定値ではなく、コミュニティ集計を含む暫定的な上限です。数字が独り歩きしやすい局面なので、innovaTopiaは「確認済みの規模」と「報告ベースの規模」を分けて読むことをおすすめします。
感染の手口にも、報道間でひとつ食い違いがあります。同時に呼び出されるパッケージ名について、CyberSec Guruは「axios got」、Sonatypeは「minimist chalk」と記しており、細部が一致していません。攻撃の波や検体によって差がある可能性があり、現時点では一次情報であるSonatype表記を基準に読むのが無難でしょう。また第2波では、npmに加えてBunというツールを使う経路が現れ、悪意あるパッケージとして js-digest・lockfile-js も確認されています（Sonatype）。第2波のペイロードはハッシュの異なる別のELFで、別のアカウント群から配布されたとも報じられており、npm install atomic-lockfile を手がかりにした検知をずらす狙いとみられます。
なお、行為主体についても断定は避けるべきです。当初は単独のarojasによる犯行と報じられましたが、前述のとおりarojasはなりすまされた被害者でした。報告ベースでは、第1波のkrisztinavarga、第2波のcustodiatovar・veramagalhaesといった複数アカウントが関与したとされ、Sonatypeは人数を明言していません。単一の人物とは限らず、複数アカウントを束ねた作戦とみるのが、現時点では妥当な読み方です。
影響範囲についても、過度な不安と油断の両方を戒めたいところです。直接の影響を受けるのはArch系ディストリビューションでAURを使うユーザーに限られます。RHELやDebian、Windows、macOSをそのまま使っている分には、このパッケージ群が降ってくることはありません。ただし、macOSのHomebrewなど他のパッケージエコシステムでも、保守者・レビュー・信頼モデルをめぐる供給網リスクは重要な論点です。問題はArch固有の不注意ではなく、ボランティアの信頼に支えられたエコシステム全体に通底する設計課題なのです。
ではこの事件は、規制や仕組みに何を迫るのでしょうか。コミュニティはすでに、所有者が最近変わったパッケージへの警告表示、アカウント管理の厳格化、AURヘルパー内でのメンテナー履歴の可視化といった改善を求めています。SBOM（ソフトウェア部品表）やパッケージ署名の義務化を進める各国の動きとも響き合う論点で、「誰がいつ管理権を握ったか」という来歴情報をいかにユーザーへ届けるかが、次の標準になっていくと考えられます。
長期的に見れば、Atomic Archは「信頼の継承」という新しい攻撃面を可視化した事例として記憶されるでしょう。ソフトウェアの世界が、これからも無償の有志に支えられて回っていく以上、管理権の移転は今後ますます狙われます。利便性と安全性のどちらを取るかという二者択一ではなく、「便利さを保ったまま来歴を透明にする」設計をいかに織り込むか。そこにこそ、Tech for Human Evolutionを掲げる私たちが注目すべき進化の余地があります。
【用語解説】
AUR（Arch User Repository）
Arch Linuxの公式リポジトリに含まれないソフトを、有志がビルド手順書（PKGBUILD）の形で共有するコミュニティ運営の場である。プレビルド済みのバイナリではなく「作り方のレシピ」が置かれており、利用者は自分のマシン上でビルドして導入する。公式サイトは下記【参考リンク】を参照。
PKGBUILD
AURで配布されるビルド手順書のことである。ソフトの取得元、コンパイル方法、インストール手順をBashスクリプトとして記述したもので、利用者のマシン上でそのまま実行される。今回はこのファイルが書き換えられ、攻撃の起点となった。
orphan（放置）パッケージの引き取り
メンテナーが管理を手放したパッケージを、別のAURアカウントが名乗り出て引き継げる制度である。本来は有用なソフトを延命させるための仕組みだが、信頼と利用実績を残したまま管理権だけが移るため、今回悪用された。
AURヘルパー（yay／paru）
AURからのパッケージ取得・ビルド・インストールを自動化する補助ツールである。makepkgを手動で叩く手間を省く反面、PKGBUILDの中身を確認しないまま実行してしまいやすい側面もある。
preinstall／postinstall フック（npmライフサイクルスクリプト）
npmがパッケージのインストール前後に自動実行する処理のことである。--ignore-scripts で抑制しない限り利用者の操作なしに走るため、悪意あるコードの自動実行口として使われた。
Bun
JavaScript/TypeScript向けの高速なランタイム兼パッケージ管理ツールである。第2波ではnpmの代わりにこのBunを使う経路が現れ、npmを手がかりにした検知をずらす狙いがあったとみられる。
ELFバイナリ
Linuxで標準的に使われる実行ファイルの形式である。今回の本体「deps」はRust言語で書かれ、シンボル情報を取り除いた（ストリップした）約3MBのELFファイルとして配布された。
eBPF（extended Berkeley Packet Filter）
プログラムをカーネル（OSの中枢）の内部で特権付きで動かせるLinuxの技術である。本来は通信監視や性能計測などに使われる正当な仕組みだが、今回はプロセスやソケットをツールの目から隠す「ルートキット」的用途に転用されうると報告された。
ルートキット
侵入後に自身の存在を隠し、管理者にも気づかれにくくする一連の技術・ソフトの総称である。今回はps・netstatなどの標準ツールから自身を見えなくする機能が指摘されたが、稼働中の動作確認ではなく静的解析に基づく点に注意が必要である。
CAP_BPF / root権限
eBPF機能の起動に必要な、通常はroot（管理者）にのみ与えられる権限のことである。マルウェアはこの権限がある場合に限ってルートキット機能を起動する設計だった。
C2（指令・制御）／Tor onionサービス
感染端末に指示を送り、盗んだ情報を受け取る攻撃者側の通信拠点（Command and Control）を指す。今回はTorの匿名ネットワーク上の秘匿サービス（.onionアドレス）が使われ、停止措置への耐性を高めていた。
CVSSスコア
脆弱性や脅威の深刻度を0〜10で示す共通指標である。今回Sonatypeは「8.7」と評価しており、これは高い深刻度に位置づけられる。
SBOM（ソフトウェア部品表）
ソフトが内部でどの部品（ライブラリ等）を使っているかを一覧化した「成分表」である。【編集部解説】で触れた「来歴の透明化」を支える仕組みとして、各国で導入が進む。
Sonatype
今回の攻撃を「Atomic Arch」と命名し、初期調査を行ったソフトウェアサプライチェーン管理企業である。公式サイトは下記【参考リンク】を参照。
【参考リンク】
Arch User Repository（AUR）公式（外部）
今回の攻撃の舞台となったコミュニティリポジトリの公式サイト。パッケージ検索やPKGBUILDの閲覧ができる。
ArchWiki「Arch User Repository」（外部）
AURの仕組みや導入手順、注意点を解説する公式コミュニティの文書。PKGBUILD確認を推奨している。
Arch Linux 公式（外部）
AURの母体となるLinuxディストリビューションの公式サイト。導入や設定の情報を提供する。
Sonatype（ソナタイプ）公式（外部）
攻撃を「Atomic Arch」と命名し初期調査を公開した企業の公式サイト。供給網セキュリティ製品を扱う。
npm 公式（外部）
攻撃に悪用されたJavaScriptパッケージレジストリの公式サイト。パッケージの検索や公開ができる。
Bun 公式（外部）
第2波で悪用されたJavaScript/TypeScriptランタイム兼パッケージ管理ツールの公式サイト。
Tor Project 公式（外部）
C2通信に使われた匿名ネットワークTorを開発・運営する非営利団体の公式サイト。
【参考記事】
Atomic Arch: Attackers Hijack Trusted AUR Packages to Deliver Rootkit-Like Malware（Sonatype）（外部）
本件の一次情報。攻撃の手口、当初の確認規模、第2波のBun経路、CVSS 8.7を報告。「所有権の悪用」という整理を提示した。
Preliminary analysis of AUR malware（ioctl.fail／Whanos）（外部）
depsバイナリを逆解析した技術的な一次レポート。eBPF機能を「root権限がある場合に限る任意の機能」と位置づけ、静的解析に基づく点も明記している。
Over 400 Arch Linux packages compromised to push rootkit, infostealer（BleepingComputer）（外部）
Sonatypeが「少なくとも20件」を確認と報道。手口でのパッケージ名の差異を確認する上で重要。
AUR Malware Hits 408 Packages with eBPF Rootkit—Act Now（byteiota）（外部）
当初「6月11日にarojasが408個を引き取った」と報じたが、arojasは後になりすましと判明。getdents64()フックなどeBPFの挙動も説明している。
Around 1,500 AUR Packages Compromised with “Rootkit-Like” Malware（Privacy Guides）（外部）
約1500パッケージが侵害されたと報道。最大規模の数字を伝えた記事として対比に用いた。
400+ AUR Packages Hijacked: What the “Atomic Arch” Campaign Means for Supply-Chain Security（StepSecurity）（外部）
AUR事案を、パッケージエコシステム全体の信頼モデルや保守者管理の問題として位置づける記事。影響範囲を広げる視点を補った。
【編集部後記】
今回の一件で、ふと考え込んでしまいました。私たちは毎日、誰かが無償で積み上げてくれた「信頼」の上で、便利なソフトを使わせてもらっているのだなと。その信頼は、所有者が変わった瞬間にそっと別物になりうる——そう知っておくだけで、見える景色が少し変わる気がします。みなさんは、自分の手元の道具が「いつ・誰の手で」作られているか、確かめたことはありますか。よければ感じたことを聞かせてください。私たちも一緒に考えていきたいです。