問い合わせフォームや決済フォームで広く使われる WordPress プラグイン Forminator(WPMU DEV 製・有効インストール 60 万件超)に、未認証で任意のファイルを読み出せるパストラバーサル脆弱性 CVE-2026-57815 が公開されました。
- 対象: Forminator を使っている Web 担当者・サイト運営者・制作会社
- 何が危険か: ログインしていない第三者が
wp-config.phpなどサーバー上のファイルを読み出せる - この記事でわかること: 自分のサイトが影響を受けるかの確認、更新手順、更新までの間の多層防御、露出が疑われる場合の後始末
攻撃の再現手順やペイロードは扱いません。同じ被害を防ぐための確認・対策に絞ってまとめます。
何が起きる脆弱性なのか
CVE-2026-57815 は、Forminator のファイルのダウンロード/エクスポート処理で、渡されたパスの検証が不十分だったことに起因します。本来は公開用ディレクトリ内のファイルだけを返すべきところ、パスをさかのぼる指定を弾けず、公開ディレクトリの外にある任意のファイルを読み出せてしまうというものです(パストラバーサル / CWE-22)。
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-57815 |
| 対象プラグイン | Forminator(WPMU DEV) |
| 影響バージョン | 1.55.0.2 以前のすべて |
| 修正バージョン | 1.55.1 |
| 種別 | パストラバーサル(任意ファイル読み取り / CWE-22) |
| CVSS 3.1 |
7.5(High) AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
|
| 認証要否 | 不要(未認証) |
| 公開日 | 2026-07-13(採番: Patchstack) |
ポイントは 「認証不要(PR:N)」かつ「機密性への影響が高(C:H)」 という組み合わせです。ファイルの改ざんや削除はできません(I:N / A:N)が、読めてしまうこと自体が致命的になり得ます。とりわけ危険なのが WordPress の設定ファイル wp-config.php で、ここには次のような機密情報が平文で書かれています。
- データベースのホスト名・ユーザー名・パスワード
- 認証キーと Salt(
AUTH_KEYなど。セッション Cookie の偽造に使われ得る) - テーブル接頭辞やデバッグ設定
つまり単体では「情報漏えい」でも、そこから得た DB 認証情報や秘密鍵を足がかりに、より深い侵害へ発展し得るため、実質的なリスクは CVSS 数値以上に高いと考えるべきです。出典は NVD の公式エントリを参照してください。
Step 1: 自分のサイトが影響を受けるか確認する
まずインストール済みの Forminator のバージョンを確認します。管理画面なら「プラグイン」一覧に表示されますが、複数サイトを運用しているなら wp-cli が確実です。
# インストール中のバージョンを確認
wp plugin get forminator --field=version
# 1.55.1 未満なら影響あり。更新可能かも確認
wp plugin list --name=forminator --fields=name,status,version,update,update_version
wp-cli を使えない環境では、プラグインの readme.txt に書かれた Stable tag で確認できます。
# 例: ドキュメントルートで実行(パスは環境に合わせて調整)
grep -i "stable tag" wp-content/plugins/forminator/readme.txt
Stable tag: 1.55.0.2 のように 1.55.1 より小さい表示なら、更新が必要です。
Step 2: プラグインを 1.55.1 以上へ更新する
最優先の対策は更新です。影響バージョンでは根本的に安全な回避策がなく、更新が唯一の確実な解決になります。
# バックアップを取ってから更新するのが安全(下の関連記事参照)
wp plugin update forminator
# 更新後に 1.55.1 以上になっているか必ず確認
wp plugin get forminator --field=version
自動更新を有効にしておくと、こうした緊急修正の適用漏れを減らせます。ただしプラグインの自動更新は互換性の問題を招くこともあるため、ステージング環境での確認とセットで運用するのがおすすめです(運用方針は関連記事にまとめています)。
Step 3: 更新できるまでの多層防御(サーバー側)
「すぐには更新できない」「検証に時間がかかる」場合の時間稼ぎとして、サーバー側で被害を抑える設定を重ねておきます。あくまで応急処置であり、更新の代わりにはなりません。
PHP から機密ファイルへの到達を制限する(open_basedir)
open_basedir を設定すると、PHP が読み書きできるディレクトリを限定でき、万一パストラバーサルが成立してもサイト領域の外までは辿らせにくくなります。
; php.ini またはプール設定(例: /etc/php/8.3/fpm/pool.d/www.conf)
; ドキュメントルートと一時ディレクトリだけに限定する
open_basedir = /var/www/example.com/:/tmp/
設定後は PHP-FPM の再起動が必要です。既存機能が壊れないよう、まずステージングで確認してください。
疑わしいパストラバーサル文字列を WAF 層で弾く(nginx)
リクエスト中にパスをさかのぼる典型的な文字列(../ やそのエンコード形)が含まれる場合に 403 を返す、保守的なルールです。正規の入力を巻き込まないよう、導入前後でフォーム送信が正常に動くか必ず確認します。
# server {} 内に追加
location / {
# デコード後のパスに親ディレクトリ参照が混ざるリクエストを拒否
if ($request_uri ~* "(\.\./|\.\.%2f|%2e%2e/|%2e%2e%2f)") {
return 403;
}
# 既存の処理(WordPress の try_files など)は下に続ける
try_files $uri $uri/ /index.php?$args;
}
Apache(.htaccess)での同等ルール
# .htaccess または VirtualHost に追加
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{THE_REQUEST} (\.\./|\.\.%2f|%2e%2e/) [NC]
RewriteRule .* - [F]
</IfModule>
wp-config.php 自体の防御も固めておく
Forminator に限らず、設定ファイルの読み取りは常に狙われます。ファイル権限を締め、直接アクセスも拒否しておきます。
# 所有者のみ読み書き(Web サーバー実行ユーザーからは読み取りのみ等、環境に合わせる)
chmod 400 wp-config.php
# wp-config.php や機密ファイルへの直接アクセスを拒否(nginx)
location ~* ^/(wp-config\.php|readme\.html|\.env|\.git) {
deny all;
return 404;
}
Step 4: 露出が疑われる場合の後始末
アクセスログに不審なリクエストの形跡がある、あるいは長期間更新できていなかった場合は、「すでに wp-config.php を読まれた」前提で認証情報を作り直します。読み取られた値は更新しない限り有効なままだからです。
-
DB パスワードを変更し、
wp-config.phpのDB_PASSWORDを新しい値に更新する。 -
認証キーと Salt を再生成して差し替える。これで既存のログインセッション(Cookie)が無効化され、盗まれた鍵での偽装を断てます。公式のシークレットキー生成サービス(
https://api.wordpress.org/secret-key/1.1/salt/)の出力でwp-config.phpの該当ブロックを丸ごと置き換えます。 - 全ユーザーのパスワードリセットを検討し、管理者アカウントに身に覚えのない追加がないか確認する。
- 設置後にファイルの改ざんがないか、正規の配布物と照合する。
なぜフォームプラグインが繰り返し狙われるのか
問い合わせ・予約・決済フォームは、未ログインの外部訪問者がデータを送り込める数少ない入り口です。攻撃者から見れば「認証を突破せずに触れる面」であり、ファイルのアップロードやエクスポートなどファイルを扱う機能を持つほど、パストラバーサルや任意ファイル操作の温床になりやすいという構造的な事情があります。
だからこそ、フォーム系プラグインは「入れたら終わり」ではなく、公開されている脆弱性情報を追い、修正が出たら速やかに当てる運用が欠かせません。今回のように未認証・情報漏えい系の脆弱性は、公開後に無差別スキャンの標的になりやすいため、公開から適用までの時間がそのまま被害確率に直結します。
まとめ
- Forminator 1.55.0.2 以前は、未認証でサーバー上の任意ファイルを読める CVE-2026-57815(CVSS 7.5) の影響を受ける。
-
wp-config.phpの DB パスワードや認証キーが読まれる恐れがあり、実害は数値以上に大きい。 - 最優先は 1.55.1 以上への更新。すぐ更新できない場合は open_basedir・WAF ルール・ファイル権限で被害を抑える(応急処置)。
- 露出が疑われるなら、DB パスワードと認証キー/Salt を作り直し、セッションを無効化する。
関連記事
- 「.git」「.env」の公開を1行で防ぐ設定(nginx/Apache/WordPress)
- WordPress自動更新を全部ONにしない運用──コア/プラグイン/テーマ別の正しい設定
- WordPressの改ざんを防ぐファイル権限とPHP実行制限(uploads対策)
本記事のような脆弱性の見落としや設定の抜けは、Web サイトを 9 つの守りでまるごと守るサイトドックでまとめて対策できます → https://sitedock.jp