Contact Form 7に認証不要ファイルアップロード｜6.2.4以降への更新と添付を点検

Contact Form 7は2026年10月29日、認証なしで任意のファイルをアップロードできる問題を6.2.4で修正しました。影響版は6.2から6.2.3です。開発元は、ファイルアップロード項目があり、HTTPサーバーがディレクトリ内容を公開する設定のサイトを、理論上の攻撃対象と説明しています。該当する運用者はプラグインの更新を優先し、添付ファイルの受け付けと一時保存先の公開状態を確認してください。

10月30日に確認したWordPress.orgの配布ページでは、後続の6.2.4.1が公開済みで、FormDataTree-PHPの2.0.10への更新が記載されています。本稿は脆弱性の修正と更新後の確認を扱うニュース解説です。6.2.4が最初の修正版であることと、現在取得する配布版が6.2.4.1であることを区別します。

認証不要のアップロードとファイル残存を組み合わせる問題

開発元の6.2.4リリース告知によると、複数の欠陥を組み合わせることで、本来は検証で拒否されるファイルを送信し、送信直後に削除されるはずのファイルを残せます。単に問い合わせメールの添付に失敗する不具合ではなく、外部の第三者がサーバー上へファイルを置く境界に関わる問題です。

ただし、この告知だけで全利用サイトの遠隔コード実行や情報流出が確認されたとはいえません。アップロード先でスクリプトを実行できるかなどは別の条件です。また、確認した開発元資料には実環境での悪用状況やCVSS値の説明がありません。本記事ではそれらを推定せず、版と設定に基づいて対応を判断します。

WordPress管理者のパスワードを変更したことは、この認証不要の入口の修正にはなりません。既存のWordPress 7.1.4のセキュリティ更新記事で扱う本体修正を適用していても、Contact Form 7の稼働版は別に確認する必要があります。外部保守へ任せている場合も、「WordPressを更新済み」という回答だけでプラグインの対応を完了扱いにしないでください。

対象判定は版・フォーム・HTTPサーバーを一組にする

最初に各サイトの管理画面でContact Form 7の版を記録し、公開中のフォームにfileまたはfile*の項目があるかを調べます。必須か任意か、添付欄が何個あるか、どのページから送信できるかを一覧にします。見た目の入力欄だけでなく、埋め込み先や停止したはずのフォームが残っていないかも確認する方法を提案します。

次に、実際の一時保存先と、その場所へ対応するURL・サーバー設定を確認します。公式のファイルアップロード手順では、通常は検証後に一時フォルダーへ移動し、メールへ添付して送信した後に削除する流れです。既定の保存先はwp-content/uploads/wpcf7_uploadsですが、アップロード先の変更やWPCF7_UPLOADS_TMP_DIRの指定があれば異なります。既定パスだけを調べて終わらないようにします。

開発元の更新推奨は影響版に限らず全利用者を対象としています。6.2より古い版を今回の脆弱性の影響版へ勝手に追加することはできませんが、今回の強化を利用するための更新は別に検討できます。新しい配布版はWordPress 7.1以上、PHP 8.3以上を要件としているため、古い構成では先に互換性と移行計画を確認してください。

ディレクトリ一覧の停止とファイルアクセス制限は別

ディレクトリ一覧とは、フォルダーのURLへアクセスした際にファイル名などのリストが表示される機能です。一覧を出さないことは重要ですが、既知のファイルURLへのアクセスまで拒否した証明にはなりません。逆に、一覧が表示されることだけで今回の攻撃や侵害を断定することもできません。更新、一覧の抑止、保存先のアクセス制御を別々の確認項目にします。

Apache HTTP ServerのOptions資料では、Indexesが有効でDirectoryIndexに該当するファイルがないと、mod_autoindexが一覧を返します。次は管理者が実際の保存先へ合わせて使う設定例です。他のOptionsを不用意に置き換えず、一覧を外す意図を明確にしています。適用前に構文を検査し、対象VirtualHostと子ディレクトリの上書きも確認します。

<Directory "/srv/www/example/wp-content/uploads/wpcf7_uploads">
    Options -Indexes
</Directory>

nginxのautoindex資料では、一覧の出力はautoindexで制御され、既定はoffです。既定値だけを根拠にせず、実際に一致するserver・locationでonへ変更されていないかを調べます。以下は対象URLへ対応する設定例で、WordPressをサブディレクトリへ置いた構成や独自保存先ではそのまま使えません。既存のlocation選択との関係を確認して適用します。

location /wp-content/uploads/wpcf7_uploads/ {
    autoindex off;
}

これらはHTTPサーバーの一覧機能を抑える例であり、Contact Form 7の欠陥そのものを修正するものではありません。レンタルサーバーでは管理画面や保守窓口を使い、実際の一時保存先に有効な設定を確認します。確認のために本番へ攻撃用ファイルを置く必要はありません。承認した検証環境で、通常のディレクトリアクセスの応答と有効設定を照合します。

拡張子は拒否リストから許可リストへ変わる

6.2.4では、実行可能なスクリプトとみなされ得るファイル名を処理するwpcf7_antiscript_file_name()が、危険な拡張子を列挙する方式からセーフリスト方式へ変更されました。リスト外の拡張子は安全な代替へ変換されます。公式の既定一覧にはPDF、TXTや主要な画像・音声・動画形式が含まれます。

フォームのfiletypes設定と、このファイル名の処理は別の役割です。「受け付ける種類に設定したから、添付先で元の拡張子が維持される」とは限りません。ZIPなどを業務で受け取るサイトは、更新後の実ファイル名と後段の処理を確認します。送信画面が成功しても、受付担当の自動仕分けや取込処理が拡張子を前提にしていれば影響します。

開発元はwpcf7_file_extension_safelistフィルターでリストを調整する方法を案内しています。ただし、従来どおり動かすために任意の拡張子を一括許可する運用は勧めません。本サイトの提案は、業務上必要な形式、メール受信後の扱い、保存先での実行可否を確認してから例外を最小化し、追加した形式ごとに試験結果を残すことです。

独自コードと添付試験を更新計画へ含める

もう一つの互換性変更はwpcf7_unship_uploaded_file()です。第2引数$optionsが必須になり、第3引数$uploaded_filesが追加されています。公式は第3引数が参照で渡される変更も記載しています。通常のフォーム設定だけで利用する場合と、テーマ・独自プラグインからこの関数を呼ぶ場合を分けて確認します。引数不足が見つかったら、現行の関数定義に合わせて修正し、検証環境で添付を試します。

更新前にはフォーム定義、メール設定、独自フック、導入版を記録し、復旧用バックアップを用意します。次に検証環境へ現在の公式配布版を適用し、サイトで許可しているPDFや画像などの無害な試験ファイルを送信します。画面の成功表示、通知メールの到着、添付の内容と名前、一時保存後の削除を一連の作業として確かめます。

拒否の試験では、業務で許可しない無害な形式や上限を超える試験ファイルを用い、期待したエラーになるかを見ます。公式手順が示すfiletypesとlimitは明示設定が推奨されています。例えば、次のフォームタグはPDFとTXTを2MBまで受け付ける例です。これは脆弱性を回避する万能設定ではなく、更新後の受け入れ条件を明確にする例です。

[file your-file filetypes:pdf|txt limit:2mb]

メールの「ファイル添付」欄には、この例なら[your-file]を指定します。フォームタグ全体を貼る欄ではありません。公式はメール添付の合計に25MBの上限も示しているため、複数欄を持つフォームでは各欄の上限だけでなく合計も確認します。添付できないときに種類や容量の制限を無条件に広げず、PHPのアップロードエラー、検証結果、メール配送を切り分けます。

残存ファイルの調査は更新の成功と分ける

更新で新たな悪用を防ぐことと、未更新期間の調査は別です。保存先に不審なファイルが残っている場合は、調査担当と連携し、時刻、所有者、ハッシュ、関連するアクセスログを保全します。既存ファイルをブラウザーで開いて動作を試したり、証拠を残す前にまとめて削除したりしないことを提案します。

ファイルが見つからない場合も、通常の削除処理、保存期間、ログ欠落を考慮します。今回確認した開発元告知には、特定のログ文字列で攻撃を確定するルールは示されていません。受信した不審な添付や異常な通信があれば、自サイトの記録から調査し、一般公開された修正情報だけで被害の有無を決めないでください。

完了条件は、対象サイトで適切な修正版が実際に稼働し、一覧公開と保存先の設定を確認し、通常の添付・拒否・削除と独自連携が期待どおり動くことです。問い合わせの停止を避けるために脆弱な旧版へ戻す前に、必要なら添付機能を一時停止するなど業務側と代替手段を調整してください。本稿の設定例と確認手順は運用提案であり、当サイトでの実測や全構成の動作保証ではありません。