Web Development2026-11-09約16分で読めます

Contact Form 7 の脆弱性 CVE-2026-114432 の影響確認と対処手順

6.2〜6.2.3は6.2.4へ更新

Contact Form 7 6.2〜6.2.3 は認証不要で任意のファイルをアップロードされ、環境次第でRCEに至る恐れがある（CVE-2026-114432）。6.2.4以降へ更新し、11月19日のPoC公開前に対応する。確認コマンド、環境別の対処、緩和策、痕跡の確認、FAQ まで一通り整理する。

セキュリティ ITリスク対策 CVE 脆弱性 WordPress

Contact Form 7 の 6.2〜6.2.3 には、認証なしで任意のファイルをアップロードできる脆弱性 CVE-2026-114432（CVSS 3.1 で 9.8、Critical）がある。標準的な Debian／Ubuntu の Apache 構成ではリモートコード実行（RCE）に至る恐れがあり、6.2.4 以降（現行最新は 6.2.4.1）への更新で修正される。WPScan は 2026年11月19日に PoC を公開する予定で、それまでに更新を済ませておきたい。

本記事は、WPScan の脆弱性情報、CVE レコード、Contact Form 7 公式サイトのリリース告知、WordPress.org のプラグインページをもとに、2026年11月9日時点で確認できた範囲を整理したものである。悪用は2026年11月9日時点で確認されておらず、CISA の KEV（悪用が確認された脆弱性カタログ）にも未追加である。一方で CISA の SSVC 評価では「自動化できる（Automatable: yes）」「技術的影響は全面的（Technical Impact: total）」とされているため、煽る必要はないが、後回しにもしない方がよい。公式に明記のない点は「明記なし」と書く。

3行でわかる要点

- 対象: Contact Form 7 の 6.2 〜 6.2.3（CVE レコードでは 6.2 以上 6.2.4 未満）。6.1.x 以前は対象外。WordPress.org の公称有効インストール数は 1,000万以上
- 内容: ファイル添付欄から、認証なしで任意のファイルをアップロードできる。環境によっては RCE（サーバー上でのコード実行）、そうでなくても uploads ディレクトリへの任意ファイル設置になりうる
- 今日やること: 6.2.4 以降へ更新する。管理画面の「プラグイン」で確認でき、更新後は添付ファイル付きフォームのテスト送信まで行う。WPScan の PoC 公開予定は11月19日

影響範囲の早見表

影響の大きさは、プラグインのバージョンに加えて、Web サーバーの構成で変わる。次の表は、ファクトシートにある WPScan と CVE レコードの記載をもとにした整理である。自分のサーバーの構成が分からない場合は、最悪の行（RCE の恐れ）を前提にして更新を急ぐのが無難である。

環境・バージョン	影響の有無	想定される影響・修正版
Contact Form 7 6.2 〜 6.2.3 ＋ Debian／Ubuntu 標準の Apache 構成（ディレクトリ一覧が有効、.phar を PHP ハンドラに割り当て）	影響あり	保存されたファイルを見つけて実行でき、RCE の恐れ。6.2.4 以降へ更新
Contact Form 7 6.2 〜 6.2.3 ＋ nginx、または .htaccess の上書きが有効な Apache	影響あり	uploads ディレクトリへの任意ファイル設置。HTML や SVG としてサイト自身のオリジンから配信され、XSS やフィッシングに悪用されうる。6.2.4 以降へ更新
Contact Form 7 6.1.x 以前	対象外	WPScan・CVE レコードとも 6.2 起点。ただし別の理由で古いバージョンのまま使い続けるのは勧めない
Contact Form 7 6.2.4 / 6.2.4.1	修正済み	6.2.4（2026-10-29）で修正。6.2.4.1 は 6.2.4 の後に FormDataTree-PHP を 2.0.10 に更新した版（同日）

何が起きているのか

Contact Form 7 は、WordPress にお問い合わせフォームを設置する定番プラグインである。フォームには「ファイル添付欄」（[file] タグ）を置け、訪問者が画像や書類を添付して送信できる。今回の脆弱性は、この添付欄の処理に関するものである。WPScan の見出しは「Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename」、つまり「不正な UTF-8 ファイル名を使った、認証なしの任意ファイルアップロード」である。

仕組みを平易に言うと、問題は2つの不備が重なっている点にある。

- 種類・拡張子の検証が働かない: 添付されたファイルの種類と拡張子が、本来の検証を通らずに受け入れられる。攻撃者は不正な UTF-8 のファイル名を使ってこの検証をすり抜ける、というのが WPScan のタイトルが示す内容である
- 一時ファイルの削除不備: 送信処理の途中で作られる一時ファイルが、削除されずにディスクに残る。つまり、拒否されたはずのファイルがサーバー上に居座る
- 認証が要らない: フォームは訪問者に公開されているため、ログインしていない第三者がそのまま送信できる（CVSS のベクターでも PR:N＝権限不要、UI:N＝利用者の操作不要）

ここまでは「任意ファイルがサーバーに置かれる」という話で、それだけで直ちに乗っ取りになるわけではない。置かれたファイルが実行されるかは、Web サーバーの構成で決まる。CVE の記述では、標準的な Debian／Ubuntu の Apache 構成が特に危ない。この構成では次の2点が重なる。

- ディレクトリ一覧が有効: ファイル名を知らなくても、ディレクトリの一覧から保存されたファイルを見つけられる
- .phar を PHP ハンドラに割り当てている: .phar という拡張子のファイルが PHP として実行される

この2つが揃うと、攻撃者は .phar ファイルを置き、一覧から探し出し、実行できる。結果がリモートコード実行（RCE）である。

nginx や、.htaccess の上書きが有効な Apache では、実行までは行かず、uploads ディレクトリへの任意ファイル書き込みにとどまる。ただしこの場合も、HTML や SVG のファイルがサイト自身のオリジンから配信されうる。サイトのドメイン上でスクリプトが動く、あるいは本物そっくりのフィッシングページが置かれる、といった悪用が考えられるため、「RCE ではないから安全」とは言えない。

深刻度は公式値で CVSS 3.1 の 9.8（Critical、AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）、CWE は CWE-434（危険な種類のファイルの無制限アップロード）、CNA（番号を採番した組織）は WPScan である。CISA ADP の SSVC では、Exploitation は none（悪用なし）、Automatable は yes、Technical Impact は total とされている。

自分が影響を受けるかの確認手順

確認は3段階で進める。(1) 自分のサイトの Contact Form 7 のバージョン、(2) 添付欄（[file] タグ）を使うフォームがあるか、(3) Web サーバーの構成の順である。(1) が 6.2〜6.2.3 でなければ、この件は対象外である。

手順1: プラグインのバージョンを確認する

- 管理画面の「プラグイン」→「インストール済みプラグイン」で、Contact Form 7 のバージョン表示を見る。「今すぐ更新」が出ていれば更新が必要
- SSH で入れる場合は WP-CLI か、プラグインのファイルを直接確認する

# WP-CLI: バージョンと更新の有無を表示
wp plugin list --name=contact-form-7 --fields=name,version,update

# バージョンだけを取得
wp plugin get contact-form-7 --field=version

# WP-CLI が使えない場合: ファイルのヘッダーを確認
grep "Version:" wp-content/plugins/contact-form-7/wp-contact-form-7.php

表示が 6.2〜6.2.3 なら対象である。6.2.4 または 6.2.4.1 なら修正済みなので、手順3の確認は不要である。マルチサイト構成では、サイトごとにプラグインの有効状態が違うことがあるため、ネットワーク全体を確認する。

手順2: ファイル添付欄を使うフォームを探す

添付欄を使っているかどうかで、どのフォームが攻撃経路になりうるかが変わる。CVE の記述は file フィールド経由とされているため、添付欄がないサイトでは攻撃経路が限られる可能性がある。ただしこれは記述からの推測で、断定はできない。更新は添付欄の有無にかかわらず行うこと。

# フォームの一覧を表示
wp post list --post_type=wpcf7_contact_form --fields=ID,post_title

# 個別のフォームに [file] タグがあるか確認（<ID> は上の一覧の番号）
wp post get <ID> --field=post_content | grep "\[file"

# まとめて確認する例（添付欄を含むフォームの ID を表示）
for id in $(wp post list --post_type=wpcf7_contact_form --field=ID); do
  if wp post get "$id" --field=post_content | grep -q "\[file"; then echo "file field: $id"; fi
done

フォーム本体は投稿（wpcf7_contact_form）として保存されているため、WP-CLI の post 系コマンドで確認できる。管理画面なら、「お問い合わせ」→ 各フォームの編集画面で、フォームのテンプレート中に「[file ...]」「[file* ...]」の記述があるかを見る。

手順3: Web サーバーの構成を確認する（Apache の場合）

# 有効な Apache モジュールを確認（php 関連のモジュールが出るか）
apachectl -M

# .phar の扱いを設定ファイルから探す（Debian／Ubuntu の場合）
grep -rn "phar" /etc/apache2/

# ディレクトリ一覧（Indexes）が有効になっていないか確認
grep -rn "Options" /etc/apache2/ | grep -i indexes

これは目安である。設定の出方はディストリビューションや PHP の入れ方で違うため、出力の解釈に自信がなければ、後述の緩和策（ディレクトリ一覧と .phar の無効化、uploads 配下での PHP 実行禁止）をまとめて入れるのが早い。レンタルサーバーでは、これらの設定自体を利用者が見られないことが多い。その場合は、バージョンを更新して、事業者の告知を確認する。

環境別の対処

管理画面から更新できる場合

- 作業の前に、サイトのバックアップを取る（ファイルとデータベースの両方）。レンタルサーバーのバックアップ機能でも、プラグインでも構わない
- 管理画面の「プラグイン」→「インストール済みプラグイン」で Contact Form 7 の「今すぐ更新」を押す。更新後のバージョンが 6.2.4 以降（6.2.4.1 が現行最新）であることを確認する
- 更新ボタンが出ない場合は、「ダッシュボード」→「更新」で更新情報を再取得する。それでも出ないときは、後述の手動更新を検討する
- 更新後は、次の「更新後の確認」に進む

WP-CLI・SSH で管理している場合

# 先にバックアップ（データベース）
wp db export backup-before-cf7-update.sql

# Contact Form 7 を更新
wp plugin update contact-form-7

# 更新後のバージョンを確認（6.2.4 以降であること）
wp plugin get contact-form-7 --field=version

複数サイトを管理している場合は、サイトごとに同じコマンドを実行するか、WP-CLI のエイリアスを使う。更新後は、PHP-FPM やキャッシュの再起動までは通常不要だが、オブジェクトキャッシュやページキャッシュを使っているサイトでは、フォームのページが古い状態のままになっていないか確認する。

制作会社・保守会社に任せている場合

自分で作業せず、委託先に更新を依頼するときは、次のような文面で伝えると齟齬が出にくい。バージョン、期限、確認項目を最初から書いておくのがコツである。

件名: 【至急】Contact Form 7 の更新のお願い（CVE-2026-114432）

お世話になっております。
Contact Form 7 の 6.2〜6.2.3 に、認証なしで任意のファイルをアップロードできる
脆弱性（CVE-2026-114432、CVSS 3.1 で 9.8）が公開されました。
当サイトの対象プラグインを 6.2.4 以降（現行最新は 6.2.4.1）へ更新をお願いします。
WPScan は 11 月 19 日に PoC を公開予定とのことですので、それ以前の対応を希望します。

つきましては、次の点をご回答ください。
1. 当サイトの Contact Form 7 のバージョン（更新前・更新後）
2. ファイル添付欄（[file] タグ）を使うフォームの有無
3. uploads ディレクトリ（wp-content/uploads/wpcf7_uploads など）に
   想定外のファイルが残っていないかの確認結果
4. 更新後のテスト送信（添付ファイル付きフォームを含む）の結果
5. 自動更新が有効かどうか

委託先が更新前にステージング環境で確認する運用の場合は、その分の日数も含めて11月19日に間に合うかを確認するとよい。

レンタルサーバー・VPS を使っている場合

- 共用レンタルサーバー: プラグインの更新は利用者の作業である。サーバー側の設定（ディレクトリ一覧、.phar のハンドラ）は事業者が管理するので、利用者は変更できないことが多い。まずバージョンを更新し、サーバーの告知や管理画面で WAF 機能が使えるか確認する
- Debian／Ubuntu 系の VPS・専用サーバー: 今回の構成に最も近い。更新に加えて、後述の緩和策で Apache の設定を見直す
- nginx を使っている場合: CVE の記述では RCE ではなく、任意ファイルの設置にとどまる。それでも更新は必要で、uploads 配下で PHP を実行させない設定も合わせて確認する
- 手動更新が必要な場合: 管理画面から更新できないときは、WordPress.org からプラグインを入手して、wp-content/plugins/contact-form-7 を差し替える。作業前にバックアップを取り、ファイルの権限と所有者を元のものに合わせる

すぐ更新できない間の緩和策

更新が最優先で、以下は更新までのつなぎである。緩和策は修正の代わりにならないので、更新できる環境では飛ばしてよい。また、どれも一般論であり、お使いの環境で動作確認をしてから入れること。

- ファイル添付欄のあるフォームを一時停止する: フォームから [file] タグを外す。添付欄がなければ、CVE の記述上の攻撃経路は限られる可能性がある
- uploads 配下で PHP の実行を禁止する: Apache なら <FilesMatch>、nginx なら location で php／phar を拒否する
- Apache のディレクトリ一覧を無効化する: Options -Indexes
- .phar のハンドラ割り当てを外す: 使っていなければ、PHP として実行させない
- WAF: 利用しているサービスのルールで、アップロード系の挙動を絞る

Apache の設定例を示す。wp-content/uploads の .htaccess または仮想ホストの設定に入れる。サーバーが AllowOverride を許していない場合は、.htaccess は効かない。

# wp-content/uploads/.htaccess または仮想ホストの <Directory> に追加
Options -Indexes

<FilesMatch "\.(php|phar|phtml|php[0-9])$">
    Require all denied
</FilesMatch>

nginx の設定例を示す。設定を変えたら、構文を確認してから再読み込みする。

# server { } 内に追加
location ~* /wp-content/uploads/.*\.(php|phar|phtml)$ {
    deny all;
}

# 設定確認と再読み込み
# sudo nginx -t && sudo systemctl reload nginx

.phar のハンドラ割り当てを外すかどうかは、サーバーで他の用途に使っていないか確認してから判断する。Debian／Ubuntu のパッケージでは設定ファイルが分割されているため、前の章の grep で場所を見つける。WAF を使う場合も、攻撃者がオリジンサーバーに直接アクセスできるなら迂回されうる。オリジンへのアクセス元を制限できているかも合わせて見直したい。

更新後の確認

添付ファイル付きフォームのテスト送信

6.2.4 では、wpcf7_antiscript_file_name() の挙動が、ブロックリスト方式から許可リスト（safelist）方式に変わったとされる（二次情報、リリースノートの要旨）。つまり「危ない拡張子を拒否する」から「許可した拡張子だけ受け入れる」への変更で、安全側に倒れる。一方で、特殊な拡張子のファイルを添付してもらっているフォームでは、更新後に受け付けられなくなる可能性がある。更新後は次の確認を行う。

- 添付欄のある各フォームから、実際に使う種類のファイル（PDF、画像、Office ファイルなど）でテスト送信する
- 送信完了のメッセージが出ること、メールが届くこと、添付が付いていることを確認する
- 特殊な拡張子を受けている場合は、受け付けられるか確認する。受け付けられなければ、運用側で拡張子の扱いを見直す
- スパム対策プラグインや CAPTCHA を併用しているフォームは、その経路まで含めて試す

痕跡の確認

更新は今後の攻撃を防ぐものであり、すでに置かれたファイルは消えない。悪用は2026年11月9日時点で確認されていないが、念のため uploads 配下に想定外のファイルがないかを確認する。Contact Form 7 の一時保存先は、既定では wp-content/uploads/wpcf7_uploads である。以下は一般的な確認手順であり、これで見つからないことが無事の証明にはならない。

# 10 月 1 日以降に作られた、実行可能・配信されうる拡張子のファイルを探す
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phar" -o -name "*.phtml" -o -name "*.html" -o -name "*.svg" \) -newermt 2026-10-01

# 一時保存先に残っているファイルを一覧
ls -la wp-content/uploads/wpcf7_uploads/

見つかったファイルが正規のもの（自分で入れた SVG ロゴなど）かどうかは、作成日時とファイルの中身を見て判断する。身に覚えのない .php や .phar があれば、削除する前にファイルのコピーとアクセスログを保全し、サーバー全体の点検（管理者アカウントの増減、書き換えられたファイル、パスワードの変更）に進む。判断に迷う場合は、保守会社やセキュリティの専門家に相談したい。

時系列

日付	出来事
2026-10-29	Contact Form 7 6.2.4 リリース（修正版）。同日、FormDataTree-PHP を 2.0.10 に更新した 6.2.4.1 も公開
2026-11-05	WPScan が脆弱性情報を掲載
2026-11-08	CVE-2026-114432 公開（UTC 06:00）
2026-11-19（予定）	WPScan が PoC を公開する予定。利用者の更新期間を確保するための措置とされる

修正版のリリースから脆弱性情報の掲載まで約1週間あり、利用者に更新の猶予が与えられた形である。PoC の公開予定日が告知されている以上、11月19日以降は攻撃コードが出回る前提で考えた方がよい。それまでが、慌てずに更新できる期間である。

今日やることチェックリスト

- Contact Form 7 のバージョンを確認した（6.2〜6.2.3 は対象）
- 対象なら、バックアップを取って 6.2.4 以降（6.2.4.1 が現行最新）に更新した
- 添付ファイル付きフォームをテスト送信し、メールと添付が届くことを確認した
- ファイル添付欄（[file] タグ）を使うフォームを把握した
- uploads 配下に、想定外の .php／.phar／.html／.svg がないか確認した
- すぐ更新できない場合、添付欄の停止か、uploads 配下での PHP 実行禁止を入れた
- 委託先がいる場合、更新の依頼と、完了の連絡を受ける約束をした
- 11月19日（PoC 公開予定）までの更新完了を目標にした
- 自動更新の設定を確認した

同じ週に公開された他の脆弱性は11月9日の脆弱性まとめに、先に出た脆弱性は11月7日の脆弱性まとめにまとめている。WordPress の同系統の事例としてWordPress「wp2shell」認証不要 RCE の緊急解説、更新運用の基本はWordPress 保守の実務、フォーム自体のスパム対策は問い合わせフォームのスパム対策、診断の費用感は脆弱性診断・ペネトレーションテストの費用相場を参照してほしい。

よくある質問

6.1 系など、古いバージョンは影響を受けませんか？

WPScan・CVE レコードとも 6.2 を起点としており、6.1.x 以前は対象外である。ただし古いバージョンのまま使い続けると、別の脆弱性や互換性の問題を抱えるおそれがあるため、更新は勧める。更新時は、WordPress 本体や PHP のバージョン要件も確認する。

ファイル添付欄を使っていなければ安全ですか？

CVE の記述は file フィールド経由とされているため、添付欄がないサイトでは攻撃経路が限られる可能性がある。ただし、これは記述からの推測で、安全を保証するものではない。フォームの設定を見落としている場合もあるため、添付欄の有無にかかわらず 6.2.4 以降への更新を勧める。

自動更新は有効にしておくべきですか？

小さなサイトでは、プラグインの自動更新を有効にすると、今回のような更新の遅れを減らせる。一方で、更新後に表示や送信が崩れるリスクもあるため、フォームなどの重要な機能は更新後に動作確認をする運用にするとよい。WordPress の管理画面の「プラグイン」から、プラグインごとに自動更新を切り替えられる（設定画面は WordPress のバージョンで異なる）。

すでに侵入されたかどうかは分かりますか？

断定はできないが、uploads 配下（既定では wp-content/uploads/wpcf7_uploads）に想定外の .php／.phar／.html／.svg がないか、Web サーバーのアクセスログに不審な POST がないかを見ることで、手がかりが得られる。悪用は2026年11月9日時点で確認されておらず、痕跡がなければひとまず安心だが、無事の証明にはならない。不審なファイルがあれば、削除前に保全して専門家に相談する。

6.2.4 と 6.2.4.1 のどちらに更新すればよいですか？

どちらも修正済みである。6.2.4.1 は、6.2.4 の後に FormDataTree-PHP を 2.0.10 に更新した版で、同日（2026-10-29）に公開された。WordPress.org の現行最新は 6.2.4.1 なので、管理画面から更新すれば自然に最新版になる。

nginx を使っていれば RCE にはなりませんか？

CVE の記述では、nginx では RCE にはならず、uploads ディレクトリへの任意ファイル書き込みにとどまる。ただし、HTML や SVG がサイト自身のオリジンから配信されうるため、XSS やフィッシングに悪用されうる。nginx でも更新は必要である。

出典

- WPScan「Contact Form 7 — Unauthenticated Arbitrary File Upload via Invalid UTF-8 Filename」（発見者: Shinya Murakami 氏）
- CVE レコード CVE-2026-114432
- Contact Form 7 公式「Contact Form 7 6.2.4」（2026-10-29）
- WordPress.org「Contact Form 7」プラグインページ

この記事に関連する無料ツール（登録不要・その場で結果）

ホシュ診断（保守リスク健康診断）8つの質問でサイト・システムの保守リスクを3段階判定

お気軽にご相談ください

お問い合わせ