【ITニュース解説】CVE-2026-15748 Explained: How One Pipe Character Broke an "Exact Match" Blocklist

今回のニュース記事は、WordPressのプラグイン「Forminator Forms」に見つかった非常に危険な脆弱性「CVE-2026-15748」について解説している。システムエンジニアを目指す皆さんにとって、これはWebアプリケーションのセキュリティの基本と、脆弱性がどのように組み合わさって深刻な被害を生むかを理解する良い事例となるだろう。

Forminator Formsは、WordPressサイトで問い合わせフォーム、支払いフォーム、カスタムフォームなどを作成するための人気プラグインで、60万以上のサイトで利用されている。このプラグインには、ファイルをアップロードする機能がある。ファイルをアップロードする機能がある場合、悪意のあるファイルをアップロードされないようにするための仕組み、特にサーバーで実行されてしまうような危険な種類のファイルを防ぐ仕組みが必須だ。しかし、今回の脆弱性はこの防御機構が二つの弱点によって破られてしまい、最終的に「リモートコード実行（RCE）」と呼ばれる非常に深刻な攻撃を可能にしてしまった。リモートコード実行とは、攻撃者がインターネット経由でターゲットのサーバー上で任意のプログラムを勝手に実行できてしまう状態を指し、サーバーの乗っ取りやデータの窃取など、あらゆる種類の被害につながる可能性がある。

この脆弱性の深刻度は「9.8（Critical）」と評価されており、認証なしで、つまりサイトのユーザーでなくても誰でも攻撃が可能であったことが強調されている。攻撃が成功するためには、フォームの中にファイルをアップロードするフィールドと、「セレクトフィールド」（選択肢から一つを選ぶドロップダウンのようなフィールド）の両方があることが前提条件となる。

では、なぜこのような危険な脆弱性が生まれたのか、その仕組みを段階的に見ていこう。

一つ目の弱点は、フォームの設定がサーバーではなく、ユーザーからのリクエストを安易に信用してしまった点にある。通常、フォームの管理者（サイト運営者）が「このアップロードフィールドでは、画像ファイル（例：jpg, png）だけを許可する」と設定した場合、その設定はサーバー（データベース）に安全に保存されるべきだ。そして、ユーザーがファイルをアップロードしようとした際には、サーバーに保存されたこの設定と照らし合わせて、適切なファイルかどうかをチェックするのが正しい動きだ。しかし、Forminator Formsの脆弱なバージョンでは、ファイルをアップロードする際の「許可されたファイルの種類」という設定が、サーバーに保存されたものからではなく、なんとユーザーが送信したリクエスト（POSTデータ）の中に含まれる情報を信頼して構築されてしまっていた。さらに悪いことに、この「アップロードフィールドの設定」は、全く関係なさそうに見える「セレクトフィールド」の入力値を使って、攻撃者が意図的に注入（上書き）できてしまう構造になっていた。これにより、管理者がどんなに厳しくアップロードファイルを制限していても、攻撃者はセレクトフィールドの値を細工するだけで、アップロードフィールドが「どんなファイルでも許可する」と誤認識するように変更できてしまう状態だったのだ。

二つ目の弱点は、危険なファイル（例えば、サーバー上でプログラムとして実行されてしまうPHPファイルなど）をブロックするためのリスト（ブロックリスト）のチェック方法にあった。このプラグインには、サーバー実行可能な.phpや.phtmlのような拡張子を持つファイルのMIMEタイプ（ファイルの種類を示す情報、例：application/x-php）をブロックするためのリストが用意されていた。しかし、このブロックリストのチェックは、「入力されたMIMEタイプ文字列が、ブロックリスト内の危険なMIMEタイプ文字列と完全に一致するかどうか」だけで判断していた。

ここに攻撃者が目をつけた。例えば、通常のPHPファイルのMIMEタイプはapplication/x-phpだ。この文字列がブロックリストにあれば、ファイルはブロックされる。しかし、攻撃者はMIMEタイプの文字列の最後に「|」（パイプ文字）などの区切り文字を追加し、application/x-php|という文字列を送信した。すると、ブロックリストは「application/x-php」とは完全に一致しないため、「これは危険なMIMEタイプではない」と誤判断してしまい、チェックをすり抜けてしまったのだ。これは、ブロックリストが入力値を事前に「正規化」（余分な文字を取り除いたり、統一された形式に変換したりする処理）せずに、単なる文字列の完全一致で比較していたために発生した問題である。

これら二つの弱点が組み合わさることで、攻撃は完成する。まず、攻撃者はセレクトフィールドの値を細工して、アップロードフィールドが「どんなファイルでも許可する」ように設定を上書きする。次に、アップロードするファイルの種類をPHPファイル（例：shell.php）とし、MIMEタイプにはパイプ文字などを付加してapplication/x-php|のように偽装してブロックリストを回避する。これにより、攻撃者が指定した名前（例：shell.php）と内容（例：サーバー上でコマンドを実行する簡単なPHPコード）のPHPファイルを、WordPressのアップロードディレクトリにアップロードすることが可能になった。

さらに問題はこれで終わりではない。通常、WordPressのアップロードディレクトリには、セキュリティ対策として、.htaccessというファイルが自動的に作成され、PHPファイルがウェブサーバー上で実行されるのを防ぐ仕組みがある。つまり、もし誤ってPHPファイルがアップロードされてしまっても、ウェブサーバーはそれを単なるテキストファイルとして扱い、実行しないように保護されていることが多い。しかし、Forminator Formsで「カスタムファイルアップロードストレージ」という機能を使っている場合、この.htaccessファイルによる保護が正しく適用されないケースがあった。その結果、カスタムアップロードパスにPHPファイルがアップロードされたとしても、何の保護もなく、ウェブサーバーがPHPファイルとして直接実行してしまう状態になる。

こうして、攻撃者は認証なしで、特別な権限も必要とせず、ウェブサイトのURLに直接アクセスするだけで、アップロードしたPHPファイルを実行し、サーバー上で任意のコマンドを実行できるようになった。例えば、http://target/wp-content/uploads/forminator-custom/shell.php?cmd=idのようなURLにアクセスすると、idコマンドが実行され、サーバーのユーザー情報が返ってくる、といった具合だ。これはまさに、リモートコード実行が成功した状態である。

この脆弱性は、Forminator Formsのバージョン1.56.2で修正された。修正内容は、根本原因に直接対処するものだ。一つ目の弱点に対しては、アップロードフィールドが許可するファイルタイプの設定を、ユーザーからのリクエストからではなく、サーバーに保存されたフォームの設定のみを信頼するように変更された。二つ目の弱点に対しては、危険なMIMEタイプのブロックリストチェックにおいて、比較する前にMIMEタイプ文字列を正規化する処理が導入された。これにより、パイプ文字のような区切り文字を付加してもブロックリストを回避できなくなった。

今回の脆弱性から学べる教訓は二つある。まず、ウェブアプリケーション開発において、クライアント（ユーザーのリクエスト）から送信される情報は決して鵜呑みにせず、常にサーバーサイドで厳格に検証・サニタイズ（安全な形に変換）する必要があるということだ。「この設定値はサーバーが管理しているはずだ」という思い込みは、全く関係ない入力フィールドから不正に上書きされる可能性を考慮しなくてはならない。二つ目に、ブロックリストや許可リストのようなチェック機構を実装する際には、「文字列が完全に一致するか」という単純な比較だけでなく、入力値の正規化処理を必ず行うべきだということだ。そうしないと、文字列の微妙な違いを利用して、攻撃者は容易にセキュリティチェックをすり抜けてしまう。

システムエンジニアを目指す皆さんは、これらの教訓を心に留めてほしい。アプリケーションのセキュリティは、複数の層の防御がきちんと機能して初めて守られるものだ。たった一つの文字の扱いの間違いや、設定値の信頼の仕方の間違いが、システム全体を危険に晒すことにつながる。

今回の脆弱性への対策としては、Forminator Formsプラグインを直ちにバージョン1.56.2以降にアップデートすることが最も重要だ。もしすぐにアップデートできない場合は、ファイルをアップロードする機能を持つフォームで、かつセレクトフィールドも併用しているフォームがあれば、そのファイルアップロード機能を一時的に無効にすることも検討すべきだろう。また、「カスタムファイルアップロードストレージ」を使用している場合は、プラグインの設定とは別に、ウェブサーバー（ApacheやNginxなど）の設定で、そのディレクトリでのPHPファイルの実行がブロックされているかを確認することが強く推奨される。万が一、攻撃を受けた可能性がある場合は、アップロードディレクトリに不審なPHPファイルがないか確認し、怪しいフォーム送信リクエスト（特にセレクトフィールドの値が異常に大きいもの）がないか、アクセスログを詳細に調査する必要がある。