何が起きたか・対象

Camaleon CMSで、ログイン済みの通常ユーザーが、アップロードの保存先とファイル形式の検査基準を変更できました。HTTPリクエストを受けたCMSがファイルを書く際に使うのは、サイト利用者の権限ではなく、サーバーでアプリを動かすOSアカウントの権限です。そのアカウントが書ける場所なら、保管領域の外にも保存できる場合がありました。

サーバーはfolderとファイル名を保管領域へ結合して保存先を決めます。研究の例ではfolderに../../../config/initializers/を指定して親ディレクトリへ戻り、Railsの初期化ファイルの領域へ移動させています。許可形式を決めるformatsのフォーム項目も取り除くと、形式を限定せずRubyファイルを受け付けました。保存先に書ける構成では、アプリが次回起動時にそのRubyを初期化コードとしてロードします。投稿直後ではなく、この再起動時に実行されます。

関連報告には領域外ファイルの読み取りとXSSも含まれ、識別子はGHSL-2024-182〜186、CVE-2024-46986、CVE-2024-46987です。ファイルの応答取得、ブラウザでのコード実行、サーバーでのRuby実行は、それぞれ条件が異なります。

報告・修正・公開の時系列

2.8.0を対象に検証され、2024-08-08に報告、08-21に修正を含む2.8.1が公開されました。研究資料の公開は2025-04-17です。報告と修正は、研究記事の公開より前に行われています。

正常ならどう動くはずだったか

投稿された画像などは、サーバーが固定した保管領域へ保存します。保存先と許可する形式はサーバー側で決め、投稿者から送られたfolderやformatsで変更させません。

アプリのプログラムや起動時の初期化ファイルを置く領域へ投稿を書き込めないように分けることで、保存されたファイルをアプリ自身のコードとして後から読み込む経路を断てます。画像として許可した内容かという検査と、保存先が安全かという検査を両方行います。

技術的な原因

MediaControllerのuploadは、投稿者がHTTPリクエストで送るfolderを保存先の組み立てに使っていました。ファイル形式の許可条件であるformatsも同じ入力から変更できたため、投稿者が保存場所と検査基準の両方を選べました。保管領域内のファイルに限定できず、アプリのOSユーザーが書ける別の場所へ投稿内容を保存できました。 folderに含む../は親ディレクトリへの移動として解釈されるため、結合後の実際の保存先を保管領域内へ限定する必要があります。formatsも投稿者が省略・変更でき、研究の実証では項目を取り除くことで任意形式のファイルを受け付けさせています。

攻撃が成立する条件と流れ

通常ユーザーとしてログインした攻撃者が、Rubyの処理を含むファイルと領域外の保存先をアップロード機能へ送ります。Railsのconfig/initializersへ書き込める構成では、保存したRubyファイルをアプリが次の起動時に初期化コードとしてロードします。アップロード直後ではなく、この再読み込みでサーバー上のコード実行になります。自己登録が有効なら、前提の通常アカウントを取得しやすくなります。

確認された事実と、想定される影響

研究は、config/initializersへ置いたRubyファイルが再起動後に実行される経路を示しています。説明用の影響例では、その処理がアプリから読める設定を外部へ送信できると、攻撃者が接続情報などを入手するおそれがあります。実行ユーザーの権限と外部通信の可否が範囲を決めます。

別のダウンロード経路では、攻撃者がfileパラメータに../を含む領域外のパスを入れます。サーバーがそのパスのファイルを読み、HTTPレスポンスで返すと、攻撃者が内容を取得します。書き込みと再起動が必要な経路とは、成立条件が異なります。

HTMLやSVGをページとして配信する経路では、利用者がアップロード済みファイルのURLを開くと、そのコードがCMSと同じオリジンで動く場合があります。説明用に、コードがCMSの非公開情報APIを呼ぶ構成なら、ブラウザは送信条件に合う利用者のログイン用Cookieを要求へ付けます。APIから情報を読み、さらに外部へ送れると、攻撃者がその内容を取得するおそれがあります。これはブラウザでの実行であり、サーバーでのRuby実行とは異なります。研究と実悪用も区別します。

実際の修正・対応方針

研究資料では2.8.1で修正とされています。各変更差分はここでは直接確認していません。一般策としては、保存先をサーバー側で固定し、形式検査の基準を投稿者が変更できないようにします。

利用者・運用者が確認すること

修正済みのサポート版へ更新し、保管領域外のファイル変更や不審な初期化ファイルを調べます。書き込まれたコードが残る場合、更新だけではそのファイルを取り除けないため、保存先の調査も必要です。

開発者への教訓（教材としての考察）

ファイル書き込みからコード実行までを確認する際は、どこへ書けるかと、そのファイルを後でどの処理が読むかを調べます。両方を説明すると、保存できた事実とコード実行の成立条件を混同せずに評価できます。

出典・確認範囲

  1. [1] Several vulnerabilities in Camaleon CMSGitHub Security Lab / 確認日 2026-10-29
未確認事項・限界

参照資料では実悪用や実際の被害件数を確認できません。未記載の実装差分は推測していません。