セキュリティ対策
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
ファイルのアップロード機能は、設計を誤ると『認証なしで任意のファイルを置かれ、それが実行されてサーバーを乗っ取られる（Webシェル→RCE）』最悪クラスの穴になります。2026年に相次いだJoomlaページビルダーの一斉悪用も同じ型でした。攻撃手順ではなく、あなたのアップロード機能をどう守るか——認証・サーバー側の検証・保存先・実行無効化の多層防御を、公開事実にもとづいて解説します。
対象：フォーム・管理画面・CMS拡張・API などでファイルを受け取る機能を持つ（あるいはそういう拡張を入れている）すべての現場。ここでは攻撃の再現手順は扱わず、自分のアップロード機能をどう安全にするか——公開事実にもとづく防御だけを扱います。関連：依存の脆弱性を直しきる CVE対応の実務、組織の土台は 組織のセキュリティ最低限。
何が起きるのか（平易に）
多くのアプリには「画像を上げる」「アイコンを差し替える」「資料を添付する」といったファイルを受け取る口があります。ここで守りが甘いと、攻撃者は画像のふりをしたスクリプトファイルを送り込み、サーバー上のWeb公開フォルダに保存させます。あとはそのファイルのURLをブラウザで開くだけ——サーバーが中身をプログラムとして実行してしまえば、攻撃者は遠隔から自由にコマンドを走らせられます。これが Webシェル（設置された遠隔操作用の小さなプログラム）であり、そこから改ざん・情報窃取・管理者アカウントの密造・他システムへの横移動へと広がります。
『受け取る』より『置き場所と実行』が9割
アップロードそのものは正当な機能です。危険なのは、受け取ったファイルを「実行できる場所」に「実行できる形」で置いてしまうこと。逆に言えば、たとえ怪しいファイルを受け取っても、実行されない場所に置き、中身を検査し、投稿口に認証があれば、被害は成立しません。守りの発想を「変なものを弾く」から「置き場所で実行させない」へ移すのが核心です。
2026年の実例：Joomlaページビルダーの一斉悪用（同じ型）
2026年、Joomlaの2つのページビルダー拡張で、まったく同じ型の未認証アップロード→RCEが公表され、広く悪用されました。いずれも「認証チェックなし＋ファイル型の検証なし＋Web公開領域へ保存」という教科書どおりの組み合わせだったと報じられています。
- SP Page Builder (CVE-2026-48908)
- JoomShaper製。6.6.1以前が対象、6.6.2で修正。アイコンのアップロード処理に認証・型検証がなかったとされ、CVSS 10.0・実際に悪用中（CISA KEV掲載）。速報解説＝CVE-2026-48908。
- Page Builder CK (CVE-2026-56290)
- joomlack.fr製。3.5.10以前が対象、3.6.0で修正（旧系統は3.1.1／3.4.10へバックポート）。同じく未認証のアップロードからRCEに至るとされ、CVSS 10.0。
- 共通点
- 認証なしで悪用可能＝無差別スキャンの標的。攻撃はしばしば管理者アカウントの密造やWebシェル設置で永続化し、入口を塞いだ後も居座るよう作られていたと報じられている。
- 本命の対策
- 対象拡張を修正版へ更新（＋使わない拡張は棚卸しして削除）。加えて下記の設計・設定を多層で。
教訓：『使っていない拡張』が最大の穴になりやすい
2つの事例に共通するのは、入れたまま忘れられがちな拡張が入口になった点です。CMSのプラグイン/拡張は「入れた数だけ攻撃面が増える」もの。棚卸しして使わないものを消すだけで、こうした一斉悪用の的を大きく減らせます（資産棚卸しの考え方）。
攻撃の連鎖は「防御の地図」でもある
この型は、各段に止め所があります。攻撃手順としてではなく、どこで断ち切れるかとして読んでください。
① 認証なしの投稿口にファイルを送る
誰でも到達できるアップロード処理に、スクリプトを送信。
⊘ 止め所：エンドポイントに認証・権限チェック＋CSRFトークン
② 型検証をすり抜けて保存される
拡張子やContent-Typeの詐称・二重拡張子で「画像」に偽装。
⊘ 止め所：サーバー側の許可リスト＋中身（マジックバイト）検査
③ Web公開領域に置かれ、URLで到達できる
推測しやすいパスに保存され、ブラウザから直接開ける。
⊘ 止め所：保存先はWeb公開領域の外／ファイル名を乱数化
④ サーバーがスクリプトとして実行してしまう
保存先でスクリプトが動く設定＝Webシェル→RCE。
⊘ 止め所：アップロード領域でスクリプト実行を無効化
崩れる構成 vs 守られる構成
崩れやすい構成
- 投稿口に認証・権限チェックがない（誰でも到達できる）
- 拡張子やContent-Typeだけで判定（詐称・二重拡張子で回避）
- 受け取ったファイルをWeb公開領域にそのまま保存
- 保存先でスクリプトが実行できる設定のまま
- ファイル名がユーザー指定／推測可能
守られる構成
- 投稿口に認証＋権限＋CSRFトークンを必須化
- 許可リストで型を絞り、**中身（マジックバイト）**まで検査
- 保存先はWeb公開領域の外（配信は専用の窓口経由）
- アップロード領域はスクリプト実行を無効化
- 乱数のファイル名に付け替え、ユーザー指定パスは信用しない
あなたの環境での実装（優先順）
投稿口に認証・権限・CSRFを必須化する
アップロードを扱うエンドポイントは、ログイン済みで適切な権限を持つ利用者だけが到達できるようにし、CSRFトークンを検証する。2026年のJoomla事例は、まさにこの認証・権限チェックが抜けていたと報じられている。まず「誰でも叩ける状態」をなくす。
サーバー側で許可リスト＋中身を検査する
クライアント側のチェックやブラウザ送信のContent-Typeは信用しない。サーバー側で、許可する型だけを通す許可リストに加え、**ファイルの中身（マジックバイト）**を検査して「本当にその型か」を確認する。二重拡張子・大文字小文字・末尾ドットなどを正規化してから判定する。
保存先をWeb公開領域の外に置く（または実行を無効化）
受け取ったファイルはWebから直接URLで開けない場所に保存し、配信は専用のコントローラ経由（適切なContent-Dispositionで）にする。それが難しければ、少なくともアップロード領域でスクリプトの実行を無効化する（Webサーバー設定）。これが効けば、たとえ悪性ファイルを受け取っても実行されない＝最後の砦になる。
ファイル名を乱数化し、サイズ・レート制限をかける
保存名はサーバーが決める乱数に付け替え、ユーザー指定のパスやファイル名を信用しない（パス操作やパストラバーサルの回避）。併せてサイズ上限・レート制限、可能ならマルウェアスキャンを通す。
拡張/CMSを棚卸しして最新に保つ
使っている拡張・プラグインを棚卸しし、使わないものは削除、残すものは最新へ更新する。2026年の一斉悪用は、更新されないまま残った拡張が入口だった。CVE対応の実務の要領で、変化検知まで載せて再発を監視する。
当サイトの設計思想と重なる点
この型の本質は、信頼できない入力を、実行できる場所に、実行できる形で置いてしまうことです。当サイト自身の原則——受け取ったものを信用しない・重要な領域を分離する・多層で守る——とちょうど裏返しの関係にあります。アップロードに限らず、「入力の検証はサーバー側で」「秘密や実行可能領域は分離する」は共通の守り。関連する配置ミスの考え方は 公開ディレクトリに秘密を置かない も併せてどうぞ。
次に読む
- 用語：RCE（リモートコード実行）とは ／ マルウェアとは（Webシェルもこの一種）
- 速報：CVE-2026-48908（SP Page Builder 未認証アップロード→RCE）
- 実務：組織のセキュリティ最低限 ／ 脆弱性(CVE)対応の実務 ／ 公開ディレクトリに秘密を置かない
よくある質問
Qファイルアップロードの脆弱性で、なぜサーバーを乗っ取られるのですか？
攻撃者が『サーバーが実行してしまう種類のファイル（例：スクリプト）』を置ける状態になると、それをブラウザから開くだけでサーバー上でコードが動きます（Webシェル→リモートコード実行=RCE）。そこから改ざん・情報窃取・管理者アカウント作成・他システムへの侵入に直結します。核心は『受け取ったこと』ではなく、置かれた場所でファイルが実行できてしまう設計にあります。
Q拡張子だけチェックすれば安全ですか？
不十分です。拡張子やブラウザが送るContent-Typeは攻撃者が自由に詐称できます。二重拡張子（例：picture.php.jpg）、大文字小文字、末尾のドットやヌル、あまり知られた実行可能拡張子など回避手口が多数あります。守りは『許可リスト（許すものだけ通す）＋ファイルの中身（マジックバイト）の検査＋そもそも保存先で実行させない』を重ねることです。禁止リスト（危険なものを弾く）だけに頼らないでください。
Q小さなサイトでも狙われますか？
狙われます。この種の穴は認証不要で悪用でき、攻撃者はインターネット全体を機械的にスキャンして無差別に叩きます。2026年に広く悪用されたJoomlaのページビルダー拡張の事例でも、規模に関係なく該当バージョンが一斉に標的になりました。『小さいから狙われない』は通用しません。