WordPressプラグイン Frontend Admin by DynamiApps（スラッグ `acf-frontend-form-element`）に、CVSS 9.8（CRITICAL） の認証バイパス CVE-2026-75816 があります。対象は 3.29.12 以前のすべてのバージョンで、3.29.13 で修正されています。
最悪の場合に起きるのは管理者アカウントの乗っ取りです。ログインしていない攻撃者が、管理者の登録メールアドレスを自分のアドレスへ書き換え、そのうえでWordPress本体のパスワード再設定を実行する、という流れになります。攻撃に利用者の操作は要りません。
修正版3.29.13の公開日は2026年8月25日で、CVEとして公表されたのは9月6日です。つまり更新自体は2週間前から用意されています。まだ3.29.12以前で動いているサイトが対象です。WordPress.orgの公開データでは、このプラグインの有効インストールは約9,000件です。
今すぐ行う対策
- ✓プラグインを 3.29.13 以降へ更新する。 2026年9月8日時点でWordPress.orgが配布している最新版は 3.29.13（2026年8月25日公開）です
- ✓まず入っている版を確認する。 管理画面なら「プラグイン」一覧、WP-CLIなら `wp plugin get acf-frontend-form-element --field=version` で出ます
- ✓複数サイトを運用しているなら一括で確認する。 `wp plugin list --format=csv` を各サイトで回し、`acf-frontend-form-element` の版を集めます
- ✓更新後に、乗っ取りの痕跡を確認する。「ユーザー」一覧で管理者権限のアカウントとそのメールアドレスを見て、身に覚えのない変更・見知らぬ管理者アカウントがないかを確認します
- ✓管理者宛に届いた通知メールをさかのぼる。 下の「乗っ取られたかどうかの見分け方」で説明するとおり、WordPress本体はメールアドレス変更時に変更前のアドレスへ通知を送ります
- ✓すぐに更新できない事情があるなら、そのプラグインを一時的に停止する。 フロントエンド投稿フォームが止まりますが、未認証で管理者を奪われるリスクよりは軽い判断です
このスコアの出所を明示します。 上の 9.8 は、このCVEの採番機関であるWordfenceが付けた CVSS v3.1 の値です。ベクタは `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`、弱点の種類は CWE-287（不適切な認証） とされています。
NVDにはまだNIST自身（Primary）の評価が載っていません。2026年9月8日時点のステータスは `Received` で、上の値はNVD上では Secondary 扱いです。後日NISTが別の数字を付ける可能性があります。
あわせて、CISAが2026年9月7日に登録した判定（SSVC）も見ておく価値があります。exploitation: none（悪用の観測なし）、automatable: yes（自動化して一斉に狙える）、technicalImpact: total（成功時の影響は全面的）です。まだ攻撃は観測されていませんが、自動化しやすい種類の欠陥だと公的機関が判定しているということです。KEV（悪用が確認された脆弱性カタログ）には、2026年9月8日時点で登録されていません。
何が起きていたのか：数字でない post_id が権限チェックを飛ばしていた
このプラグインは、フロントエンドに設置した入力フォームから投稿やユーザー情報を編集させるものです。編集対象は `post_id` という値で指定します。
投稿を編集する処理（`ActionPost::conditions_logic()`）には、「その投稿を編集する権限があるか」を確かめる `current_user_can( 'edit_post', $post_id )` のチェックがあります。問題は、そのチェックにたどり着く前に置かれていた早期リターンでした。3.29.12 のコードは次のとおりです。
// 3.29.12 — main/frontend/forms/actions/post.php
$post_id = $settings['post_id'] ?? 'none';
if( ! is_numeric( $post_id ) ){
return $settings; // ← 数字でなければ、権限チェックへ進まずそのまま通す
}
if ( ! current_user_can( 'edit_post', $post_id ) ) {
// 本来ここで弾かれる
}`post_id` が数字でなければ、権限チェックを一切通さずに設定を返してしまいます。CVEの説明によれば、ここに `user_1` のような数字でない文字列を渡すことで、未認証のフォーム送信が任意のユーザーレコードへ流れる、という筋になります。
3.29.13 の修正は、この早期リターンの意味を反転させたものです。
// main/frontend/forms/actions/post.php
+ // 'none' と 'add_post' だけが正当な非数値の状態。
+ // それ以外は想定外の入力なので、下の権限チェックを迂回させてはならない。
+ if ( in_array( $post_id, array( 'none', 'add_post' ), true ) ) {
+ return $settings;
+ }
+
if( ! is_numeric( $post_id ) ){
- return $settings;
+ $settings['post_id'] = 'none';
+ return $settings;
}正当な非数値（`none` と `add_post`）だけを明示的に許可し、それ以外の数字でない値は `none` に潰す、という形になりました。この差分は、WordPress.org公式のプラグインリポジトリ（SVN）にある 3.29.12 と 3.29.13 のタグを直接読んで確認しています。
なお、このプラグインは2026年8月に権限まわりの修正を3回続けて出しています。3.29.11 と 3.29.12 が8月19日、3.29.13 が8月25日です。3.29.11 では「ユーザーの作成・編集における権限チェックの迂回」、3.29.12 では「メールアドレス・表示名・ウェブサイトのユーザー項目に不足していた権限チェックの追加」がそれぞれ入っています。部分的に上げるのではなく、3.29.13 以降まで上げてください。
ここは断定しません：3.29.12での完全な攻撃経路までは公開情報で確認できない
当サイトの方針として、裏が取れなかった部分は正直に書きます。
CVEの説明文は、メールアドレス項目の `pre_update_value` に権限・所有者チェックが無いことを、この攻撃のもう半分として挙げています。ところが公式リポジトリのソースを実際に読むと、3.29.11 では確かにチェックが無い一方で、3.29.12 の同じ関数には既に `current_user_can( 'edit_user', $user_id )` が入っています。
つまり当サイトが自分の目で確認できたのは次の2点です。
（1）3.29.11以前は、メールアドレス項目そのものが無防備だった。
（2）3.29.13で、投稿アクション側の権限チェック迂回が塞がれた。
「3.29.12 以前のすべてが影響を受ける」という影響範囲は、採番機関であるWordfenceの判定をそのまま採っています。3.29.12 で最後まで残っていた経路の詳細までは、公開情報だけでは再現できませんでした。ただし、どちらの読み方をしても対処は同じです。3.29.13以降へ上げてください。
乗っ取られたかどうかの見分け方
この攻撃の最終段は「メールアドレスを書き換えてからパスワード再設定」です。そこにWordPress本体の仕様が痕跡を残します。
`wp_update_user()` でユーザーのメールアドレスが変更されると、WordPress本体は `[サイト名] Email Changed` という件名の通知を、変更前のアドレス宛に送ります（本文は「あなたのメールアドレスが ◯◯ に変更されました」という確認文）。今回のプラグインはこの `wp_update_user()` を呼んでメールアドレスを書き換えるため、攻撃が成功していれば、その管理者の元のアドレスに身に覚えのない通知が届いているはずです。
- ▸管理者の受信箱を「Email Changed」で検索する。 日本語環境でも件名は英語のままのことがあります
- ▸「ユーザー」一覧で、管理者権限アカウントのメールアドレスを目視で確認する。 見覚えのないドメインになっていないか
- ▸身に覚えのない新規ユーザー、特に管理者権限のアカウントがないかを確認する。
- ▸通知が来ていない＝安全、ではない。 `send_email_change_email` フィルタで通知は抑止できますし、そもそもメール送信が失敗していれば届きません。届いていないことを根拠に「無事だった」と結論づけないでください
- ▸痕跡が見つかった場合は、全管理者のパスワードを変更し、投稿・プラグイン・テーマファイルの改ざんまで確認する。 メールアドレスを戻すだけでは終わりません
この件から持ち帰れること
「想定外の入力なら、とりあえずそのまま通す」は権限チェックを飛ばす典型的な形です。今回の早期リターンは、書いた時点では「数字でないIDは編集対象ではないのだから、判定の対象外」という意図だったはずです。ところがその判定の先に権限チェックが置かれていたため、想定外の値を渡した側が、判定ごとすり抜けられる構造になっていました。
未知の入力に出会ったときの既定の振る舞いを「許可」ではなく「拒否」に倒す。修正後のコードが `none` に潰しているのは、まさにその形です。
もうひとつ。フロントエンド編集系のプラグインは、WordPress本体とは別に権限判定を持ちます。本体の権限モデルが正しくても、プラグイン側の入口で迂回できれば意味がありません。会員サイトや投稿フォームを外部に開けているサイトほど、この種のプラグインの更新は最優先で当ててください。