JFrog ArtifactoryのCVE-2026-82329。既定構成のまま未認証で管理者権限を渡す認証不備

社内のビルドが取りに行くライブラリも、本番へ配る成果物も、多くの組織ではひとつのバイナリリポジトリを通ります。その機械の管理者権限が、資格情報を一切持たない相手にネットワーク越しで渡ってしまう。これがJFrogがCVE-2026-82329として公開した認証の弱点です。JFrogによる説明は「既定構成のもとで、ネットワークアクセスを持つ未認証の攻撃者が管理者権限を取得できる可能性がある」というものです。

JFrogは2026年8月28日にこの脆弱性を公開し、同じ日に6つのリリースブランチそれぞれの修正版を出しました。CISAは5日後の2026年9月2日、実際の悪用の証拠にもとづいてKnown Exploited Vulnerabilities(KEV)カタログへ追加し、是正期限を9月5日、つまり収録の3日後に設定しています。同じ日にKEVへ追加された7件のうち、収録3日後という短い期限と侵害調査の要件が両方付いたのは4件で、CVE-2026-82329はそのひとつです。

この記事は、Artifactoryを自社で運用している開発基盤担当と情報システム担当に向けて、CVEレコード、JFrogの公式アドバイザリとリリースノート、CISAのKEVカタログと拘束的運用指令、JFrogの製品ドキュメントという一次情報をもとに、何が起きるのか、どの版まで上げるのか、侵害の有無をどう確かめるのかを整理します。攻撃を再現する手順は扱いません。設定変更や調査は自組織が管理する環境に限って行ってください。記述は執筆時点(2026年9月4日)に確認できた範囲に限ります。

バイナリリポジトリの管理者権限が届く範囲#

Artifactoryが置かれている位置を先に確認します。JFrogのドキュメントによれば、リモートリポジトリは外部のURLで管理されているリポジトリに対するキャッシュプロキシとして働きます。クライアントが要求した時点で成果物が取得されてキャッシュに保存される仕組みで、事前に丸ごと同期されるわけではありません。社内のビルドがnpmやMavenやコンテナイメージを取得するとき、実体としてはArtifactoryのリモートリポジトリを経由します。

同じ機械には、社内で作った成果物を置くローカルリポジトリと、複数のリポジトリをひとつのURLでまとめる仮想リポジトリも同居します。つまりこの1台は、外から入ってくる部品と、中から出ていく配布物の両方が通る場所です。管理者権限を持つ相手は、リポジトリの構成を変え、新しいリモートリポジトリを追加し、利用者とグループと権限ターゲットを作り、アクセストークンを発行できます。

供給網の脅威モデルとしては、これはSLSAの分類で言う配布経路への攻撃にあたります。SLSA v1.1の脅威一覧は、(G) Distribution channelを「攻撃者が管理インタフェースを使って、またはインフラの侵害によって、パッケージレジストリ上のパッケージを改変する。利用者へ届く途中での改変を含む」と定義しています。CVE-2026-82329が与えるものは、まさにその管理インタフェースです。

被害の広がり方は、Artifactoryそのものの停止ではありません。汚染された成果物を引いたビルドが成功し、その出力がまた別のビルドに引かれ、最終的に本番へ届くという連鎖です。気づくのが遅れるほど、遡って洗い直す範囲が増えます。ソフトウェア供給網への攻撃の型そのものは、次の記事で整理しています。

SLSA v1.1のThreats & mitigationsは、供給網の脅威を(A)から(I)までの位置で分類しています。(G) Distribution channelの定義は「攻撃者が管理インタフェースを使って、またはインフラの侵害を通じて、パッケージレジストリ上のパッケージを改変する。利用者へ送られる途中でのパッケージの改変を含む」です。この分類の脅威は消費側の検証によって緩和されるとされ、緩和策として、期待するビルダーからのprovenanceまたはVSAを要求すること、provenanceやVSAのsubjectがパッケージのハッシュと一致することを確認することが挙げられています。

公開された事実を一次資料でそろえる#

CVEレコードを直接見ると、この脆弱性の基本情報が確定できます。cveawg.mitre.orgのAPIで取得できるレコードは、割り当て組織の短縮名がJFROG、予約日が2026年8月28日14時26分(UTC)、公開日が同日18時27分(UTC)です。CNAが付けたタイトルは「Potential authentication bypass leading to administrative access in Artifactory」で、日本語にすると「Artifactoryにおける管理者アクセスにつながりうる認証迂回の可能性」となります。

主要な値を並べると次のようになります。

CVEレコードの説明文は1文だけです。「JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.」つまり、既定構成という条件のもとで、ネットワークアクセスを持つ未認証の攻撃者が管理者権限を得られる可能性がある、という記述です。押さえたいのは「既定構成のもとで」という限定で、特別な設定を入れた環境だけの話ではありません。

CVEレコードが挙げるベンダー参照は2件で、JFrogのセキュリティアドバイザリ一覧と、Artifactoryの自己管理版リリースノートです。NVDにも同日に登録されており、執筆時点のvulnStatusはAnalyzedです。

CVE-2026-82329のCVEレコード(dataVersion 5.2)は、assignerShortNameがJFROG、dateReservedが2026-08-28T14:26:47Z、datePublishedが2026-08-28T18:27:43Zです。problemTypesにCWE-287 Improper Authentication、metricsにCVSS v3.1のbaseScore 9.8とvectorString CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H が記録されています。affectedはvendor jfrog、product artifactory、defaultStatus unaffectedで、6つのバージョン範囲が列挙されています。ADPコンテナにはCISAのVulnrichmentによるSSVC(Exploitation: active、Automatable: yes、Technical Impact: total、timestamp 2026-09-02)と、KEV追加日2026-09-02の記録が含まれます。

影響を受ける版と修正版を取り違えない#

この案件で実務上いちばん間違えやすいのが版番号です。Artifactoryは複数のリリースブランチを並行して保守しており、修正版もブランチごとに別々の番号になります。CVEレコードのaffectedと、JFrogのアドバイザリに載っているPatched Versionの表を突き合わせると次のとおりです。

修正版はいずれも2026年8月28日にリリースされています。注意すべき点が3つあります。

1つ目は7.146系です。JFrogのアドバイザリの一覧表は影響範囲を「7.146.0 > 7.146.36」と表記していますが、同じアドバイザリの詳細セクションにあるPatched Versionの欄は7.146.38で、CVEレコードのlessThanも7.146.38です。自己管理版のリリースノートでは7.146.36の次の項目が7.146.38で、7.146.37という項目は存在しません。この食い違いから、二次的な記事では7.146.37を修正版として記載しているものがあります。ベンダーのPatched Version欄とCVEレコードが一致する7.146.38を採るのが妥当です。

2つ目は7.111系の下限です。CVEレコードは「version 0、lessThan 7.111.21」と記録しており、7.111.21より前のすべてが対象という書き方です。一方でNVDが生成したCPE照合条件はversionStartIncludingを7.111.4としており、JFrogのアドバイザリの一覧表も「7.111.4 > 7.111.21」と書いています。7.111.4より前の版は機械的な照合で対象外と判定されることがありますが、そもそも保守対象から外れている可能性が高い版です。番号の下限で安心せず、保守されているブランチの最新パッチへ上げる判断をします。

3つ目はクラウド版の扱いです。JFrogのアドバイザリは、クラウド環境について「影響を受けたクラウド環境はすでに対処済みであり、クラウドインスタンスについて必要な操作はない」と書いています。作業が必要なのは自己管理の環境です。ただしこれは脆弱性そのものの修正についての記述であり、自組織のテナントで管理者トークンや利用者が不正に作られていないかという確認は、契約形態にかかわらず別の作業として残ります。

JFrogのSecurity Advisoriesページは、CVE-2026-82329の深刻度をCritical、CWEをCWE-287 Improper Authentication、公開日と更新日をどちらも2026年8月28日としています。Affected Productsの表は6行あり、Patched Versionの列にそれぞれ7.161.20、7.146.38、7.133.29、7.125.20、7.117.28、7.111.21が記載されています。How to Fixの項目は「Cloud Environment: 影響を受けたクラウド環境はすでに対処済みです。クラウドインスタンスについて必要な操作はありません」「Self-Hosted Environment: 自分のリリースブランチに対応する修正版へアップグレードしてください」と分けて書かれています。

Artifactory Self-Managed Releasesのページには、7.161.20、7.146.38、7.133.29、7.125.20、7.117.28、7.111.21の6つの項目があり、いずれもReleasedが2026年8月28日です。各項目のCVEs Addressedの表にはCVE-2026-82329が1件だけ載り、ComponentはGeneral、SeverityはCriticalです。7.146系の一覧は7.146.35、7.146.36、7.146.38の順に並んでおり、7.146.37の項目はありません。

CVSS 9.8とSSVCが示している内容の違い#

ベクトルを分解すると、この評価の意味がはっきりします。AV:Nはネットワーク経由で到達できること、AC:Lは特別な条件がいらないこと、PR:Nは事前の権限が不要なこと、UI:Nは利用者の操作が不要なことを表します。ここまでで前提条件が何もないという評価になり、NVDが計算したexploitabilityScoreは満点の3.9です。影響側はC:H/I:H/A:Hで、機密性と完全性と可用性のすべてが高、impactScoreは5.9です。合計してベーススコアは9.8になります。

このCVSSはJFrogが付与した値で、NVDでもtypeがSecondary、sourceがreefs@jfrog.comとして記録されています。ベンダー自身が最高クラスの評価を付けた点は、内容を読むうえでの補助線になります。

一方、CISAが付与しているのはSSVCという別の枠組みの判定です。CISAのADPが記録した値はExploitation: active、Automatable: yes、Technical Impact: totalの3つです。順に、悪用が実際に起きていると判断していること、攻撃に必要な手順を攻撃者が全自動化できると判断していること、悪用後に資産を完全に掌握されると判断していること、を意味します。

BOD 26-04の本文は、この完全な掌握(total control)を「攻撃がソフトウェアの挙動に対する完全な制御を攻撃者へ与えること。ログイン資格情報を確実に露出させる場合を含む」と定義しています。CVSSが技術的な深刻度の数値であるのに対し、SSVCの3つの答えは対応の速さを決めるための判断で、目的が違います。CVSSが9.8だからではなく、Automatableがyesだから、スキャンで見つかった瞬間に一斉に狙われうる、という読み方をします。

Artifactoryは外部からの到達性が高くなりやすい製品でもあります。JFrogのドキュメントによれば、外部のクライアント(UI、REST API、CLI、CI/CD)はロードバランサを経由してArtifactoryのRouterサービスへ接続し、Routerは既定でポート8082を待ち受けます。社外のCIランナーからの利用を通すために、この入口をインターネットへ向けている構成は珍しくありません。AV:Nという評価が実務上そのまま効くかどうかは、この配置で決まります。

NVDに登録されたCVE-2026-82329は、sourceIdentifierがreefs@jfrog.com、公開日時が2026-08-28T20:20:21、執筆時点のvulnStatusはAnalyzedです。cvssMetricV31にはJFrogによるSecondary評価としてベーススコア9.8が記録され、exploitabilityScoreは3.9、impactScoreは5.9です。CISA由来の項目としてcisaExploitAddが2026-09-02、cisaActionDueが2026-09-05として記録されています。CPEの照合条件は6区間で、最初の区間はversionStartIncludingが7.111.4、versionEndExcludingが7.111.21です。

KEVへの収録と3日という是正期限#

CISAのKEVカタログは、実際の悪用が確認された脆弱性の一覧です。執筆時点で参照できる版はcatalogVersion 2026.09.02、リリース日時は2026年9月2日16時54分(UTC)、収録件数は1694件です。この日に追加された7件を並べると、期限の付き方に差があることが分かります。

期限が収録の3日後になっている5件はforensicTriageがYes、14日後の2件はNoです。BOD 26-04の本文には、表の中の「& forensic triage」という表記について「期限(3日)以内に修正または緩和を完了し、あわせてその資産が侵害されているかどうかを評価するためのフォレンジックトリアージを実施しなければならない」という説明があります。forensicTriageがYesとは、CISAが「直すだけでは足りず、すでに入られていないかを確かめること」を求める水準だと判断した、という意味です。

BOD 26-04が是正期限を決める変数は4つです。資産が公開されているか、KEVに載っているか、攻撃を自動化できるか、悪用後の技術的影響が部分的な制御か完全な掌握か。CVE-2026-82329はKEV掲載、自動化可能、完全掌握という3つがそろっているため、公開資産では最短の区分に落ちます。

拘束の範囲も押さえておきます。BOD 26-04は44 U.S.C. 3552(b)(1)および3553を根拠とする拘束的運用指令で、対象はFederal Civilian Executive Branch(米国の連邦文民行政機関)の情報システムです。法律で定義された国家安全保障システムや、国防関連および情報コミュニティの一部システムには適用されません。

したがって2026年9月5日という日付は、日本の組織を法的に拘束するものではありません。日本の組織にとっての価値は別のところにあります。CISAが実際の悪用を確認したと判断した事実と、直すだけでなく侵害調査まで求める水準だと判断した事実の2つです。この2つは、社内で対応の優先度を上げるための客観的な根拠として使えます。KEVとEPSSを日々の優先度付けへ組み込む方法は、次の記事で整理しています。

CISAのKEVカタログのJSONフィードは、執筆時点でcatalogVersion 2026.09.02、dateReleased 2026-09-02T16:54:39Z、count 1694です。CVE-2026-82329のエントリは、vendorProjectがJFrog、productがArtifactory、vulnerabilityNameが「JFrog Artifactory Improper Authentication Vulnerability」、dateAddedが2026-09-02、dueDateが2026-09-05、knownRansomwareCampaignUseがUnknown、forensicTriageがYes、cwesがCWE-287です。requiredActionは「ベンダーの指示に従って緩和策を適用し、CISAのBOD 26-04およびForensics Triage Requirementsの指針への準拠を確保すること。クラウドサービスについては該当するBOD 26-04の指針に従い、緩和策が利用できない場合は製品の使用を中止すること」と記載されています。

BOD 26-04は、是正の緊急度を決める変数として、資産が公開されているか(Asset Exposure)、KEVカタログに載っているか(KEV Status)、攻撃に必要な手順をすべて自動化できるか(Exploit Automation)、悪用後に攻撃者が得るのは部分的な制御か完全な掌握か(Technical Impact)の4つを挙げています。Total controlの定義は「攻撃がソフトウェアの挙動に対する完全な制御を攻撃者へ与えること。ログイン資格情報を確実に露出させる場合を含む」です。表中の「& forensic triage」は、期限(3日)以内に修正または緩和を完了し、あわせて資産が侵害されているかを評価するフォレンジックトリアージを実施することを意味します。適用範囲はFederal Civilian Executive Branchの情報システムで、法律上の国家安全保障システムや一部の国防および情報コミュニティのシステムには適用されません。

悪用の観測について確認できること#

一次資料として確認できる悪用の事実は、CISAのKEVカタログへの収録と、CISAのADPが記録したSSVCのExploitation: activeです。CISAは2026年9月2日の告知でも、7件の追加は「実際の悪用の証拠にもとづく(based on evidence of active exploitation)」と述べています。KEVカタログには具体的な攻撃者や手口の記載はありません。

これ以上の詳細は、執筆時点で確認できる範囲が限られます。攻撃観測を扱う企業であるwatchTowrが、CVE-2026-82329の悪用を観測しており攻撃者が自分用の管理者トークンを発行している、という趣旨の投稿を自社アカウントで行い、複数のニュース媒体がそれを引用して報じています。ただし、執筆時点でwatchTowrの技術ブログに本件の解析記事は見当たらず、観測の詳細を一次資料として確認することはできませんでした。報道が伝える利用者の列挙やバックドア利用者の作成といった事後活動も、同じ理由でここでは断定しません。

対応の判断としては、この不確実性は障害になりません。CISAがforensicTriageをYesとして収録した時点で、修正の適用と侵害の確認を並行して進めるという結論は変わらないためです。攻撃の詳細が公開されていないことを前提に、自分の環境のログで何が起きたかを見る作業へ時間を割いたほうが確実です。

認証の弱点はサービス間の信頼の入口に効く#

JFrogのアドバイザリは、脆弱性そのものの説明を1文に留めています。ただし、暫定策の記述から、この弱点がJFrog Platformのどの層に関係しているかは読み取れます。アドバイザリが示す暫定策は、system.yamlのshared.security配下にadditionalJoinKeysという設定を追加し、Accessサービス(またはJPD全体)を再起動するというものです。そして、この暫定策の説明として「サービス登録で自分自身の鍵だけが受け入れられるようにするためのもの」であり「既存のjoin keyは引き続き有効なのでクラスタの動作には影響しない」と書かれています。

join keyはAES(128ビットまたは256ビット)の対称鍵で、JFrogの各サービス間の信頼を確立するために使われます。たとえばArtifactoryとAccessのようなマイクロサービス間で使われ、各サービスはトークンを作ってこのjoin.keyで署名します。join.keyが一致していなければサービス間通信は失敗します。既定ではArtifactoryの初回起動時に自動生成され、暗号化された鍵が $JFROG_HOME/artifactory/var/etc/security/join.key に置かれます。

ここから言えるのは、この認証の弱点がサービス登録の経路、つまりAccessサービスが「これは自分たちの仲間のサービスだ」と判断する部分に関係するということです。JFrogが公開していない実装の詳細まで踏み込んで断定はしませんが、暫定策が追加のjoin keyの検証であるという点は、公開されている事実として押さえておく価値があります。

CWEの分類がCWE-287 Improper Authenticationであることも、この読み方と整合します。認証が完全に欠けているCWE-306(Missing Authentication for Critical Function)ではなく、証明の仕方に不備があるという上位の分類が選ばれています。

なお、JFrogのドキュメントによれば、pairing tokenは以前join keyが担っていたトポロジ間の紐付けを置き換えるもので、既定の有効期限は300秒、ペアリングの結果として発行されるmaster tokenは長期のアクセストークンです。管理者はこのmaster tokenを失効させることで信頼を取り消せます。侵害を疑う場合、join keyだけでなくこの系統のトークンも棚卸しの対象になります。

JFrogのManage Keysのページは、join keyを「対称暗号(AES-128ビットまたはAES-256ビット)にもとづいてJFrogサービス間の信頼を確立するもの」と定義し、「join.keyは同一サービスのマイクロサービス間、たとえばArtifactoryとAccessの間で使われる」と説明しています。信頼の確立手順として、join keyがすべてのJFrogサービス間で共有されること、各サービスがトークンを作成してjoin.keyで署名することを挙げています。暗号化された鍵の保存先は $JFROG_HOME/artifactory/var/etc/security/join.key で、既定ではjoin.keyとmaster.keyは初回起動時に自動生成されます。鍵の生成には openssl rand -hex 16 または openssl rand -hex 32 が示されています。

CWE-287 Improper Authenticationは抽象度がClassの弱点で、定義は「ある行為者があるアイデンティティを持つと主張したとき、製品がその主張が正しいことを証明しない、または証明が不十分である」です。子となるBase相当の弱点として、CWE-290(なりすましによる認証迂回)、CWE-294(キャプチャとリプレイによる認証迂回)、CWE-306(重要な機能に対する認証の欠如)、CWE-798(ハードコードされた資格情報)、CWE-1390(脆弱な認証)などが並びます。Common Consequencesは、影響が「アプリケーションデータの読み取り、権限の獲得またはアイデンティティの詐称、認可されないコードやコマンドの実行」です。

最初の数時間で決める順番#

パッチを当てる操作は、侵害の痕跡を消してしまうことがあります。CISAのBOD 26-04実装ガイダンスは、証拠の収集を修正より先に置き、「可能な場合は、証拠や成果物の収集前にシステムを変更したり修正したりしないこと」と明記しています。急ぎながらも、順番だけは崩さないようにします。

CISAのBOD 26-04実装ガイダンスは、フォレンジックトリアージを6つの段階に分けています。Step 1はスコーピング(KEV追加から2時間以内が目安)で、対応チームの立ち上げ、影響範囲の特定、侵害されている可能性のあるインフラに依存しない帯域外の連絡手段の確保を求めます。Step 2は証拠の保全と収集(2時間から24時間)で、揮発性データの取得を最優先とし、「可能な場合は、証拠や成果物の収集前にシステムを変更したり修正したりしない」と明記しています。以降はStep 3が重要なパッチ適用と安定化、Step 4が封じ込めと制御、Step 5がトリアージ分析、Step 6がエスカレーション判断です。これらの時間はあくまで推奨であり、BOD 26-04の要件は適切なフォレンジックトリアージが行われることだと注記されています。

更新できない場合の暫定策#

JFrogのアドバイザリは、修正版へのアップグレードが最善の対処であるとしたうえで、すぐに上げられない場合の回避策を1つ示しています。追加のjoin keyを設定する方法です。まず、既存のjoin keyと同じ形式のランダムな16進文字列を生成します。アドバイザリが挙げている生成方法は次の2つです。

# 方法A: OpenSSL(推奨)
openssl rand -hex 16

# 方法B: Python
python3 -c "import secrets; print(secrets.token_hex(16))"

生成した値は、join keyと同じ水準の秘密として扱います。設定は system.yaml の shared.security 配下に追加します。

shared:
  security:
    # 既存の join key はそのまま残し、下の行を追加する
    # join key と同じ形式の強くランダムな値を使う
    additionalJoinKeys: "<生成した強いランダム値>"

すでに shared.security 配下に joinKey などの項目がある場合は、それらを残したまま additionalJoinKeys の行だけを足します。sharedやsecurityの見出しを二重に書かないよう注意します。複数の鍵はカンマ区切りで並べます。コンテナやHelmでの運用では、同等の環境変数 JF_SHARED_SECURITY_ADDITIONALJOINKEYS を使う方法があります。反映にはAccessサービス(またはJPD)の再起動が必要です。アドバイザリはこの回避策について、サービス登録で自分自身の鍵だけが受け入れられるようにするためのものであり、既存のjoin keyは引き続き有効なのでクラスタの動作には影響しない、と説明しています。

秘密情報を構成ファイルや環境変数でどう扱うかという設計の話は、次の記事で整理しています。

アクセストークンと鍵の棚卸し#

管理者権限を取られた場合に真っ先に疑うのはアクセストークンです。ここには、失効の可否に関わる仕様上の制約があります。JFrogのドキュメントによれば、トークンの既定の有効期限は3600秒(1時間)で、ゼロを指定すると期限なしのトークンになり、明示的に失効させるまで有効です。さらに revocable-expiry-threshold という設定があり、既定値は6時間(21600秒)です。設定された有効期限がこの閾値より短いトークンは失効させられず、自然に期限切れになるのを待つことになります。

トークンの一覧はGet Token APIで取れます。応答には token_id、subject、expiry、issued_at、issuer、description、refreshable といった項目が含まれ、issued_at を見れば疑わしい期間に発行されたトークンを抜き出せます。個別の失効で追いつかない場合は、トークン証明書のリセットという手段があります。reset_root_keys という名前のファイルを <VAR>/bootstrap/etc/access/keys/ へ置いてサービスを再起動する手順で、JFrogのドキュメントは「生成済みのすべてのトークンが実質的に失効する」と記載しています。正規のCI/CDや開発者のトークンも止まりますので、周知と再発行の段取りを先に組みます。

棚卸しの対象はトークンだけではありません。整理すると次のようになります。

最後の行を落とさないでください。Artifactoryは、上流のプライベートレジストリへ接続するための資格情報や、レプリケーション用の資格情報を保持していることがあります。管理者権限を取られたなら、その先の系も疑いの範囲に入ります。

JFrogのAccess Tokensのページは、トークンの既定の有効期限を3600秒(1時間)とし、expiryをゼロに設定すると期限なしのトークンになり、明示的に失効させるまで有効だと記載しています。revocable-expiry-thresholdは失効可能性を決める閾値で、既定値は6時間(21600秒)です。有効期限がこの閾値より短いトークンは失効させられず、設定された期限に達して失効します。トークン証明書については、reset_root_keys という名前のファイルを <VAR>/bootstrap/etc/access/keys/ に置いてサービスを再起動するとリセットでき、「トークン証明書のリセットは生成済みのすべてのトークンを実質的に失効させる」と明記しています。Get Token APIの応答には token_id、subject、expiry、issued_at、issuer、description、refreshable が含まれます。

監査ログで侵害の痕跡を確かめる#

Artifactoryは、侵害調査に使える記録を複数のファイルへ分けて出力します。いずれも $JFROG_HOME/artifactory/var/log 配下にあり(アクセスログのみ var/artifactory/log 配下)、まずどこに何が入っているかを押さえます。

この案件でいちばん効くのは1行目の監査証跡ログです。Artifactory 7.131.0以降ではアクセス設定の変更も記録されます。フォーマットはパイプ区切りで、次の並びです。

Date | Trace ID | User IP | User | Logged Principal | Entity Name | Event Type | Event | Data Changed

Event Typeは操作の種類で、Cが作成、Uが更新、Dが削除です。Eventは操作された対象で、USRが利用者、GRPがグループ、PRMが権限、TKNがトークンです。したがって、疑わしい期間に発行されたトークンは |C|TKN| を含む行、新しく作られた利用者は |C|USR| を含む行として抜き出せます。

この案件の調査で押さえておくべき性質がひとつあります。JFrogのドキュメントは、User IPとUserの項目について「操作が内部サービストークンで実行された場合、値はunknownとして表示される」と説明しています。サービス間の信頼を悪用して行われた操作は、実行者の名前もIPも残らない可能性があるということです。利用者名がunknownの行が通常より多い時間帯がないか、という見方が必要になります。

抽出は調査用のコピーに対して行い、原本には触れないようにします。

# 監査証跡ログからトークン作成の行を抜く
grep -E '\|C\|TKN\|' access-security-audit.log

# 利用者の作成と更新、グループの作成を抜く
grep -E '\|[CU]\|(USR|GRP)\|' access-security-audit.log

# 実行者が特定できない行(内部サービストークン経由)の日付別件数
grep -E '\|unknown\|unknown\|' access-security-audit.log \
  | cut -c1-10 | sort | uniq -c

アクセスログのほうは、認証の結果と操作の種類が見えます。レコードにはACCEPTEDまたはDENIEDという応答と、DOWNLOAD、DEPLOY、DELETE、LOGIN、CONFIGURATION_CHANGEなどの操作種別が入り、末尾に利用者名とIPアドレス、認証方式(APIKEYまたはTOKEN)が付きます。CONFIGURATION_CHANGE の行を時系列で並べると、攻撃者が構成に手を入れた時刻の見当が付きます。

結果を読むときの注意が3つあります。1つ目は、監査証跡ログは管理者権限があればREST APIで無効化できる点です。JFrogのドキュメントは PATCH /access/api/v1/config で security.audit.enabled をfalseにできると記載しています。ログが途中で途切れているなら、それ自体が調べる価値のある事象です。2つ目は保持期間で、既定は最大100MBのファイル10本、合計1GBまでです。試行の時期がこの範囲より前なら記録は残っていません。3つ目は、痕跡が見つからないことが安全の証明にはならない点です。

依存関係の把握とログの保全をどう設計するかは、次の記事で整理しています。

JFrogのAudit Trail Logのページは、監査証跡ログの場所を $JFROG_HOME/artifactory/var/log/access-security-audit.log とし、記録される操作として利用者、グループ、権限ターゲット、アクセストークンの作成と更新と削除、そしてArtifactory 7.131.0以降はアクセス設定の更新を挙げています。エントリの形式は「Date | Trace ID | User IP | User | Logged Principal | Entity Name | Event Type | Event | Data Changed」で、Event TypeはC(作成)、U(更新)、D(削除)、EventはUSR(利用者)、GRP(グループ)、PRM(権限)、TKN(トークン)です。User IPとUserについては「内部通信にのみ使われる内部サービストークンで操作が実行された場合、unknownとして表示される」と記載されています。ログの既定サイズは1GBで、最大100MBのファイル10本に分割されます。監査証跡ログは既定で有効で、PATCH /access/api/v1/config で切り替えられます。

JFrogのAccess Logのページは、アクセスログを「送信元IPと文脈を含む、すべてのセキュリティ関連イベント」を記録するものと説明し、場所を $JFROG_HOME/artifactory/var/artifactory/log/artifactory-access.log としています。レコードの構造は「Timestamp(UTC) [Trace Id] [Action response and type] Repository path(任意) Message(任意) User name/IP type(任意)」で、応答はACCEPTEDまたはDENIED、操作の種類としてANNOTATE、DOWNLOAD、DEPLOY、DELETE、SEARCH、LOGIN、CONFIGURATION_CHANGE、CREATE、UPDATEなどが列挙されています。利用者名は匿名アクセスの場合anonymousとなり、Typeの項目には認証方式としてAPIKEYまたはTOKENが入ります。

リポジトリ設定と成果物の側を確認する#

権限まわりの記録を見終えたら、次はリポジトリの構成と成果物です。管理者権限を持つ相手ができる操作のうち、供給網へ直接効くのはこの部分です。

見る対象は次の順です。まず、リモートリポジトリの一覧と、それぞれのURLです。上流URLを差し替えられていれば、以後そのリポジトリ経由で引かれる依存関係は、攻撃者が用意した先から来ることになります。既存のリポジトリのURL変更と、見覚えのないリポジトリの新規作成の両方を確認します。

次に、外向きリクエストのログです。artifactory-request-out.log には、リモートリポジトリやレプリケーションが起点となった外向きのリクエストが記録されます。宛先ホストの一覧を取り、想定している上流レジストリだけかどうかを照合します。

# 外向きリクエストの宛先を集計する
grep -oE 'https?://[^/|]+' artifactory-request-out.log \
  | sort | uniq -c | sort -rn | head -50

続いて、キャッシュされた成果物です。リモートリポジトリのキャッシュには <リポジトリ名>-cache という形でアクセスでき、保存済みの成果物を直接参照できます。上流の公式レジストリから取得したハッシュと突き合わせれば、差し替えの有無を確認できます。対象が多い場合は、疑わしい期間に新しくキャッシュされたものと、ビルドで実際に使われたものへ絞ります。

最後に、社内で作った成果物を置くローカルリポジトリです。リリース済みのバイナリが上書きされていないかは、配布先に残っているコピーやCI側のビルド出力と照合するのが確実です。ビルド情報(build info)を残しているなら、そのビルドが生成したはずのチェックサムと実物を比較します。

汚染されたパッケージが自動で広がる形の攻撃は、npmのエコシステムで実際に起きています。似た構図の実例は次の記事で扱っています。

JFrogのRemote Repositoriesのページは、リモートリポジトリを「リモートURLで管理されているリポジトリに対するキャッシュプロキシとして働く」ものと定義しています。リモートリポジトリへ新しい成果物をデプロイすることはできず、キャッシュから削除することだけができます。成果物へは http://<host>:<port>/artifactory/<remote-repository-name>/<artifact-path> の形式でアクセスでき、すでにキャッシュにあるものへ直接アクセスする場合は <remote-repository-name>-cache を使います。同ページは「リモートリポジトリはミラーではなくプロキシとして動作する。成果物は事前取得されず、クライアントが要求したときにのみ取得されキャッシュされる」と明記しています。

汚染された可能性のある成果物をどう扱うか#

侵害の確証が得られなくても、疑いが残る期間の扱いは決めておく必要があります。判断の材料になるのは期間の絞り込みです。上限は、脆弱な版を外部から到達できる位置に置いた時点か、JFrogの公開日である2026年8月28日のいずれか遅いほうです。ただし公開前の悪用を完全に排除するには、脆弱な版を運用し始めた時点まで遡る必要があります。下限は、修正版を適用した時刻か外部到達を遮断した時刻です。この期間に取得または生成された成果物が確認の対象になります。

対応の重さは、対象がどこへ届いたかで変えます。開発環境でだけ使われた依存は、上流の公式レジストリのハッシュと照合し、疑いが晴れなければキャッシュを削除して取り直します。本番へ配った自社成果物は、CI側のビルド出力や配布先のコピーと照合し、修正版を適用した環境で再ビルドして差し替えます。顧客へ配布した成果物は、配布時のチェックサムと現物を照合し、再配布と契約に応じた通知を検討します。コンテナイメージは、ベースイメージとレイヤのダイジェストを照合します。

照合を成り立たせるには、何がどのビルドから出たかという記録が要ります。SBOMを出力していれば、対象期間に作られた成果物がどの部品を含んでいるかを機械的に絞り込めます。持っていない場合、この作業は手作業の追跡になります。

再ビルドを行う場合は、順番に注意します。修正版の適用と権限まわりの掃除が終わっていない環境で再ビルドしても、同じ経路で汚染される可能性が残ります。修正、失効、再発行、再ビルドの順に進めます。

再発時に効く構えとして残すもの#

今回の対応が終わったあとに残しておくと、次に同じ種類の脆弱性が出たときの負担が変わる項目が5つあります。1つ目は、配置です。Artifactoryの入口であるRouterがインターネットへ直接向いている必要が本当にあるかを見直します。社外のCIランナーや協力会社の利用があるなら、送信元の制限や、認証済みのネットワーク経路を通す構成が取れないかを検討します。BOD 26-04が「公開されているか」を最初の変数に置いているのは、そこが是正の緊急度を最も大きく動かすからです。

2つ目は、ログの外部転送です。監査証跡ログは管理者権限で無効化できます。取られる側の機械の中だけに置いていると、侵害された時点で調査の材料そのものが操作されうる状態になります。SIEMやログ基盤へ転送しておけば、転送済みの分は残ります。

3つ目は、権限の定義をコードで持つことです。利用者、グループ、権限ターゲット、リポジトリ構成を構成管理に置いていれば、現物との差分を取るだけで勝手に増えたものが見えます。今回のような調査でいちばん時間を食うのは、正常な状態を思い出す作業です。

4つ目は、成果物の署名と検証です。SLSAの脅威一覧が配布経路への攻撃の緩和策として挙げているのは、利用者側での検証、つまりprovenanceや検証サマリの署名確認と、成果物のハッシュ照合でした。リポジトリの管理者権限が奪われうるという前提に立つなら、リポジトリの外で検証できる仕組みが要ります。

5つ目は、更新の運び方です。Artifactoryは複数のリリースブランチが並走する製品で、自分がどのブランチにいるかを把握していないと、修正版の番号を見ても判断できません。今回7.146.37と7.146.38の食い違いで混乱が起きたのは、この構造が背景にあります。運用中のブランチと、そのブランチの最新パッチ番号を確認する担当と頻度を決めておきます。

JFrogのSystem Architectureのページによれば、JFrog Platform Deployment(JPD)は自己管理のJFrog製品の配置単位で、JFrog Cloud(SaaS)ではJFrogが代わりに運用します。JPD内の各ノードは、製品の内部サービスとともにローカルのRouterを動かします。外部のクライアント(UI、REST API、CLI、CI/CD)はロードバランサ経由で接続し、ロードバランサはすべてのトラフィックをArtifactoryのRouterのポート8082へ振り分けます。Routerは既定でポート8082を待ち受け、プラットフォームのAPI呼び出しの主要な入口になります。

対応チェックリスト#

供給網の中心に置く機械を、外へ出したままにしない#

CVE-2026-82329が示しているのは、認証の弱点が1か所にあるだけで、その機械が担っていた信頼が丸ごと外れるという構図です。Artifactoryが持っていたのは、外から来る部品を仲介する役割と、中から出ていく配布物を保管する役割の両方でした。管理者権限が渡るということは、その両方の入口を渡すということです。

一次資料から確定できるのは、影響を受ける版と修正版、既定構成という条件、CVSSが9.8であること、CISAが実際の悪用を確認してKEVへ収録し、修正だけでなく侵害調査まで求める水準だと判断したこと、暫定策がサービス登録での鍵の受け入れを絞るものであることです。攻撃の詳細は執筆時点で公開されていませんが、対応の内容はそれによって変わりません。

作業の順番だけ、もう一度確認します。証拠を残す、外部からの到達を絞る、修正版を当てる、トークンと利用者を洗う、ログで確かめる。この5つです。そして対応が落ち着いたあとに、この機械が本当にインターネットへ向いている必要があったのか、監査ログはこの機械の外にも残っているのか、権限の正常な状態を定義した記録はあるのか、という3つを検討します。次に似た脆弱性が出たとき、そこに答えがあるかどうかで、費やす時間が変わります。