【ITニュース解説】When the Artifact Repository Is the Target: JFrog Artifactory and the Software Supply Chain Chokepoint

ソフトウェア開発の現場では、多くの部品やツールを組み合わせて一つの製品を作り上げる。このプロセスにおいて非常に重要な役割を果たすのが「アーティファクトリポジトリ」と呼ばれるシステムだ。これは、ソフトウェアのビルドに必要なライブラリ、パッケージ、コンテナイメージといった様々な部品を集中管理し、開発チームがいつでも信頼できる形で利用できるように保管しておく「倉庫」のようなものと考えると理解しやすい。JFrog Artifactoryは、このアーティファクトリポジトリを提供する代表的なツールの一つで、多くの企業で利用されている。ソフトウェアが作られる一連の自動化された工程であるビルドパイプラインは、このアーティファクトリポジトリが提供する部品を全面的に信頼して動作している。もし、この「信頼の源」であるリポジトリが攻撃を受けてしまうと、アプリケーションそのものを直接攻撃しなくても、そのアプリケーションが作られる元となる部品を改ざんされてしまう危険性がある。

今回、JFrog Artifactoryの自己ホスト型インスタンス（企業が自社のサーバーで運用しているもの）において、三つの重大な脆弱性が発見され、これらを組み合わせた実際の攻撃が観測された。一つ目は、CVSSスコア9.8という非常に高い深刻度を持つ「CVE-2026-82329」という認証不備の脆弱性だ。これは、Artifactoryのデフォルト設定において、認証情報を生成する際の仕組みに問題があり、攻撃者が管理者権限を持つトークンを勝手に作り出すことができてしまうというものだった。このトークンがあれば、攻撃者はプラットフォームの管理者として、ユーザーやグループの情報、認証情報、さらにはシステム全体の構成まで自由に閲覧、操作できる。 二つ目は、「CVE-2026-42018」（CVSS 7.5）という、これも認証に関する問題だ。この脆弱性を使えば、認証されていない外部の人間でも、匿名のユーザーとしてトークンを取得し、本来はアクセスできないはずの機密性の高いアーティファクトやリポジトリのデータにアクセスできてしまう。さらに、匿名アクセスが無効化されているはずの設定でも、この脆弱性は有効だったと報告されている。 そして三つ目は、「CVE-2026-42016」（CVSS 8.1）という権限昇格の脆弱性だ。これは、ユーザーのトークンの署名や発行元は正しく検証されるものの、そのトークンが持つ「スコープ」（利用できる範囲や権限）が適切に制限されていなかったという問題だ。このため、低い権限しか持たないはずのトークンでも、より高い権限の操作ができてしまう恐れがあった。

実際に観測された攻撃は、これら三つの脆弱性を巧みに組み合わせて実行された。攻撃者はまず、管理者権限を持つトークンを作成し、それを使って永続的なアクセス経路を確保した。具体的には、攻撃者自身の管理者アカウントを作成したり、そのアカウントにSSH公開鍵を登録して、いつでもアクセスできる状態にした。次に、Artifactoryが持つ「プラグイン」の仕組みを悪用し、悪意のあるプラグインをデプロイした。このプラグインは、任意のコードを実行できるバックドアとして機能し、さらなる悪意のあるプログラムをダウンロードして実行したり、持続的なアクセスを維持したりするために使われた。最後に、攻撃者はリポジトリの設定情報や、新しく作成したトークン、システム全体の暗号鍵などを外部に持ち出した。さらに、リポジトリに保存されている内容を全て把握しようと試みた。

この攻撃の最後のステップが、特に「下流」のシステム、つまりこのリポジトリを利用してソフトウェアを開発・運用している全ての組織にとって深刻な問題を引き起こす。一度攻撃者がアーティファクトリポジトリを乗っ取ってしまうと、リポジトリにキャッシュされている正規のパッケージを、悪意のある改ざんされたパッケージにすり替えることが可能になる。また、パッケージの公開に必要な認証情報を不正利用して、悪意のあるソフトウェアを正規のパッケージとして公開することもできてしまう。その結果、被害はリポジトリサーバー自体にとどまらず、そのリポジトリから部品を取り込んでビルドされる全てのソフトウェア、そしてそのソフトウェアを使うエンドユーザーにまで及んでしまうのだ。

このような事態を防ぐため、そして既に攻撃を受けてしまったかもしれない場合に取るべき対策はいくつかある。最も基本的な対策は、JFrog Artifactoryを修正済みの最新バージョンに早急にアップグレードすることだ。公式アドバイザリでは、特定のバージョンが修正済みとされているため、自社のArtifactoryが該当するバージョンに更新されているかを確認し、必要であればすぐにアップデートする必要がある。次に、対策が施される前に発行された全てのトークンや認証情報は、既に侵害されている可能性があるとみなし、全てローテーション（更新）することが重要だ。 さらに、管理者アカウントの監査も欠かせない。普段見慣れない管理者アカウントが作成されていないか、特に最近作成されたアカウントに不審な点がないかを確認し、また、本来SSH鍵が添付されるべきではないアカウントにSSH鍵が登録されていないかも徹底的にチェックすべきだ。攻撃の主な手口として悪意のあるプラグインのデプロイが確認されているため、インストールされているプラグインについても一つ一つ確認し、不審なものがないか検査する必要がある。 Artifactoryのアクセスログ、特にトークンの発行や管理者のアクションに関するログを定期的に確認することも重要だ。業務時間外の不審なリクエストや、普段利用しないようなIPアドレスからのトークン発行要求がないか、注意深く監視する必要がある。そして、最終的にビルドされて利用されるプロダクション環境のイメージやインストーラー、その他の成果物について、ハッシュ値や署名を比較し、意図しない変更が加えられていないかを検証することで、サプライチェーンの安全性を確認できる。

運用面で注意すべき点が二つある。一つは、Artifactoryをコンテナ環境でデプロイしている場合、単にホストサーバーのログを見るだけでは不十分な場合があるということだ。コンテナ内のログパスはインストールの方法によって異なるため、コンテナの内部にアクセスして関連するログを確実に確認する必要がある。二つ目は、もし不審な管理者アカウントや悪意のあるプラグインファイルを発見したとしても、すぐに削除してはいけないということだ。まずはその機能を無効化し、証拠としてそのままの状態で保存することが極めて重要だ。性急なクリーンアップは、攻撃の全貌を解明するための貴重な証拠を破壊してしまう可能性があり、攻撃者の特定や被害範囲の正確な評価を困難にしてしまう。

今回のJFrog Artifactoryの脆弱性は、ソフトウェアの「サプライチェーン」におけるアーティファクトリポジトリの構造的な重要性を浮き彫りにした。Artifactoryは、その設計上、全ての依存関係やイメージが一箇所で解決される「チョークポイント」（隘路）となっている。これは、運用効率を高める一方で、攻撃者にとっては非常に効率的な攻撃目標となることを意味する。今回のケースでは、修正パッチが提供されてから数週間もの間、多くのシステムが未対応のまま攻撃にさらされていたことが報告されている。 これほど広範な影響力を持つコンポーネントのセキュリティを確保するためには、単にパッチを適用するタイミングに依存しない、より強固な防御策を講じることが重要だ。例えば、一度作成されたら変更できない「イミュータブル（不変な）アーティファクト」の導入、ビルド時に署名を検証する仕組み、リポジトリの管理ネットワークとビルドネットワークを分離する設計、そして権限昇格が不可能な最小限の権限しか持たないトークンの利用などが挙げられる。これらは、仮に攻撃者が単一の認証バイパスに成功したとしても、そこから得られる利益を大幅に減少させ、被害の拡大を防ぐことにつながる。アーティファクトリポジトリのセキュリティは、現代のソフトウェア開発において不可欠な要素であり、継続的な監視と対策が求められる。