0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@jiis-sasaki

Contact Form 7(1000万サイト)に未認証ファイル設置 CVE-2026-114432──更新と点検

0
Posted at

この記事は、Contact Form 7 でお問い合わせフォームを運用している Web 担当者・制作会社の方向けです。
6.2〜6.2.3 には、ログイン不要でサーバーに任意のファイルを置かれる脆弱性(CVE-2026-114432)があります。
自サイトが該当するかの確認、6.2.4 以降への更新、置かれたファイルの点検、サーバー側の多重防御までをコピペで進められるようにまとめました。

脆弱性の概要

項目 内容
CVE CVE-2026-114432
対象 Contact Form 7(WordPress プラグイン / 有効インストール 1,000 万以上)
影響バージョン 6.2 〜 6.2.3
修正バージョン 6.2.4(2026-11-08 時点の最新は 6.2.4.1)
認証 不要(未ログインの訪問者が悪用可能)
前提条件 ファイル添付欄([file] タグ)を含むフォームが公開されていること
深刻度 Patchstack: CVSS 8.1 / NVD: 分析待ち(2026-11-08 受付・スコア未付与)
弱点分類 CWE-434(危険な種類のファイルの無制限アップロード)
公開日 WPScan 2026-11-05 / NVD 2026-11-08

公式の説明を要約すると次のとおりです。

  • フォームのファイル添付欄で受け取ったファイルについて、種類や拡張子の検証が行われていない
  • 一時ファイルの後始末に不備があり、検証で弾かれたファイルもディスク上に残ってしまう
  • その結果、未認証の利用者が任意のファイルをアップロードできる
  • Debian / Ubuntu 標準構成の Apache(ディレクトリ一覧が有効、.phar が PHP ハンドラに割り当て済み)では、置かれたファイルを見つけて実行される=**リモートコード実行(RCE)**に至るおそれがある
  • nginx や .htaccess の上書きが効く Apache では、影響は「uploads 配下に任意ファイルが置かれる」までに限られるが、HTML や SVG としてサイト自身のドメインから配信される可能性は残る(フィッシングページやスクリプト埋め込みの踏み台)

Patchstack の解説によれば、6.2 で一時保存前のファイル種別チェックが外れたことが原因で、6.1 系(6.1.7)はチェックが効いていたため影響範囲は 6.2 からとされています。また WPScan は、利用者の更新猶予のため検証コード(PoC)の公開を 2026-11-19 に予定しています。公開後は悪用が一気に広がるのが通例なので、それまでに更新を終えるのが目安です。

「お問い合わせフォームはあるが添付欄は無い」サイトは今回の直接の前提条件を満たしませんが、後から添付欄を足した瞬間に該当するため、更新はすべてのサイトで行ってください。

手順1: バージョンと「添付欄の有無」を確認する

WP-CLI が使える場合

# WordPress のルートディレクトリで実行
wp plugin get contact-form-7 --fields=name,status,version

6.2 / 6.2.1 / 6.2.2 / 6.2.3 のいずれかが出たら対象です(WP-CLI が無ければ管理画面のプラグイン一覧で確認できます)。

ファイル添付欄を使っているフォームを洗い出す

Contact Form 7 のフォーム本文はカスタム投稿 wpcf7_contact_form のメタ _form に保存されています。[file を含むフォームが今回の前提条件を満たすフォームです。

PREFIX=$(wp db prefix)
wp db query "
SELECT p.ID, p.post_title, p.post_status
FROM ${PREFIX}posts p
JOIN ${PREFIX}postmeta m ON m.post_id = p.ID AND m.meta_key = '_form'
WHERE p.post_type = 'wpcf7_contact_form'
  AND (m.meta_value LIKE '%[file %' OR m.meta_value LIKE '%[file* %');
"

結果が 1 件でもあり、かつバージョンが 6.2〜6.2.3 なら最優先で対応してください。

手順2: 6.2.4 以降へ更新する

# 更新前にバックアップ(DB + wp-content)
wp db export "backup-$(date +%Y%m%d%H%M).sql"
tar czf "wp-content-$(date +%Y%m%d%H%M).tar.gz" wp-content

# 更新して確認
wp plugin update contact-form-7
wp plugin get contact-form-7 --field=version   # 6.2.4 以上であること

管理画面からなら「プラグイン → Contact Form 7 → 今すぐ更新」で同じです。更新後は添付欄つきフォームから実際にテスト送信し、通知メールに添付ファイルが届くことを確認しておくと安心です。

すぐ更新できない場合の暫定策

検証環境での確認待ちなど、当日中に更新できない事情があるときは次のどちらかで「前提条件」を外します。

  1. 添付欄を一時的に外す(フォーム編集画面で [file] / [file*] タグを削除して保存)
  2. 後述の手順4のサーバー設定で、一時保存ディレクトリへの外部アクセスを遮断する

どちらも根本対策ではないため、更新が終わるまでのつなぎとして扱ってください。

手順3: 置かれたファイルが残っていないか点検する

Contact Form 7 は、添付ファイルを wp-content/uploads/wpcf7_uploads/ 配下の一時ディレクトリに保存し、メール送信後に削除します。正常運用ならこの配下にファイルはほとんど溜まりません。 今回の不具合では弾かれたファイルが残るため、まずここを確認します。

UP=wp-content/uploads/wpcf7_uploads

# 1) 配下に残っているファイルを新しい順に一覧(.htaccess / index.php はプラグイン自身が置く保護用)
find "$UP" -type f ! -name '.htaccess' ! -name 'index.php' -printf '%TY-%Tm-%Td %TH:%TM\t%s\t%p\n' | sort -r | head -50

# 2) 実行・表示される危険がある拡張子だけを抽出
find "$UP" -type f -regextype posix-extended \
  -iregex '.*\.(php[0-9]?|phtml|phar|pht|phps|html?|svgz?|js|shtml)$' -ls

# 3) 一時ディレクトリの中に、プラグイン以外が置いた .htaccess が無いか
find "$UP" -mindepth 2 -name '.htaccess' -ls

wp-config.php の定数 WPCF7_UPLOADS_TMP_DIR で保存先を変更している場合は、そのパスに読み替えてください。2) の $UP を wp-content/uploads に変えて実行すれば、uploads 全体の PHP 系ファイルも点検できます(通常 uploads に PHP ファイルは存在しません)。

アクセスログで痕跡を見る

一時保存ディレクトリは外部から閲覧される理由が無い場所です。ここへの GET が 200 で返っていたら要調査です。

# nginx の例(Apache なら /var/log/apache2/access.log*)
zgrep -h '/wp-content/uploads/wpcf7_uploads/' /var/log/nginx/access.log* \
  | awk '$9 ~ /^2/ {print $1, $4, $7, $9}' | sort | uniq -c | sort -rn | head -30

# フォーム送信 API への POST を送信元 IP 別に集計(短時間の大量送信は機械的な探索の兆候)
zgrep -h 'POST /wp-json/contact-form-7/v1/contact-forms/' /var/log/nginx/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

不審なファイルが見つかったら

  • 削除前に退避し(ハッシュ・時刻を記録)、該当時刻のアクセスログを保全する
  • wp core verify-checksums と wp plugin verify-checksums --all で改ざん有無を確認し、見知らぬ管理者が増えていないかも見る
  • 実行された形跡があれば、改ざん前のバックアップからの復旧とパスワード・DB 認証情報・認証用キーの変更までを一続きで行う

手順4: サーバー側で多重防御を入れる

今回 RCE に至る条件は「ファイルが残る」「ディレクトリ一覧で場所が分かる」「.phar 等が PHP として実行される」の重なりでした。更新とは別に、サーバー側でこの連鎖を断っておくと、次に似た不具合が出たときの被害を抑えられます。

Apache(バーチャルホスト設定に記述)

Debian / Ubuntu 標準の Apache は AllowOverride None のため、プラグインが一時ディレクトリに置く .htaccess の保護は効きません。 保護は .htaccess ではなくバーチャルホスト側に書きます。

# /etc/apache2/sites-available/example.conf の <VirtualHost> 内
# DocumentRoot は環境に合わせる

# 1) ディレクトリ一覧を全体で無効化
<Directory "/var/www/html">
    Options -Indexes
</Directory>

# 2) uploads 配下: 一覧なし・.htaccess による上書きを無視・PHP系は実行させない
<Directory "/var/www/html/wp-content/uploads">
    Options -Indexes -ExecCGI
    AllowOverride None
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar|pht|phps)$">
        Require all denied
    </FilesMatch>
</Directory>

# 3) Contact Form 7 の一時保存ディレクトリは外部から一切読ませない
#    (添付はプラグインがサーバー内部でメールに添付するため、Web 公開は不要)
<Directory "/var/www/html/wp-content/uploads/wpcf7_uploads">
    Require all denied
</Directory>

sudo apachectl configtest && sudo systemctl reload apache2

nginx

# server { } 内。既存の「location ~ \.php$」より前に置く
# ^~ を付けると、以降の正規表現 location(PHP 実行)に渡らない

# Contact Form 7 の一時保存ディレクトリは外部から一切読ませない
location ^~ /wp-content/uploads/wpcf7_uploads/ {
    deny all;
}

# uploads 配下の PHP 系ファイルは実行させない
location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|phar|pht|phps)$ {
    deny all;
}

# ディレクトリ一覧は既定で off だが、明示しておく
autoindex off;

sudo nginx -t && sudo systemctl reload nginx

設定が効いているかの確認

# どちらも 403 が返れば OK(404 でも外部から読めない点は同じ)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/uploads/wpcf7_uploads/
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/uploads/test.phar

再発防止の観点

被害が RCE まで伸びるかはサーバー設定次第でした。「uploads で実行させない」「一覧を出さない」「一時領域を閉じる」を平時の設定にしておけば、次に似た不具合が出ても被害を抑えられます。あわせて、フォームの添付欄が本当に必要かを見直し、必要なら limit と filetypes オプションで容量と種類を絞りましょう。

まとめ

  • Contact Form 7 6.2〜6.2.3 は、ファイル添付欄のあるフォーム経由でログイン不要で任意ファイルを置かれる(CVE-2026-114432)
  • Debian / Ubuntu 標準構成の Apache では RCE に至るおそれ、それ以外でも HTML / SVG の配信に悪用されうる
  • 6.2.4 以降へ更新し、wpcf7_uploads 配下と uploads 全体に不審なファイルが無いか点検する
  • 検証コードの一般公開が予定される 2026-11-19 より前に更新を終える
  • サーバー側で「uploads で実行させない・一覧を出さない・一時領域を閉じる」を入れておくと、次の類似脆弱性でも被害を抑えられる

出典

関連記事

本記事のような設定の抜けは、Web サイトを 9 つの守りでまるごと守るサイトドックでまとめて対策できます → https://sitedock.jp

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?