オンプレミス版のJFrog Artifactory（社内向けバイナリリポジトリ）を全社のビルド成果物の配布経路に置いている組織では、2026年夏に公開された3件の脆弱性が運用の前提を崩す。CVE-2026-42018（認証回避）とCVE-2026-42016（権限昇格）を連結すると、匿名アクセスを無効にしたインスタンスでも、認証情報を持たない相手が管理者スコープのトークンを取得できる。Wiz Researchは2026年8月15日から9月8日にかけて、複数の攻撃者がこの2件を連結して自己ホスト型のArtifactoryを攻撃するのを観測し、独自のRust製バックドアが設置された事例を報告している[1]。米CISAは2026年9月11日、JFrogの2件を含む3件を悪用実績のある脆弱性カタログ（KEV）に追加した[2]。厄介なのはパッチ適用後だ。侵入中に作られた管理者アカウントやGroovyプラグインは、アップグレードでは消えない[1]。3件の仕組みと観測された悪用の実態を整理し、パッチ適用後に何を確認すべきかを順に見る。
予備知識
- JFrog Artifactory：社内でビルドしたコンテナイメージやnpm/Mavenパッケージを一元管理・配布するリポジトリ製品。CI/CDの中核に置かれることが多い。
- KEV（Known Exploited Vulnerabilities）カタログ：米CISAが「実際に悪用が確認された脆弱性」を掲載するリスト。対策の緊急度を示す指標として使われる。
- トークンのスコープ：APIトークンに付与された「どの操作まで許可するか」という権限範囲。署名や発行者が正しくても、スコープの検証が漏れると低権限トークンが管理者権限として通ってしまう。
- Groovyユーザープラグイン：Artifactoryが備える拡張機構。サーバー上のプラグイン置き場にファイルを置くとAPIから呼べるようになる。
ビルド・配布経路を狙う攻撃の脅威モデリングを体系立てて学びたい担当者向け。
JFrog Artifactoryの何が壊れていたのか
CVE-2026-42018とCVE-2026-42016を連結すると、認証情報を持たない外部の攻撃者が数分で管理者になれる。
起点はCVE-2026-42018だ。匿名アクセスを無効にしていても、/access/api/v1/aws/token/へのリクエストに内部的な匿名ユーザー用のJWT（JSON Web Token）を誤って返してしまう不備で、2026年8月12日公開[1][3]。次に効くのがCVE-2026-42016（2026年7月27日公開）だ。トークンの署名・発行者は正しく検証するが、権限範囲（スコープ）は強制していなかった。結果、先の匿名JWTを/access/api/v1/tokensに渡すだけで管理者スコープの新トークンを取得できる[1][3]。Wizの観測では、最初のリクエストから管理者アカウント作成まで5分以内という事例もある[1]。
| CVE番号 | 深刻度 | 対象バージョン | 修正済みバージョン |
|---|---|---|---|
| CVE-2026-42016 | High（CWE-863 不適切な認可） | 7.133.11より前の全バージョン | 7.133.11 |
| CVE-2026-42018 | High（CWE-287 不適切な認証） | 7.111.20未満、7.117.0〜7.117.27等の複数系列 | 7.111.20、7.117.27、7.125.19、7.133.28、7.146.8 |
| CVE-2026-82329 | Critical（CWE-287 不適切な認証） | 7.161.19以前の複数系列 | 7.111.21、7.117.28、7.125.20、7.133.29、7.146.38、7.161.20 |
CVE-2026-82329は別系統だ。デフォルト設定のまま/access/api/v1/registry/joinへ未認証でPOSTすると、応答本文に管理者スコープのトークンが返る。2026年8月28日公開で、深刻度はCritical[3]。Wizによれば、この脆弱性は複数のベンダーから実際の悪用が報告され、CISAのKEVにも追加されている[1]。3件とも、認証は通しつつ認可の境界を作り込めていない点が共通する。
Artifactoryとは製品が違っても、トークン・スコープ管理の考え方をCI/CD全体に広げて理解できる。
観測された悪用の実態と、遅れるパッチ適用
悪用は2026年8月から9月にかけて複数の攻撃者によって観測され、公開から数週間たっても半数前後の組織が脆弱なインスタンスを残していた。
Wiz Researchは2026年8月15日から9月8日にかけて、複数の攻撃者がCVE-2026-42018とCVE-2026-42016を連結して自己ホスト型のArtifactoryを攻撃するのを観測している。CVE-2026-82329については9月1日から9月8日にかけて、別に複数の攻撃者による悪用を確認している[1]。いずれもWizが観測できた範囲の期間で、同社は状況の進展に応じてアドバイザリとブログを更新し続けるとしており、そこで区切りがついたわけではない[1]。
侵入後の挙動には一定のパターンがある。攻撃者はまずlabadmin_やsvc_で始まるランダム文字列のアカウント、あるいはjfrog-distributionやbackup-serviceのように正規の運用アカウントを装った名前で管理者アカウントを作成する[1]。次に任意のシェルコマンドを実行できるGroovyプラグインを配置し、/api/plugins/execute/<プラグイン名>経由で実行する。最終的に/dev/shmや/tmpなど書き込み可能な一時領域にRust製のバックドアを展開し、外部のC2（コマンド&コントロール）サーバーから追加のペイロードをHTTPで取得する構成が確認された[1]。観測されたC2通信先には64.207.232.6:8443などが含まれる[1]。
パッチ公開後の適用は遅い。Wizの集計では、CVE-2026-42016が公開された7月27日の時点で、Artifactoryを運用する組織の67%が脆弱なインスタンスを1台以上抱えていた。CVE-2026-42018は公開時点（8月12日）で69%、CVE-2026-82329は公開時点（8月28日）で67%と同水準だった[1]。その後の減り方は一様ではない。CVE-2026-42016は最初の公開から6週間後も59%の組織が脆弱なまま、CVE-2026-42018は4週間で69%から62%までしか下がっていない。CVE-2026-82329はCriticalという深刻度評価が緊急の対応を促したとみられ、公開2週間で67%から49%へ下がった[1]。深刻度が低い側のCVEほど放置されているという構図で、連鎖の起点になるのはその低い側だ。
従業員数千人規模で、基幹システムと取引先・外部サービスとの連携をBizTalk Server 2020で長年運用してきた製造業や金融機関の情報システム部門は少なくない。日々の運用では、その連携基盤がAzure Service Busとの通[…]
パッチだけでは終わらない理由——遡及調査が必須になる根拠
パッチは今後の侵入経路を塞ぐだけで、侵入済みなら残された管理者アカウントやバックドアは消えない。
CVEへのパッチは、今後同じ手口で侵入されることを防ぐだけだ。すでに作成された管理者アカウント、配置されたGroovyプラグイン、展開済みのバックドアはパッチのインストールでは消えない。Wizは、Groovyのユーザープラグインは再起動のたびに自動で読み込まれるため、アップグレードは入口を閉じても内部に居る攻撃者を追い出さないと明示している[1]。さらに重いのは鍵だ。回収されたプラグインのうち複数は、Accessトークンの署名鍵private.keyを読み出す機能を持つ。鍵を持ち出されていれば、任意のユーザー・任意のスコープのトークンを、ホストに戻らずに作り続けられる。パッチではこれは失効しないため、該当するプラグインが見つかったインスタンスにはアップグレードだけでなくトークン証明書のリセットが要る[1]。
したがって対応は「パッチ適用」で終わらせず、該当バージョンを使い始めてからパッチ適用までの期間に遡ってログを確認する遡及調査（コンプロマイズアセスメント）が必要になる。米CISAのBOD 26-04も、連邦民生機関に対して、パッチ適用前に攻撃者に侵害されていなかったかを確認すべき場面の基本的な期待値を定めている[2]。確認すべき痕跡は大きく3つある。第一に、認証エラー（401）の直後に短時間で200応答が続く不自然なアクセスパターン。第二に、本来は低権限のはずのアカウントが/access/api/v1/tokensでトークンを発行したりユーザー一覧を取得したりする操作。第三に、身に覚えのない管理者アカウントやプラグインの存在そのものだ[1]。
ただし、そのログ自体が消されている場合がある。Wizが回収したプラグインの一つにはpurgeという操作があり、Artifactoryのログディレクトリにあるrequest*.logをすべて0バイトに切り詰めてから、プラグイン自身をディスクから削除する。切り詰められるのは、これら3つの痕跡を探すためのアクセスログそのものだ[1]。別のプラグインはメモリ上にしか存在しない第二のバックドアを仕込み、api/pluginsやregistry/joinを含むURIへのリクエストを、攻撃者のヘッダーがない限りHTTP 400で拒否する。正規の管理者がプラグインの一覧表示・再読み込み・削除をできなくなるため、調査中にプラグインAPIが壊れて見えること自体が指標になる[1]。ログが空になっている、プラグインAPIが400を返す——どちらも「痕跡なし」ではなく痕跡として扱う。
数千人規模の従業員を抱え、SharePoint Server（Microsoft 365ではなくオンプレミス環境で運用する社内ポータル基盤）を人事・稟議・ナレッジ共有の窓口として使い、年1回の内部監査を受ける企業のIT基盤担当者に、いま最[…]
内部配布ソフトの供給源が侵害されるとどこまで波及するか
Artifactoryは配布の終点ではなく中継点であり、侵害されると通過した成果物すべてが調査対象になり得る。
開発者や委託先のSIer（システムインテグレーター）がビルドしたコンテナイメージやパッケージは、いったんArtifactoryに登録されたのち、社内の各システムやビルドサーバーへ配布される。ここが侵害されると、配布経路を通過した成果物すべてに改ざんの疑いがかかる。単発の情報漏えいと違い、影響範囲の特定に「いつリリースしたか」「誰がpullしたか」という配布記録の突合が要る点で調査コストが大きい。
射程はビルド成果物にとどまらない。Wizが解析したプラグインの一つは、LDAPの接続情報やリモートリポジトリに保存された認証情報を復号して返す。同社はこれを、組織の上流レジストリ・SSOディレクトリ・外向きプロキシへの直接の足がかりだと評している[1]。別のプラグインはArtifactoryを中継にした内部ネットワークへのトンネルを開き、しかも設定済みのプロキシを迂回して外向き接続を張るため、本来なら気づくはずの監視をすり抜ける[1]。
社内ネットワーク限定の運用なら同じ侵害は起きないのか
外部から直接叩かれる経路は塞がれるが、脆弱性そのものは残り、遡及調査の必要も消えない。
Wizが観測した悪用は自己ホスト型インスタンスに対するもので、同社はインターネットから到達できるインスタンスを優先して対応し、ネットワークアクセスを信頼できる利用者とシステムに制限するよう勧めている[1]。Artifactoryを社内ネットワークからしか叩けない構成にしている組織では、外部の匿名攻撃者が/access/api/v1/aws/token/や/access/api/v1/registry/joinへ直接到達する最短経路は塞がれている。
塞がれているのは経路だけだ。Wizは、これらのCVEは認証不要のHTTPリクエスト数回で悪用でき、脆弱な状態で外部に公開されていたなら侵害を前提に痕跡を探すべきだとしている[1]。逆に言えば、社内ネットワークに入れる立場——VPN経由の委託先アカウント、踏み台にされた開発端末、CIランナー——から同じ数回のリクエストを送れば結果は同じになる。外部に出していなくても更新そのものは要るということで、CVE-2026-42016は公開から6週間後もなお59%の組織が脆弱なインスタンスを残していた[1]。バージョンを年次の保守枠でしか動かせない体制では、この空白がさらに延びる。
確認の側でもう一点効くのが、アカウント名だ。攻撃者が作る管理者アカウントにはjfrog-distributionやmigration-toolのように、正規の運用アカウントとして通りそうな名前が使われる[1]。一覧を目で追うだけでは見落とすため、いつ誰が作ったかまで当たる。
まとめ
JFrog Artifactoryの連鎖攻撃が示したのは、認証は通っても認可（スコープ）の検証が甘いと、数回のリクエストで管理者の境界を越えられるという事実だ。3件ともすでに修正版が出ているが、侵入中に作られた管理者アカウント、配置されたGroovyプラグイン、持ち出されたAccess署名鍵は、アップグレードでは消えない[1]。脆弱性対応が「パッチ適用」で完結せず「侵害有無の遡及調査」という別の判断を要求するのはこのためで、米CISAのBOD 26-04がパッチ適用前に侵害されていなかったかを確認すべき場面まで定めているのも同じ理由だ[2]。
次の一手は、該当バージョンを稼働させていた期間のアクセスログとAudit Logを突合し、身に覚えのない管理者アカウント・APIトークン・Groovyプラグインの有無を確認することだ。ログが0バイトに切り詰められていたり、プラグインAPIがHTTP 400を返すようになっていたりすれば、それ自体を痕跡として扱う[1]。該当するプラグインが実際に見つかった場合は、アップグレードとアカウント無効化だけでは足りず、トークン証明書のリセットまで踏む[1]。
よくある質問（FAQ）
Q. JFrog Artifactoryとは何ですか。
A. 社内でビルドしたコンテナイメージやパッケージを一元管理・配布するリポジトリ製品で、多くの企業のCI/CDパイプラインの中核に置かれている。
Q. 自社のバージョンが今回の脆弱性の対象か確認するにはどうすればいいですか。
A. 稼働中のArtifactoryのバージョン番号を、CVE-2026-42016は7.133.11、CVE-2026-42018は7.111.20・7.117.27・7.125.19・7.133.28・7.146.8、CVE-2026-82329は7.111.21・7.117.28・7.125.20・7.133.29・7.146.38・7.161.20と照合する[3]。判断が難しい場合はJFrogサポートに直接問い合わせるのが確実だ。
Q. パッチさえ当てれば安全になりますか。
A. いいえ。パッチは今後の侵入経路を塞ぐだけで、すでに侵入されていた場合に作成された管理者アカウントやバックドアは残る。パッチ適用と合わせて過去ログの遡及調査が必要だ。
