第１ 結論
Contact Form 7 6.2から6.2.3には，認証なしで本来拒否されるファイルをアップロードし，送信後に削除されるべきファイルを残せる脆弱性があった。
公式発表によれば，脆弱性の影響版は6.2から6.2.3であり，セキュリティ修正は6.2.4に含まれる。
令和８年１１月９日現在，WordPress.orgが配布する現行版は6.2.4.1である。
したがって，6.2.4へ止めるのではなく，WordPress 7.1以上及びPHP 8.3以上という現行版の要件とサイトの互換性を確かめ，6.2.4.1又はそれより新しい修正版へ更新するのが基本となる。
更新後は，管理画面の版番号だけで完了とせず，フォーム表示，送信，添付ファイル，担当者の実受信及び拒否すべき拡張子の扱いを試験する。
また，更新したことは更新前の侵害がなかったことの証明ではないため，必要に応じてログとファイルを確認する。
第２ どのような脆弱性であったか
１ 認証なしの任意ファイルアップロード
Contact Form 7の公式発表は，複数の不備を組み合わせることにより，通常は検証で拒否されるファイルをアップロードし，通常は送信直後に削除されるファイルを残せる問題であったと説明している。
管理者又はログイン利用者だけの問題ではなく，認証していない外部者からの要求が問題になる。
ただし，「Contact Form 7を使う全サイトで直ちに任意コードが実行される」という発表ではない。
公式発表は，理論上の対象として，ファイルアップロード欄を持つフォームがあり，HTTPサーバーがディレクトリー内容を公開表示する設定になっている場合を挙げている。
２ ファイル添付欄がないサイトでも更新する
公式発表は，直接の脆弱性が確認された版を6.2から6.2.3としている。
同時に，セキュリティ強化は全利用者に関係するため，全利用者へ6.2.4への更新を推奨している。
ファイル添付欄がないことは，更新を不要にする理由ではない。
フォームの設定は後から変わることがあり，プラグインの共通処理も更新されるため，現行の修正版へそろえる方がよい。
第３ 6.2.4と6.2.4.1の関係
セキュリティ修正が公表された版は6.2.4である。
6.2.4では，実行可能なスクリプトとして認識され得るファイル名の処理について，従来の禁止リスト方式から，許可する拡張子のセーフリスト方式へ変更された。
6.2.4.1の変更履歴には，内部ライブラリーであるFormDataTree-PHPを2.0.10へ更新したことが記載されている。
したがって，「脆弱性は6.2.4.1で初めて修正された」と説明するのは正確ではない。
6.2.4がセキュリティ修正版であり，6.2.4.1は令和８年１１月９日現在の現行版として選ぶ，と区別すると分かりやすい。
第４ 更新前に確認すること
１ 完全な版番号と動作要件
プラグイン一覧でContact Form 7の完全な版番号を確認する。
6.2，6.2.1，6.2.2又は6.2.3であれば影響版に当たるため，優先して更新する。
現行版6.2.4.1について，WordPress.orgはWordPress 7.1以上及びPHP 8.3以上を必要条件としている。
WordPress本体又はPHPが古い場合は，プラグインだけを強行更新せず，本体，PHP，テーマ及び他のプラグインを含む更新順序と復旧方法を決める。
２ バックアップとフォーム一覧
ファイルとデータベースのバックアップを取得し，復旧方法を確認する。
そのうえで，Contact Form 7のフォーム一覧，掲載ページ，送信先，返信先，ファイル添付欄の有無，許可拡張子及び最大サイズを記録する。
更新後に送信できない場合，更新前の設定を記録していなければ，脆弱性対策による仕様変更か，従来からの設定不備かを分けにくい。
業務上重要な問い合わせフォームは，実際の担当者と試験時刻を決めてから更新する。
第５ セーフリスト変更で起こり得る影響
6.2.4では，既知の危険な拡張子を除く方式ではなく，許可された拡張子を通す方式が採られた。
公式発表の既定セーフリストには，画像，音声，動画，PDF及びテキスト等の拡張子が含まれる。
業務で独自の拡張子又は圧縮ファイルを受け付けていた場合，更新後に添付できなくなる可能性がある。
その場合も，動かすためだけにセーフリストを広げず，そのファイルを外部者から受け取る必要性，マルウェア検査，保存場所，実行可否及び保管期間を確認する。
独自コードでContact Form 7のアップロード後処理関数を直接利用している場合は，引数の変更の影響も確認する。
通常の管理画面設定だけを利用するサイトと，独自PHPコードを追加したサイトを同じ試験で済ませない。
第６ 更新後の試験
１ 一般的な表示・送信試験
フォームの表示，通常送信，自動返信，迷惑メール及び担当者の実受信は，更新前後で一通り確認する。
具体的な確認方法は，AIでホームページを作る方法―ChatGPT・Codex・Claude CodeからWordPress公開までの第７を参照されたい。
２ 6.2.4固有の添付試験
ファイル添付欄ごとに，許可する拡張子とサイズを設定どおり受け付け，担当者宛てメールへ添付されることを確認する。
許可しない拡張子，二重拡張子，過大なファイル等が拒否されることも確認する。
添付ファイルの公開URLを推測して第三者が取得できないか，アップロード後に不要なファイルが残り続けないかも確認する。
実在する依頼者の資料や個人情報を試験用に使わず，内容のないテストファイルを使う。
第７ 更新前の侵害を確認する場合
修正版への更新は，将来同じ脆弱性を悪用される危険を下げる措置である。
更新前に悪用がなかったことまでは証明しない。
影響版を利用し，ファイル添付欄を公開していた場合は，対象期間のアクセスログ，アップロード先，WordPress及びサーバーのファイル更新，未知のPHPファイル，管理者アカウント並びに不審な外部通信を確認する。
WAFが要求をブロックした記録は重要であるが，ブロック数だけで侵入の有無を決めない。
Wordfenceのレポートの読み方は，Wordfenceのアクティビティレポートの読み方で説明している。
侵害又は個人情報漏えいのおそれがある場合は，ログを保全し，調査範囲と分からない範囲を区別する。
第８ 更新できない場合の暫定対応
互換性の問題で直ちに更新できない場合は，影響版を公開したまま長期間放置しない。
ファイル添付欄を含むフォームの公開停止，代替の連絡手段，サーバー側WAF，アクセス制限及び監視の強化を検討し，修正版へ移行する期限を決める。
暫定対応は脆弱性そのものを修正するものではない。
フォームを止めた場合は，利用者が連絡不能にならないよう，電話，別の安全なフォーム等の代替手段を分かりやすく案内する。
第９ 関連記事
AIでホームページを作る方法―ChatGPT・Codex・Claude CodeからWordPress公開まででは，Contact Form 7の接続，メール設定及び実受信試験を説明している。
PHPの緊急セキュリティ更新とWordPress保守では，バックアップ，互換性試験，更新後検証及び復旧手順を整理している。
第１０ 出典
①Contact Form 7 6.2.4の公式リリース
②WordPress.orgのContact Form 7配布ページ
③Contact Form 7のファイルアップロードとメール添付