BookingPress(CVE-2026-11823)未認証SQLインジェクションでDB露出──確認と対策

WordPress の予約プラグイン BookingPress Appointment Booking Pro に、ログイン不要(未認証)で悪用できる SQL インジェクション CVE-2026-11823(2026年7月1日公開)が見つかりました。

• 予約フォームを設置しているサイト運営者が対象です。
• 放置すると、データベース内のユーザー名やパスワードのハッシュを外部から読み出される恐れがあります。
• この記事を読めば、影響有無の確認 → 5.7.2 への更新 → 更新できないときの暫定対応まで、コピペで一通り対処できます。

何が起きたのか(CVE-2026-11823 の概要)

項目	内容
対象	BookingPress Appointment Booking Pro(WordPress 予約プラグイン)
脆弱性	SQL インジェクション(CWE-89)
影響バージョン	5.7.1 以前すべて
修正バージョン	5.7.2
認証	不要(未認証の第三者が悪用可能)
CVSS v3.1	7.5(High) / AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
影響	データベースの読み出し(情報漏えい)。※改ざん・削除は伴わない

CVSS ベクタの C:H/I:N/A:N が示すとおり、これは 「読まれる」種類の脆弱性です。攻撃者はサイトを書き換えるのではなく、DB の中身を静かに抜き出します。具体的には wp_users テーブルのログイン名やパスワードハッシュが対象になり得ます。ハッシュはオフラインでの解析や、使い回しパスワードの悪用につながるため、「表示上は何も壊れていない=安全」ではありません。

根本原因は公式アドバイザリで次のように説明されています。予約スロット割り当て処理 bpa_assign_staffmember_to_slots() が、store_service_date という POST パラメータに対して stripslashes_deep() を適用したうえで、$wpdb->prepare() などのパラメータ化を行わずにそのまま SQL の LIKE 句へ埋め込んでいた点にあります。

• 出典(NVD): https://nvd.nist.gov/vuln/detail/CVE-2026-11823

本記事は再発防止・防御目的の解説です。悪用可能な攻撃文字列(ペイロード)や再現手順は記載しません。

自分のサイトが影響を受けるか確認する

まず、BookingPress を使っているか・使っているならバージョンはいくつかを確認します。WP-CLI が使える環境なら次の 2 コマンドで済みます。

# インストール済みプラグインとバージョンを一覧(スラッグは環境で確認)
wp plugin list --fields=name,status,version,update

# BookingPress のバージョンだけ取り出す(スラッグは list の name 列で確認)
wp plugin get bookingpress-appointment-booking --field=version

update 列が available になっていれば更新が来ています。バージョンが 5.7.1 以下なら影響ありです。

WP-CLI が無い場合は、管理画面の プラグイン > インストール済みプラグイン で「BookingPress」のバージョン表記を確認してください。

対策1:すぐに 5.7.2 へ更新する(最優先)

修正版が出ているので、まず更新が正解です。更新前にバックアップを取ってから実行します。

# 1) 更新前バックアップ(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

# 2) BookingPress を更新
wp plugin update bookingpress-appointment-booking

# 3) 更新後のバージョン確認(5.7.2 以上になっていること)
wp plugin get bookingpress-appointment-booking --field=version

管理画面から更新する場合も手順は同じで、更新→バージョンが 5.7.2 以上になったことの確認まで必ず行ってください。

すぐ更新できないときの暫定対応

検証環境での動作確認が必要ですぐ更新できない、というケースもあります。その場合の暫定策です。あくまで一時しのぎで、確認が取れ次第 5.7.2 へ更新してください。

(1) 予約機能を一時停止する(最も確実)

# プラグインを一時的に無効化(予約受付は止まる点に注意)
wp plugin deactivate bookingpress-appointment-booking

(2) WAF を有効にする

Cloudflare / Wordfence / ModSecurity(OWASP CRS)などの WAF は、典型的な SQL インジェクション文字列を既定ルールでブロックします。導入済みならルールが有効になっているかを確認し、未導入なら暫定的にでも前段に置くと被害面を下げられます。ただし WAF はすり抜けが起こり得るため、根本対処は更新です。

なぜ「プラグインの SQL インジェクション」は繰り返すのか

同じ被害を防ぐという観点で、原因パターンを 1 つだけ押さえておきます。WordPress では、外部から来た値を SQL に混ぜるときは 必ず $wpdb->prepare() でプレースホルダ経由にするのが鉄則です。今回の不具合は、この基本が抜けていたことに尽きます。

<?php
// NG:外部入力をそのまま LIKE 句へ連結(今回と同種のパターン)
$date = stripslashes_deep( $_POST['store_service_date'] ); // ← 危険
$rows = $wpdb->get_results(
    "SELECT * FROM {$wpdb->prefix}bpa_slots WHERE service_date LIKE '%{$date}%'"
);

// OK:プレースホルダでパラメータ化する
$date = sanitize_text_field( wp_unslash( $_POST['store_service_date'] ) );
$like = '%' . $wpdb->esc_like( $date ) . '%';
$rows = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}bpa_slots WHERE service_date LIKE %s",
        $like
    )
);

ポイントは 3 つです。wp_unslash() で正しくスラッシュ除去し、$wpdb->esc_like() でワイルドカードをエスケープし、$wpdb->prepare() の %s に渡す。自作テーマ・プラグインを触る制作会社の方は、この形をテンプレートとして持っておくと同種の事故を防げます。

運営者ができる恒久対策(このプラグイン以外にも効く)

プラグイン単位でモグラ叩きをするより、「1つ穴が空いても被害を最小化する」土台を作るほうが効きます。

(1) 更新運用を仕組み化する
使っていないプラグインは削除し、残すものは更新方針を決めておきます(コア/プラグイン/テーマ別の考え方は関連記事参照)。

(2) DB ユーザーの権限を絞る(被害の封じ込め)
WordPress 用の MySQL ユーザーに FILE や他 DB へのアクセス権を与えないことで、万一 SQL インジェクションを受けてもサーバ上のファイル読み出しや別 DB への波及を防げます。

-- WordPress 専用ユーザーは「そのDBだけ」に権限を限定する(FILE/SUPER は付与しない)
CREATE USER IF NOT EXISTS 'wpuser'@'localhost' IDENTIFIED BY '<強いパスワード>';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP, REFERENCES
  ON wordpress_db.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;

(3) アクセスログの監視
予約系エンドポイント(admin-ajax.php など)への異常なアクセス増や 500 エラーの多発は、探索行為のサインになることがあります。日次でざっと眺める習慣をつけます。

# admin-ajax.php へのアクセスを件数の多い IP 順に確認(nginx の例)
awk '$7 ~ /admin-ajax\.php/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head

侵害が疑われるときの初動

CVSS ベクタどおり「読み出し」中心の脆弱性なので、気づかないうちに情報だけ抜かれている可能性があります。露出期間があった場合は次を検討してください。

1. 管理者・利用者パスワードのリセット(ハッシュが読まれた前提で扱う)。
2. 認証キー/ソルトの再生成(wp-config.php の AUTH_KEY 等を 公式のシークレットキー生成 API で更新)。ログインセッションが無効化されます。
3. 不審な管理者アカウントが増えていないか wp user list --role=administrator で確認。
4. バックアップからの復元が必要になったときのために、復元手順を事前に手に馴らしておく(関連記事参照)。

まとめ

• CVE-2026-11823 は BookingPress 5.7.1 以下の未認証 SQL インジェクション。DB の中身(ユーザー名・パスワードハッシュ)を読まれる。
• 対処は明快で、まず 5.7.2 へ更新。すぐ更新できないなら一時無効化 + WAFでしのぐ。
• 恒久策は 更新運用の仕組み化・DB ユーザーの権限最小化・ログ監視。1 つのプラグインに閉じない土台づくりが効く。

関連記事

• WordPress自動更新を全部ONにしない運用
• WordPressセキュリティ 最低限やることチェックリスト10
• 改ざんされても30分で戻せるWordPressバックアップ&復元手順

本記事で触れた設定(セキュリティヘッダや公開ファイルの露出など)は、Webサイトを9つの守りでまるごと守る「サイトドック」の月次の定期健診でまとめて確認できます → https://sitedock.jp