JFrog Artifactoryの脆弱性3件が実悪用、Rustバックドアも確認　更新後も侵害調査が必要

自社運用のJFrog Artifactoryを利用する組織に、脆弱性の修正と侵害調査が求められている。Wiz Researchは2026年9月10日、複数の攻撃者が8月15日から9月8日にかけて認証関連の脆弱性を悪用し、管理者権限を取得してRust製バックドアなどを設置していたと報告した。

対象は修正を適用していないセルフホステッド環境で、JFrog Cloudには対策が適用済みである。ソフトウェアの更新だけでは、攻撃者が作成した管理者アカウント、発行済みトークン、窃取されたクラスタージョインキーなどは無効にならないため、影響を受けた可能性がある環境では追加の対応が必要となる。

■ソフトウェア供給網の中核を狙った攻撃

Wiz Researchによると、複数の脅威アクターが、修正プログラムの提供後も更新されていなかったJFrog Artifactoryのセルフホステッド環境を攻撃した。一部の事例では、認証されていない状態から新たな管理者アカウントを作成するまでに要した時間は5分未満だったという。

Artifactoryは、ソフトウェアのビルドに使われるパッケージ、依存関係、バイナリなどを保管・配布するアーティファクトリポジトリである。ビルドパイプラインが参照する基盤で管理者権限を奪われると、保存された成果物や認証情報へのアクセスに加え、下流のビルドが取り込むデータを改変される可能性がある。

JFrogの2025年末時点の公表資料によると、同社は約6600組織を顧客に持ち、Fortune 100企業の約83％に採用されている。このため、Artifactoryへの侵害は個々のサーバーにとどまらず、組織のソフトウェア開発・配布工程に影響を及ぼし得る。

■匿名トークンから管理者権限を取得

Wizが確認した攻撃の一つでは、CVE-2026-42018とCVE-2026-42016が連鎖して悪用された。

CVE-2026-42018は、匿名アクセスを無効にした環境でも、認証されていない呼び出し元に内部の匿名ユーザー用JSON Web Tokenを返す可能性がある不適切な認証の脆弱性である。攻撃では、末尾にスラッシュを加えたトークンエンドポイントへのPOSTリクエストが使われていた。取得できる匿名トークン自体の権限は限定的だった。

CVE-2026-42016は、トークンの権限範囲を適切に検証しない認可上の脆弱性である。Artifactoryはトークンの署名と発行者を検証する一方、トークンに指定されたスコープが呼び出し元に許可された範囲かどうかを十分に強制していなかった。

攻撃者はCVE-2026-42018で得た匿名ユーザー用トークンをトークン作成エンドポイントに提示し、管理者スコープを持つトークンを取得していた。個別には限定された脆弱性でも、匿名トークンの取得と不適切なスコープ検証が組み合わさることで、認証なしの状態から管理者権限に至る経路が成立した。

JFrogはCVE-2026-42016を7月27日、CVE-2026-42018を8月12日に公表していた。Wizが連鎖攻撃を最初に観測したのは8月15日で、攻撃開始時点では修正プログラムがすでに提供されていた。

■管理操作が「token:anonymous」と記録

この攻撃では、生成された管理者スコープのトークンが匿名ユーザーの識別情報を引き継ぐ。そのため、このトークンを使った管理操作は、Artifactoryのログ上で名前付き管理者ではなく「token:anonymous」による操作として記録される。

不審な名前の管理者アカウントだけを検索しても、管理者トークンを取得した初期段階の活動を見落とす可能性がある。攻撃者が名前付き管理者アカウントを作成するのは、すでに管理者権限を得た後だからだ。

調査では、匿名ユーザーや本来は低権限であるユーザーが、トークンの作成、ユーザー一覧の取得、プラグインの再読み込み、リポジトリ設定の参照といった管理者向け操作を実行していないかを確認する必要がある。

■正規のプラグイン機構からRustバックドアを設置

Wizは、侵害後の活動が攻撃者によって異なることを確認した。すべての手順を同じ攻撃者が実行したわけではなく、複数のグループが脆弱な環境をそれぞれ悪用していた可能性がある。

攻撃者は「jfrog-distribution」「backup-service」「jfrog-insight」「repo-service」など、正規のサービス用IDに見える管理者アカウントを作成していた。このほか、「0xTerror」や、「labadmin_」にランダムな文字列を続けた名前も確認された。

複数の攻撃者は、Artifactoryの正規のGroovyプラグイン機構を使って悪意あるプラグインを導入した。管理者としてプラグインを読み込ませることで、追加の脆弱性を使わずに、Artifactoryが稼働するホスト上でコードを実行していた。

その後、ドロッパーが暗号化されていないHTTP通信でバイナリを取得し、/tmp、/dev/shm、/var/tmpなどのディレクトリに保存して、外部とのコマンド＆コントロール通信を確立した。

Wizは複数の侵害環境で、Rustで作成されたカスタムバックドアを確認した。確認対象となる指標には、SHA-1ハッシュが「513a907b69edffc3cb77a494da395178d21ef9bd」である「/tmp/.z」が含まれる。

ペイロードの配布元として「hxxp://log.gitclone[.]org:45678/smtp」と「hxxp://3.88.162[.]79:36789/smtp」、C2通信先として「64.207.232[.]6:8443」が観測された。これらは今回確認された攻撃に関する侵害指標であり、該当の有無をログや端末上で調査する手掛かりとなる。

攻撃者はArtifactoryの設定データやクラスタージョインキーを窃取し、一部ではWebシェルも設置していた。クラスタージョインキーはArtifactoryのノード間で信頼関係を構築する共有シークレットであり、窃取されたキーは明示的に変更するまで有効であり続ける可能性がある。

■単独で管理者権限につながるCVE-2026-82329

2件の脆弱性を組み合わせた攻撃とは別に、CVE-2026-82329も実際の攻撃で悪用されている。これはデフォルト構成のArtifactoryで、ネットワークから到達可能な未認証の攻撃者が管理者権限を取得できる可能性がある認証の脆弱性で、CVSS v3.1の基本値は9.8である。

Fastlyの分析によると、Artifactoryは信頼するクラスタージョインキーの一覧を構成する際、空の値を除外していなかった。デフォルト環境では空の値から予測可能な署名用シークレットが生成されるため、攻撃者がクラスタ参加用のトークンを偽造し、管理者権限を持つトークンの取得に利用できた。

JFrogは8月28日にCVE-2026-82329を公表し、修正版を提供した。watchTowrは9月1日までに、インターネットへ公開された環境で攻撃者が管理者トークンを生成し、ユーザーやグループなどを列挙する活動を観測したと報告している。

Fastlyも、公表後に同脆弱性を狙う通信が小規模な探索から広範なスキャンへ移行したと報告した。Fastlyが観測した通信件数は攻撃の試行を示すもので、実際に侵害された組織やサーバーの数とは一致しない。

米サイバーセキュリティ・社会基盤安全保障庁は9月2日、CVE-2026-82329を「既知の悪用された脆弱性カタログ」に追加した。さらに9月11日には、連鎖攻撃に使われたCVE-2026-42016とCVE-2026-42018も同カタログに追加し、実際の悪用が確認された脆弱性として対応を求めている。

■脆弱な環境が多数残っているとの推計

Wizによると、CVE-2026-42016が7月27日に公表された時点では、Artifactoryを使用する調査対象組織の67％に少なくとも1台の脆弱なインスタンスが存在した。公表から6週間後にも59％が脆弱な状態にあったという。

CVE-2026-42018では、8月12日の公表時点で69％、約4週間後にも62％が脆弱だった。CVE-2026-82329は比較的速く更新が進んだものの、Wizの調査では公表から約2週間後にも49％が脆弱な状態にあった。

Wizは、外部から到達可能な調査対象インスタンスの49～62％が、3件のうち少なくとも1件の脆弱性の影響を受ける状態にあると推定している。これらはWizが可視化できた環境を基にした推計であり、世界中の全Artifactory環境における割合を直接示すものではない。

JFrog Cloudの影響を受ける環境にはJFrog側で対策が適用されている。利用者自身による更新と調査が必要なのは、主にセルフホステッド版である。

■更新後もアカウントやトークンは残る

修正版への更新は新たな侵入経路を閉じるが、更新前に発行されたアクセストークンや、攻撃者が作成した管理者アカウントを自動的に削除するものではない。窃取されたクラスタージョインキーや、設置されたバックドア、改変された設定やアーティファクトも別途確認する必要がある。

8月15日から9月8日の間にインターネットへ公開され、該当する未修正バージョンを実行していたArtifactoryについて、Wizは侵害された可能性を前提として調査するよう勧告している。

修正版は脆弱性とリリース系列によって異なる。CVE-2026-82329についてJFrogが案内している修正版は、7.111.21、7.117.28、7.125.20、7.133.29、7.146.38、7.161.20であり、各系列のこれら以降へ更新する必要がある。CVE-2026-42016とCVE-2026-42018の影響範囲と修正版は別に定められているため、利用中の系列をJFrogの最新セキュリティアドバイザリで確認することが重要となる。

CVE-2026-82329には、直ちに更新できない場合の暫定策として、ランダムな追加ジョインキーをsystem.yamlに設定する方法が案内されている。一方、CVE-2026-42016とCVE-2026-42018を組み合わせた経路については、Wizは暫定的な回避策はないとしている。

対応では、まず脆弱性を修正した後に認証情報を変更する。脆弱な状態のままシークレットを変更すると、環境内に残る攻撃者に新しい認証情報を取得されるおそれがあるためだ。

更新後は、クラスタージョインキーのローテーション、影響期間中に発行されたアクセストークンの調査と失効、不審な管理者アカウントの削除を行う。さらに、Artifactoryの設定、リポジトリ、プラグイン、ホスト上のファイルを既知の正常な状態と比較し、改変やバックドアの有無を調べる必要がある。

■ログで確認すべきリクエストと操作

CVE-2026-42018とCVE-2026-42016の連鎖攻撃では、同一クライアントから短時間のうちに、標準のトークン取得パスへのリクエストがHTTP 401を返し、末尾にスラッシュを追加したパスへのリクエストがHTTP 200を返していないかを確認する。この並びは、攻撃者が標準パスを試した後に脆弱な派生パスを利用した可能性を示す。

Artifactoryのリクエストログでは、「token:anonymous」が「/access/api/v1/tokens」でトークンを作成したり、プラグインを再読み込みしたり、ユーザーやリポジトリ設定を参照したりしていないかを調べる。匿名または低権限のIDによる管理者向け操作は、優先して確認すべき兆候となる。

CVE-2026-82329については、「/access/api/v1/registry/join」へのPOSTリクエストがHTTP 200または201を返していないかを確認する。その後に管理者アカウントの作成、システム設定の取得、トークンの列挙、作成されたユーザーへのSSHキー追加などが続いていれば、一連の侵害活動として調査する必要がある。

「jfrog-distribution」や「backup-service」のように正規サービス用に見えるアカウントも、実際に組織が構成したものかを確認しなければならない。該当サービスを導入していない環境で同名の管理者アカウントが見つかった場合は、攻撃者が永続的なアクセスのために作成した可能性がある。

元記事: JFrog Artifactory Hacked in 24-Day Campaign; Rust Backdoors Survive Patching