背景

2026年6月、Arch Linux AURエコシステムで大規模なサプライチェーンポイズニングが発生し、Sonatypeはこの活動を「Atomic Arch」と名付けました。この事件は、Arch Linuxの公式リポジトリ、pacman、AURヘルパー、またはArch Linux自体にゼロデイ脆弱性が存在したわけではなく、攻撃者が長期間メンテナンスされていないがユーザーから信頼されているAURのオーファンパッケージの引き継ぎメカニズムを悪用し、合法的にこれらのパッケージを掌握してPKGBUILDやインストールスクリプトを改変したものです。

ユーザーが通常のAURインストールまたはアップグレード操作を実行すると、悪意のあるスクリプトがnpmまたはBunを呼び出し、攻撃者が制御するJavaScriptパッケージをインストールし、npmライフサイクルフックを利用してLinux ELFペイロードを実行します。このペイロードは主にLinux開発者ワークステーションおよびビルド環境を対象としており、GitHub、npm、SSH、Docker/Podman、Vault、ブラウザデータ、シェル履歴などの機密情報を窃取する機能を備えています。

公開開示段階において、影響を受けるAURパッケージの数は、当初の400以上から約1,500に拡大しました。このイベントは、オープンソースエコシステムにおける「メンテナンスされていないが依然として信頼されている」コンポーネントが、攻撃者によってスクリプト、パッケージマネージャーのライフサイクルフック、開発者のローカル環境を結びつける新たなサプライチェーン入口として利用されていることを示しています。

本文は、MistEyeが`runescape-launcher`、`atomic-lockfile@1.4.2`、および`js-digest@4.2.2`に対して実施した静的分析結果を基に、今回の攻撃チェーンの主要な技術的环节を整理したものである。上記のサンプルは、攻撃に用いられたすべてのサンプルではなく、攻撃パターンを明らかにするための技術的プロファイルである。

MistEye が応答しました

MistEyeは、SlowMistが自社開発したWeb3脅威インテリジェンスおよび動的セキュリティ監視システムで、セキュリティ監視とインテリジェンス集約機能を統合し、ユーザーにリアルタイムのリスク警告と資産保護を提供します。

今回のArch Linux AURサプライチェーン毒化事件において、MistEyeは関連する悪意のあるパッケージ、npm依存関係、ELFペイロード、C2通信、および2段階ダウンロードなどの攻撃チェーンの各段階を分析・関連付け、関連するIOCを抽出しました。分析結果に基づき、MistEyeはクライアントに高リスク警告および脅威インテリジェンス通知を配信し、クライアントが関連するサプライチェーンリスクを迅速に特定・対処できるよう支援しました。インテリジェンスの詳細：

以下に詳細な技術分析を示します。

攻撃チェーン分析：AURインストールスクリプトレットからnpmライフサイクルスクリプトへ

今回の攻撃の技術的主軸は、3段階の段階的構造で要約できます。攻撃者はAURパッケージを乗っ取り、ビルド/インストールスクリプトを改ざんすることで、pacmanによるインストールまたはアップグレード段階でnpm installをトリガーし、悪意のあるパッケージを取得します。その後、npmのライフサイクルスクリプト(preinstall)を利用して、パッケージに埋め込まれたLinux ELFネイティブペイロードを自動実行します。以下に、この3段階を順を追って説明します。

第一層：AUR インストールスクリプトレットが npm に実行権を譲渡

runescape-launcher パッケージ（バージョン 2.2.12-1）を例に挙げると、攻撃者は .SRCINFO と PKGBUILD に install.sh の参照を導入し、npm を実行時依存関係として宣言しました。

.SRCINFO における重要な声明：

PKGBUILD 内の対応する宣言：

install.sh は pacman のインストールスクリプトレットファイルです。攻撃者はこのファイル内で post_install() 関数を定義し、post_upgrade() を同じ関数に指向しています：

主要実行チェーンは以下の通りです：

.SRCINFO 声明 install = install.sh および depends = npm

→ PKGBUILD で install="install.sh" と depends=('npm' ...) を同期

→ makepkg が install.sh を最終的な pacman パッケージに組み込む

→ pacman の初回インストール時に post_install() を呼び出す

→ pacman のアップグレード時に post_upgrade() を呼び出す

→ post_upgrade() が post_install() を呼び出します

→ post_install() で /tmp に移動

→ npm install atomic-lockfile commander chalk → npm で atomic-lockfile@1.4.2 をインストール

atomic-lockfile の preinstall をトリガーする

→ Linux x86-64 ELF ペイロード src/hooks/deps を実行

注意点：commander と chalk は npm 上の合法で人気のあるパッケージであり、必ずしも悪意のあるパッケージとは限りません。同じ post_install() 内には、既存の/付随する setcap ロジックも存在しており、悪意のある追加部分は cd /tmp と npm install atomic-lockfile commander chalk です。

この層の核心設計意図は、pacmanのパッケージインストール/アップグレードライフサイクルを跳板として、実行権をシステムパッケージマネージャからnpmに移譲し、初回インストールおよびアップグレードの両方でトリガーされることである。

第2層：npm lifecycle がネイティブ ELF をトリガー——atomic-lockfile@1.4.2

atomic-lockfile@1.4.2 は、今回の攻撃で最初に使用された悪意のある npm パッケージです。このパッケージは、ファイルロックツールライブラリとして偽装しており、完全な TypeScript/JavaScript ライブラリ構造、main/module/exports エントリポイント、CLI、および型定義を保持しています。しかし、攻撃者は package.json の scripts.preinstall に、インストール時にネイティブバイナリを自動実行する設定を追加しました。

src/hooks/deps は通常の依存関係インストールスクリプトではなく、シンボルテーブルを除去した Linux x86-64 PIE ELF 実行ファイルです。重要なメタデータ：

ファイルパス：src/hooks/deps
ファイル形式：ELF 64ビット LSB pie実行ファイル、x86-64、動的リンク、ストリップ済み
ELF SHA-256：6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
サイズ：3,040,376 バイト
動的依存：libbpf.so.1、libm.so.6、libc.so.6
埋め込み eBPF オブジェクトの SHA-256：3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
埋め込み eBPF オブジェクトのオフセット：0x324f9
元のtarball SHA-256：64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

このELFペイロードの機能は、資格情報の収集、永続化、チャネル別通信/アップロード、およびroot権限または対応するcapabilityを有する条件下でのeBPFステルスコンポーネントの有効化試行をカバーしています。以下にそれぞれを詳細に説明します。

繰り返しXORデコードとTor隠蔽サービスC2

atomic-lockfile@1.4.2 のELFペイロードにおいて、重要なC2は明文文字列としてではなく、repeating-XORでエンコードされて格納されている。サンプルは0x1aa60オフセットに32バイトのキーを、0x2da96オフセットに62バイトの暗号文を埋め込んでいる。復号方法は以下の通り：

plain[i] = cipher[i] ^ key[i % 32]

デコード後に得られるTor v3ヒドンサービスアドレス：

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

62バイトの長さは、56文字のTor v3 onionホスト名に.onionサフィックスを加えたものに正確に対応します。C2ホスト以外にも、サンプルは同じ手法でエージェントの識別子とバージョンをエンコードしています：

エージェント名：atomic、キーオフセット 0x1bc60、暗号オフセット 0x3fddf
エージェントバージョン：0.8.2、キーオフセット 0x1c900、暗号オフセット 0x3fde5

この設計により、完全なC2は通常のstrings出力には表示されません。したがって、strings | grep .onion、平文のYARAルール、または単純なIOC抽出プロセスのみに頼ると、この隠蔽サービスC2を検出できない可能性があります。

Tor/SOCKS通信チャネル

C2ホストはXORエンコードされて隠されていますが、ELF内にはSOCKS/Tor関連のプレーンテキスト文字列が依然として表示されます。たとえば：

これらの文字列とデコードされた.onionアドレスを組み合わせると、このペイロードにはSOCKS/Torを通じてヒドゥンサービスC2に通信するフレームワークが組み込まれていることを示しています。

また、ELFには、POST、GET、HTTP/1.0、HTTP/1.1、Host:、Content-Length:、Content-Type: application/json、Content-Type: application/octet-stream、POST /upload HTTP/1.1、Content-Type: multipart/form-data などのHTTPリクエスト構築およびアップロード関連の文字列が存在する。POST /upload および multipart テンプレートは、ペイロードにアップロード構築機能があることを示唆しているが、temp.sh サービスと対応しているか、または実際に外部に送信されているかは、動的トラフィック、プロキシログ、またはホストフォレンジックの証拠によって確認する必要がある。

認証情報と開発環境の収集面

このELFは、現代の開発者ワークステーションの複数の重要な資格情報格納ポイントをカバーしています。

リモートプラットフォームの資格情報に関して、ペイロードには GitHubトークンの検証およびリポジトリ列挙に関連する文字列が含まれています——GET /user、GET /user/repos、Authorization: Bearer、Accept: application/vnd.github+json；npmトークンの検証文字列——GET /-/whoami、registry.npmjs.org、_authToken=；および Vault資格情報に関連する文字列——/.vault-token、X-Vault-Token:。

即時メッセージとコラボレーションツールにおいて、Slack 関連の文字列には auth.test、conversations.list、users.info の API パスおよび %.slack.com に対する Cookie SQL クエリが含まれ、Teams/Skype 関連では X-Skypetoken:、authsvc.teams.microsoft.com および %teams.microsoft.com に対する Cookie クエリが含まれ、Discord 関連の文字列には discord: なども確認されます。

ローカルおよびコンテナ環境では、.ssh、known_hosts、PRIVATE KEY、PuTTY-User-Key-File などの SSH 認証情報ファイル、および .bash_history、.zsh_history、.env、Chromium 系ブラウザの Cookie と Local Storage パスが注目対象です。Docker/Podman および DevOps ツールに関連する文字列—docker login、docker push、docker pull、docker build、docker run、docker tag、docker-compose、podman login、podman push など—は ELF 内に存在しますが、現在のところこれらは静的文字列としての手がかりに過ぎず、完全な収集チェーンは確認されていません。Claude：これらの文字列は AI ツールに関連する手がかりとしても機能しますが、Claude のデータ収集を単独で証明することはできません。

アップロードと二段階ダウンロード

荷重にはHTTP multipartアップロードテンプレートおよび/var/tmp、/secretsなどの一時データパスが含まれる。サンプルはonion C2を介したタスク/結果通信とmultipartアップロードリクエストの構築機能を備えている。temp.shサービスに対応しているかどうか、または具体的な被害ホスト上でアップロードまたは外部転送が成功したかどうかは、動的実行、プロキシログ、またはホストフォレンジック証拠によって確認する必要がある。二段階ダウンロードチェーンには明確な静的痕跡も残されている：/bin/sha256/およびsha256 fetch:という文字列は、二段階のハッシュ検証パスを示しており、server returned empty binaryおよびtmp 200 headers too largeというメッセージは、二段階ダウンロード失敗時のエラーハンドリングロジックが存在することを示している。Tor bundleの取得痕跡/tor-expert-bundle-とSOCKS伝送チェーンの組み合わせは、stagingダウンロードの手がかりを構成している。

疑似cryptominerの手がかり

atomic-lockfile の ELF に /usr/bin/monero-wallet-gui の文字列が含まれている。二段階ダウンロードチェーンと組み合わせると、ペイロードは二段階で Monero マイニング関連のバイナリを取得する可能性があると推測される。現在のサンプル内では xmrig、randomx、stratum、マイニングプールドメイン、ウォレットアドレスなどの強力なマイナー特徴は確認されていないため、内部にマイナー本体が含まれているとは断定できない。

永続化

サンプルには、ユーザー階層とシステム階層の両方の起動シナリオをカバーする systemd サービステンプレートが含まれており、ペイロードが自身をシステムサービスとして登録し、再起動後やユーザーセッション開始後に継続して実行されることを意図していることを示している。

eBPF の隠蔽とフォレンジック対策

eBPF（拡張 Berkeley パケットフィルター）は、Linuxカーネルが提供するメカニズムで、カーネルのソースコードを変更せずに、制限されたカスタムプログラムをカーネルに読み込んで実行できます。通常の用途では、ネットワークフィルタリング、可観測性、セキュリティ監視に使用されますが、今回のサンプルにおけるeBPFコンポーネントは、システムを「観察」するためではなく、自らを「隠す」ためのツールとして設計されています。

atomic-lockfile@1.4.2 のELFペイロードsrc/hooks/depsはlibbpf.so.1に依存し、bpf_object__open_mem、bpf_object__load、bpf_program__attach、bpf_map__pinなどのAPIを用いて組み込まれたeBPF再配置可能オブジェクトの読み込みを試みる。このロジックは無条件で実行されない：サンプルはまずgeteuid()を呼び出してrootユーザーかどうかを確認し、次に/proc/self/statusを読み取り、CapEff:フィールドを解析して、CAP_BPFおよびCAP_SYS_ADMINに対応するcapabilityビットをテストする。より正確には、権限条件が満たされた場合にのみ、サンプルはeBPF読み込み試行パスに入る。つまり、これは条件付きの隠蔽モジュールに近い；現在の静的証拠は、自身で権限昇格を完了していることを示していない。

デコンパイル結果によると、ホストプログラムはオフセット 0x324f9 から 0xce28 バイトの埋め込みオブジェクト、すなわち 52,776 バイトの eBPF オブジェクトを読み取ります。このオブジェクトの SHA-256 は：

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

抽出されたeBPFオブジェクトは、独立したコンパイル成果物であり、ファイル形式はELF 64-bit LSB relocatableで、debug_info/BTF情報が含まれており、strippedされていません。そのデバッグ情報にはソースコードのパスが漏洩しています：

/cloud/scales/agent/../ebpf/scales.bpf.c

このeBPFオブジェクトは、BPFマップ（状態を保存するデータテーブル）とtracepoints（カーネルイベントフックポイント）を組み合わせて、複数の隠蔽およびフォレンジック対策の痕跡を生成します。そのデバッグ情報とシンボルには、hidden_pids、hidden_names、hidden_inodes、net_fds、diag_fds、getdents64、ptrace、recvmsg、bpf_probe_write_userなどの名前が含まれており、これはプロセスの隠蔽、ディレクトリエントリの隠蔽、ネットワーク接続に関連するsocket/inodeの隠蔽、およびデバッガーのアタッチを妨害することを設計目標としていることを示しています。

具体的には、このeBPFオブジェクトの機能痕跡は以下の3類に分けられる：

プロセスとディレクトリエントリの非表示：hidden_pids は非表示にする PID を保存するために使用される。sched_process_exec 関連のロジックは、新しいプログラムの実行時に hidden_names に一致するプロセス名を検出し、一致した PID を非表示集合に追加する。getdents64 関連のロジックはディレクトリ読み取り結果の処理に対応し、悪意のあるサンプルはこれを利用して /proc などのディレクトリリストから指定された PID やディレクトリエントリを非表示にできる。
ネットワーク接続列挙の妨害：recvmsg、socket、hidden_inodes、net_fds、diag_fds などの手がかりは、ネットワーク接続列挙結果の妨害を示唆しており、ss や netstat などのツールが表示する socket/inode 情報に影響を与える可能性があります。
デバッグと改ざん結果の遮断：ptrace、PTRACE_ATTACH、PTRACE_SEIZE および bpf_send_signal(9) は、デバッガーのアタッチを遮断するためのフォレンジック回避設計を示している；複数の bpf_probe_write_user 文字列は、このオブジェクトがユーザースペースの読み取りバッファを変更する実装の痕跡を有していることを示しており、これはディレクトリエントリやネットワークエントリを隠蔽するための重要な手段である。

本件は静的分析であるため、サンプルを動的に実行していないため、このeBPFオブジェクトが特定のホスト上で実際にロードされた成功率を確認できず、プロセス、ディレクトリエントリ、またはネットワーク接続が実際に隠蔽されたとは断定できません。しかし、権限チェックロジック、map構造、tracepointのカバレッジ、およびbpf_probe_write_userの使用痕跡から判断すると、このオブジェクトの設計意図は、root権限または対応するカーネル能力を持つ前提で、プロセス、ディレクトリエントリ、およびネットワーク接続に関連するsocket/inodeの痕跡を隠蔽し、動的分析を困難にすることです。

第3層：.mjs 拡張子の偽装——js-digest@4.2.2

js-digest@4.2.2 は、今回の攻撃の後続の波で使用された悪意のある npm パッケージです。このパッケージは JavaScript の要約/暗号化ツールライブラリを装っており、aes.js、sha256.js、hmac-sha512.js、index.js などの通常の外観を持つソースコードファイルを含んでいます。攻撃者は package.json に preinstall エントリを設定しました：

atomic-lockfileとの主な違いは、ペイロードの命名戦略である。install-deps.mjsの拡張子.mjsは、これがESM JavaScriptモジュールであることを示唆し、人間による監査者や拡張子に基づく検出ルールの警戒を低下させる。しかし、静的ファイルタイプ識別によると、実際にはLinux x86-64 PIE ELFである。主要なメタデータ：

ファイルパス：lib/install-deps.mjs
サフィックスの示唆：ESM JavaScriptモジュール
実際のファイルタイプ：ELF 64ビット LSB pie 実行可能ファイル、x86-64、動的リンク、ストリップ済み
ELF SHA-256：7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
サイズ：3,193,176 バイト
動的依存：libbpf.so.1、libm.so.6、libc.so.6
埋め込み eBPF オブジェクトの SHA-256：3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
組み込み eBPF オブジェクトのオフセット：0x37d91
元のtarball SHA-256：0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

js-digest は、C2をrepeating-XORエンコードで隠蔽しています。0x1cba0オフセットに32バイトの鍵が埋め込まれ、0x32bcbオフセットに62バイトの暗号文が格納されており、復号結果はatomic-lockfileと完全に一致します：

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

そのエージェントの識別子とバージョンは：

エージェント名：cryjs（キーオフセット 0x1d740、暗号オフセット 0x45ec2）
エージェントバージョン：0.8.4（キーオフセット 0x1ec40、暗号オフセット 0x45ec7）

両方のエージェント名（atomic と cryjs）およびバージョン（0.8.2 と 0.8.4）は異なるが、同じ onion C2 アドレスと同じ組み込まれた eBPF オブジェクトを共有している。

js-digest は、資格情報収集関連文字列、SOCKS/Tor 伝送チェーン、multipart アップロードテンプレート、systemd 永続化テンプレート文字列、および二段階ダウンロードフラグメント（/bin/sha256/、sha256 fetch:）において atomic-lockfile と高度に一致している。Docker/Podman および @reboot 関連の手がかりは atomic-lockfile よりも明確ではなく、/usr/bin/monero-wallet-gui も js-digest では確認されていない。

.mjs 拡張子の偽装は、今回の攻撃において注目すべき回避手法です：これは差分検出の盲点を突くもので、文字列やファイル名に基づくパターンマッチングルールが .mjs ファイルを「JavaScript モジュール」ホワイトリストに分類し、実際の MIME タイプや ELF ヘッダーを検査しない可能性があります。

要約

今回のArch Linux AURサプライチェーンポイズン攻撃は、オープンソースソフトウェアエコシステムにおける二つの構造的脆弱性が重なり合ったことを示している。一つはAURのオーファンパッケージ引き継ぎメカニズムが引き継ぎ者に対する信頼審査を欠いていること、もう一つはパッケージマネージャ（pacmanとnpm）のライフサイクルスクリプトがインストール段階で実行可能な信頼境界が連結されていることである。攻撃者はいかなるソフトウェア脆弱性にも依存せず、オープンソースエコシステムの保守メカニズムとパッケージマネージャの設計上の行動を悪用するだけで、完全な攻撃チェーンを構築できる。

今回の攻撃チェーンの技術的特徴は、以下の3つのレベルに要約できます：

AURの信頼継承の悪用。攻撃者は新しいパッケージを作成したり、ソフトウェアの脆弱性を悪用したりせず、メンテナンスされていないAURパッケージを引き継ぐことで、既存のユーザー基盤を継承した。runescape-launcherを例に挙げると、攻撃者は合法的なAUR引き継ぎプロセスを利用してパッケージを乗っ取り、install.shにnpm install atomic-lockfileコマンドを埋め込み、post_upgrade()からpost_install()を呼び出してアップグレード時にも実行されるようにした。被害者ユーザーが通常のyay -Sまたはparu -S操作を実行しても、PKGBUILDおよび.installスクリプトが改ざんされていることに気づかない。

二重ライフサイクル連携とC2隠蔽。攻撃者はpacmanのpost_install()/post_upgrade()スクリプトレットをエントリーポイントとして、AURパッケージのインストール/アップグレード時にnpm installをトリガーし、npmのpreinstallライフサイクルを利用してLinux ELFペイロードを実行する。ペイロードのC2アドレスはrepeating-XORでエンコードされ、単純なstrings/grep .onionでは直接抽出できない。onion C2は、タスク、結果、ステータスの通信チャネルとしてより適切に表現される。ペイロードはmultipartアップロードリクエストの構築機能も備えている。temp.shサービスに対応しているかどうか、または具体的な被害ホストへのアップロードが成功したかどうかは、動的またはログ証拠によって確認する必要がある。

ロードコンビネーションはマルチステージ攻撃能力をカバーしています。ELFロードは、静的機能として、資格情報収集（GitHub/npm/Slack/Discord/Teams/Vault/SSH/ブラウザおよびDocker/PodmanなどのDevOps関連の文字列ヒント）、チャネル別通信とアップロード構成（onion C2 + multipart uploadテンプレート）、永続化テンプレート（systemd user/systemサービスがWantedBy=multi-user.targetおよびWantedBy=default.targetを両方サポート）、および条件付き防御回避（権限が満たされた場合、eBPFを用いてプロセス、ファイル名、socket/inodeを隠蔽しようとする、bpf_send_signal(9)でptraceデバッグをブロック）などの機能をカバーしています。js-digestはさらに.mjs拡張子を模倣することで、拡張子に基づく検出の有効性をさらに低下させています。

提案：

インストール済みのAURパッケージの中で、npm install atomic-lockfile、bun install js-digest、または類似のnpm/Bun取得コマンドを含むPKGBUILDまたは.installスクリプトがあるか即座に調査してください。影響を受けたパッケージが見つかった場合、隔離環境でデジタル証拠収集と資格情報の変更を直ちに実施してください。
~/.config/systemd/user および /etc/systemd/system に異常な systemd service/timer が存在するか確認し、/sys/fs/bpf/ に hidden_pids、hidden_names、hidden_inodes などの異常な BPF マップが存在するか確認してください。
影響を受けた開発者ホストについて、GitHub PAT/GITHUB_TOKEN、npmトークン、Slack/Discord/Teamsセッション、Vaultトークン、SSH秘密鍵、Docker/Podman認証情報、および.envファイルに保存されたすべてのキーをローテーションしてください。
CI/CD ビルド環境は、node_modules をクリーンアップするか悪意のあるパッケージを削除するだけでなく、信頼できるベースイメージから再構築することをお勧めします。
AURユーザーは、最近取得されたか長期間アクティブでないパッケージをインストールする前に、PKGBUILDおよび.installスクリプトを一行ずつ確認し、npm install、bun install、curl、wgetなどの外部コマンド呼び出しが含まれていないか注意してください。

IOC

ドメイン

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid[.]onion

悪意のある依存

npm:atomic-lockfile@1.4.2

npm:js-digest@4.2.2

npm:nextfile-js@1.4.2

npm:lockfile-js@1.4.2

悪意のあるファイル

ファイル名: src/hooks/deps SHA256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

ファイル名: lib/install-deps.mjs SHA256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

ファイル名: atomic-lockfile-1.4.2.tar.gz SHA256: 64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

ファイル名: js-digest-4.2.2.tar.gz SHA256: 0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

ファイル名：埋め込み eBPF オブジェクト SHA256: 3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

本文はSlowMist脅威インテリジェンスチームがMistEye脅威インテリジェンスシステムとSlowMist Agent AI駆動分析を活用して作成しました。ご質問やフィードバックはお気軽にお問い合わせください。

参照リンク

1.https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency

Arch Linux AURのサプライチェーン汚染が悪意のあるnpmパッケージと関連

背景