【ITニュース解説】Two Flaws, One Chain: How JFrog Artifactory Was Pushed to Admin

JFrog Artifactoryというソフトウェアシステムで発生した、非常に重大なセキュリティ問題について解説する。この問題は、二つの異なるセキュリティ上の欠陥が組み合わされて悪用されたことで、システムの管理者権限が攻撃者に奪われ、結果として悪意のあるプログラムが仕掛けられたというものだ。

まず、JFrog Artifactoryとは何かを理解する必要がある。これは、ソフトウェア開発において「アーティファクトリポジトリ」と呼ばれる重要な役割を担うシステムである。ソフトウェア開発では、プログラムのソースコードをコンパイルしたり、他の部品と組み合わせたりして、実際に動く「成果物（アーティファクト）」を作成する。例えば、JavaのMavenパッケージ、JavaScriptのnpmパッケージ、PythonのPyPIパッケージ、Dockerイメージ、KubernetesのHelmチャートといったものがこれに該当する。Artifactoryは、これらの成果物を一元的に管理し、開発チーム内で共有するための「倉庫」のような存在だ。開発プロセスの中で、自動的にプログラムを作成・テスト・配布する「ビルドパイプライン」と呼ばれる一連の流れは、Artifactoryから必要な成果物を取得し、また新しい成果物をそこに格納している。もしArtifactoryの管理者権限が攻撃者に奪われると、攻撃者はこの「倉庫」の中身を自由に改ざんしたり、ソフトウェアを公開するための認証情報（例えばパスワードやトークン）を不正に利用したりできるようになる。そうなると、Artifactoryから成果物を受け取るすべてのビルドプロセスや、それによって作られる最終的なソフトウェアにまで悪影響が及ぶことになり、これは「サプライチェーン攻撃」と呼ばれる広範囲な被害を引き起こす可能性がある。

今回の攻撃に利用されたのは、二つの異なるセキュリティ上の欠陥、すなわち「脆弱性」である。 一つ目は「CVE-2026-42018」と識別される脆弱性で、「不適切な認証処理」に分類される。これは「匿名ユーザーのトークン生成露出」という具体的な問題だ。通常、Artifactoryでは、ユーザー名やパスワードなしでのアクセス（匿名アクセス）を無効に設定できる。しかし、この脆弱性のあるバージョンでは、管理者が匿名アクセスを無効に設定していたにもかかわらず、特定の要求を認証なしでシステムに送るだけで、Artifactory内部の匿名ユーザーが使うための「トークン」（これは認証情報の一部であるJWTという形式のもの）を、攻撃者が取得できてしまうという問題があった。この要求には、ユーザーを特定する認証ヘッダーは不要だった。この脆弱性があるシステムでは、通常のリクエストパスではアクセス拒否（401エラー）となるが、パスの形式をわずかに変える（例えば、末尾にスラッシュを追加する）だけで、トークンが返されてしまう（200成功）という特徴的な挙動が見られた。

二つ目は「CVE-2026-42016」という識別子の脆弱性で、「承認エラー」に分類される。この脆弱性は、Artifactoryがユーザーのトークンを検証する際に、そのトークンが正当なものか、誰によって発行されたかといった基本的な確認は行っていたものの、そのトークンが「どれくらいの範囲の権限を持つべきか」という、本来最も重要な部分の制限が不十分だったことに起因する。この不備により、本来は限定的な権限しか持たないはずの「低権限トークン」が悪用されると、管理者権限のようなより高い権限を不正に取得できてしまう可能性があった。この脆弱性単体では、攻撃者が利用できるトークンを事前に持っていない限り悪用は難しい。しかし、ここで一つ目の脆弱性が決定的な役割を果たす。

これら二つの脆弱性が組み合わされることで、恐ろしい「連鎖」が完成する。まず攻撃者は、一つ目の脆弱性（CVE-2026-42018）を利用して、認証なしでArtifactory内部の匿名ユーザートークンを取得する。次に、この取得した匿名ユーザートークンを二つ目の脆弱性（CVE-2026-42016）に悪用し、本来の権限を超えて、最終的にArtifactoryの「管理者権限」を奪い取る。この一連の攻撃には、ユーザー名やパスワードは一切必要ない。どちらか一方の脆弱性を修正するだけでも、この攻撃連鎖は断ち切られることが確認されている。

この脆弱性の影響を受けるArtifactoryのバージョンは、それぞれで異なるため、修正版へのアップデートは非常に注意深く行う必要がある。例えば、CVE-2026-42016はバージョン7.133.11より前のものが影響を受け、7.133.11で修正された。一方、CVE-2026-42018は、複数のバージョンブランチ（7.111.x系、7.117.x系、7.125.x系、7.133.x系、7.146.x系など）で影響を受け、それぞれ異なる修正バージョンがリリースされている。古いブランチを利用している場合、最新の修正バージョンに更新しても、片方の脆弱性しか修正されない可能性もあるため、自身のシステムが利用しているブランチに合わせた修正バージョンを正確に確認し、不明な点があれば必ずベンダーに問い合わせることが重要だ。これら二つの脆弱性は、Artifactoryの開発元によって危険度が「高（High）」と評価されている。

攻撃者がArtifactoryの管理者権限を奪取した後、どのような行動をとったかについて見てみよう。観察された攻撃のパターンは、ほぼ一貫していた。まず、攻撃者は管理者権限を持つ新しいアカウントをシステム内に作成し、そのアカウントに自身のSSH公開鍵を追加することで、その後も継続的にシステムへアクセスできる手段を確保した。次に、悪意のある「プラグイン」をデプロイした。Artifactoryにはシステム機能を拡張するためのプラグイン機構があり、攻撃者はこれを利用して任意のプログラムコードを実行させ、システムにバックドアとなる不正なプログラムを仕掛けたのだ。そして最後に、重要なデータの持ち出し（情報流出）を行った。具体的には、Artifactoryの設定情報、攻撃者が新たに生成したトークン、システムを構成するためのクラスターキーなどがエクスポートされ、リポジトリに保存されている成果物（資産）のリストも収集された。

このデータ流出のステップこそが、単なるサーバーの乗っ取り問題を、先に述べた「サプライチェーン問題」へと発展させる。攻撃者がArtifactory内のキャッシュされているパッケージを置き換えることができれば、そのArtifactoryからパッケージを取得してソフトウェアのビルドを行うすべての下流のシステムは、改ざんされた、悪意のある成果物を自動的に利用してしまうことになる。その影響は、Artifactoryサーバー単体にとどまらず、そこから引き出されるあらゆるソフトウェアやシステムへと広がっていくのだ。

このような攻撃からシステムを守るためには、いくつかの重要な点を確認し、適切に対応する必要がある。 まず、現在稼働しているArtifactoryのバージョンが、ベンダーが公開している修正済みバージョンと正確に一致しているかを検証する。次に、Artifactoryのユーザーリストを精査し、最近作成された不審な管理者アカウントがないかを調べる。また、Artifactoryのプラグインが格納されているディレクトリを検査し、見慣れない、あるいは悪意のある可能性のあるプラグインがデプロイされていないかを確認することも非常に重要だ。さらに、Artifactoryのアクセスログを定期的にレビューし、匿名トークンの取得を試みるようなトークンエンドポイントへの不審な呼び出しや、見慣れないIPアドレスからの管理者操作、通常の営業時間外に行われた活動がないかを重点的に調べる。特に、一度401エラーになった後にパスの形式を変えて成功するようなリクエストパターンがないかを確認することは、脆弱性の悪用を検知する上で有効である。もしArtifactoryをコンテナ環境で運用している場合は、コンテナの内部を検査する必要があること、またログの保存場所はインストール方法によって異なることにも注意が必要だ。もし不審な管理者アカウントやプラグインファイルが見つかった場合、すぐに削除せず、まず無効化して証拠を保全することが、その後の調査に役立つ。

そして、これらの問題に対して適切な対応を行うための手順も重要である。 まず「露出の軽減」として、管理画面やトークンエンドポイントへのアクセスを内部ネットワークに制限し、外部からのアクセスが必要な場合は、許可されたIPアドレスのみに限定する「ホワイトリスト方式」でプロキシを経由させるなどの対策を講じる。次に、ベンダーの修正バージョン表に従って、適切なブランチの修正済みバージョンへ速やかに「アップグレード」する。そして「ローテーション」として、不審なトークンはすべて無効化し、継続的インテグレーション（CI）システムやリポジトリの認証情報を更新し、クラスターキーも交換する。管理者パスワードや管理者に関連する鍵もすべて変更する必要がある。最後のステップは「監査と信頼の再構築」だ。管理者による変更履歴、アーティファクトの置き換え記録、そして不審な一括ダウンロードがないかを徹底的にレビューする。さらに、特に重要なアーティファクトの「ダイジェスト値」（ファイルの同一性を確認するためのハッシュ値）を、信頼できるビルドソースから得られたものと比較し、改ざんされていないかを確認する。この最後のステップはしばしば見落とされがちだが、脆弱性を修正するだけでは、修正前に配布されたパッケージが安全であるという保証にはならないことを理解しておく必要がある。

今回の事例は、単一の脆弱性だけでなく、複数の脆弱性が組み合わされることで、より深刻な攻撃につながる可能性があることを示している。また、システムの脆弱性を速やかに修正することだけでなく、その影響範囲を正確に把握し、事後対策まで含めた包括的なセキュリティ戦略が重要であることを浮き彫りにした。システムエンジニアを目指す上では、このようなセキュリティ問題の構造を理解し、日々の運用の中でどのように対策を講じるべきかを考えることが不可欠となるだろう。