0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@jiis-sasaki

The Events Calendar(60万サイト)に未認証RCE 2件──6.17.5更新とコメント設定の確認

0
Posted at

イベント告知にWordPressプラグイン「The Events Calendar」を使っているサイト向けの記事です。
2026年9月、このプラグインに未認証(ログイン不要)で任意コードを実行され得る脆弱性が2件公表されました。いずれもCVSS 9.8の緊急です。
この記事では「自分のサイトが該当するか」「どう直すか」「すぐ更新できないときに何を止めるか」を、コピペで確認できるコマンド付きでまとめます。

何が起きたのか

The Events Calendar は wordpress.org 公称で 60万サイトが有効化しているイベントカレンダープラグインです。2026年9月12日にNVDへ登録された2件は、どちらも**認証不要・リモートからのコード実行(RCE)**に分類されています。

CVE 概要 影響バージョン 修正版 CVSS v3.1
CVE-2026-78159 parse_array 経由のコード実行(ウィジェットのclasses検証不足) 6.17.3 以前 6.17.3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CVE-2026-78006 is_safe_widget_instance の検証回避によるPHPオブジェクトインジェクション 6.17.4 以前 6.17.4.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

ポイントは3つです。

  1. 修正版が2段階に分かれている。 6.17.3.1(2026-08-26)で1件目、6.17.4.1(2026-09-10)で2件目が塞がれました。「8月末に更新したから大丈夫」という状態が一番危険で、6.17.4 のままだと CVE-2026-78006 が残ります。2026-09-17 公開の 6.17.5 が現在の最新で、REST APIまわりの権限チェック強化も入っています。
  2. 悪用の前提は「イベントページのコメントが有効かどうか」。 どちらもイベント投稿タイプ(tribe_events)のコメント欄を入口として、外部から投稿されたブロックマークアップが単一イベントページの描画処理を通ることが条件です。コメントを出していないサイトは未認証の経路が成立しません。逆に言えば、バージョンとコメント設定の2点を確認すれば自分の状況が判定できます。
  3. 広範な悪用の報告は現時点で出ていません。 ただし公開済みの緊急脆弱性であり、修正版の配布も進んでいるため、更新の遅れがそのままリスクになります。

攻撃の成立条件は上記までにとどめ、再現手順は扱いません。以下は「同じ被害を防ぐ」ための確認と対処です。

1. 自分のサイトが該当するか3分で確認する

バージョンを見る

WP-CLIが使える環境ならこれが最速です。

# 現在のバージョン
wp plugin get the-events-calendar --field=version

# 更新可能なプラグイン一覧(まとめて棚卸しする場合)
wp plugin list --update=available --fields=name,version,update_version

管理画面の場合は「プラグイン」一覧で The Events Calendar のバージョンを確認します。6.17.4 以下なら該当です。Events Calendar Pro などのStellarWP系アドオンを併用している場合は、本体と一緒に更新対象に含めてください。

イベントページのコメント設定を見る

WordPressコア側の既定値と、個々のイベント投稿の設定を両方見ます。

# 新規投稿の既定(open = コメント受付)
wp option get default_comment_status

# イベント投稿ごとのコメント受付状態
wp post list --post_type=tribe_events --post_status=any \
  --fields=ID,post_title,comment_status --format=table

comment_status が open のイベントが1件でもあれば、未認証の経路が開いている可能性があります。プラグイン側にもイベントページへコメントを表示するかどうかの設定(Show comments)があるので、管理画面のイベント設定も併せて確認してください。

判定は単純です。

  • 6.17.4 以下 かつ コメントが open → 最優先で対応
  • 6.17.4 以下 だがコメントは全て closed → 未認証の経路は成立しにくいが、緊急脆弱性が残った状態なので早めに更新
  • 6.17.5 → 対応済み

2. 対処:更新する

更新前に必ずバックアップを取ります。

# DBとファイルのバックアップ(保存先は公開ディレクトリの外へ)
wp db export ~/backup-db-$(date +%Y%m%d).sql
tar czf ~/backup-files-$(date +%Y%m%d).tar.gz wp-content

そのうえで更新し、バージョンを確認します。

# 最新へ更新
wp plugin update the-events-calendar

# 反映確認(6.17.5 以上になっていること)
wp plugin get the-events-calendar --field=version

イベント一覧・単一イベントページ・カレンダー表示が崩れていないかを目視で確認してください。テーマ側でテンプレートを上書きしている場合は、ステージング環境で先に当てるのが安全です。

3. すぐに更新できないときの一時的な緩和

検証待ちなどで即時更新できない場合は、入口であるコメントを閉じるのが確実です。いずれも制限を強める方向の設定です。

# 既存のイベント投稿のコメントを一括で閉じる
for id in $(wp post list --post_type=tribe_events --post_status=any --format=ids); do
  wp post update "$id" --comment_status=closed
done

# 新規投稿の既定も閉じる
wp option update default_comment_status closed

コメント機能自体は残したい場合は、少なくとも次の2つを有効にします。

# 全コメントを承認制にする
wp option update comment_moderation 1

# コメント投稿をログインユーザーに限定する
wp option update comment_registration 1

ただし、承認前のコメントでも描画処理を通り得るという指摘があるため、承認制だけを頼りにしないでください。ログインユーザー限定にすれば未認証の経路は塞がりますが、これはあくまで時間稼ぎで、更新の代替にはなりません。

4. すでに踏まれていないかを確認する

RCEの怖いところは、更新しても入られた後の痕跡は消えない点です。6.17.4 以下でコメントを開けていた期間がある場合は、次を確認してください。

# コア・プラグインのファイル改ざん検査
wp core verify-checksums
wp plugin verify-checksums --all

wp plugin verify-checksums は wordpress.org 配布のプラグインのみ検査できます(有料アドオンは対象外)。

# uploads 配下のPHPファイル(本来存在しないはず)を更新日時付きで列挙
find wp-content/uploads -type f -name '*.php' -printf '%TY-%Tm-%Td %p\n'

# 身に覚えのない管理者アカウントが増えていないか
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 不審な常駐(mu-plugins / スケジュール実行)
ls -la wp-content/mu-plugins/
wp cron event list

アクセスログ側では、イベントページ(既定のパーマリンクは /events/ 配下)へのPOSTの偏りを見ます。

# イベントページへのPOSTを送信元IPごとに集計(nginx)
grep -E '"POST /events/' /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

該当するものが見つかった場合は、その場でファイルを消すより先にバックアップからの復元を検討してください。侵入経路が塞がっていない状態での部分的な削除は、再設置されて終わります。

5. 同じ被害を繰り返さないために

今回のように「更新が2段階に分かれる」ケースは、手動更新の運用だと取りこぼしが起きます。

  • 入口になるプラグインだけでも自動更新を有効にする。 フォーム・カレンダー・会員機能など、未認証ユーザーが触れる機能を持つものが優先です。
wp plugin auto-updates enable the-events-calendar
wp plugin auto-updates status --all
  • 脆弱性情報を定点観測する。 IPA の重要なセキュリティ情報や JVN iPedia を週1で見るだけでも、緊急の見落としはかなり減ります。
  • 更新までの時間を埋める仕組みを持つ。 仮想パッチ(サイト固有の弱点に合わせた個別対応)とWAF(全サイト共通の攻撃を一律遮断)は役割が違います。今回のようにピンポイントの経路が公開された脆弱性では前者が、広く飛んでくる無差別スキャンには後者が効きます。
  • 戻せる状態を保つ。 改ざんの確認は「正常な状態のバックアップ」があって初めて意味を持ちます。

まとめ

  • The Events Calendar(60万サイト)に未認証RCEが2件。6.17.4 以下は該当、最新は 6.17.5。
  • 修正は 6.17.3.1 と 6.17.4.1 の2段階。6.17.4 で止まっていると1件残るので、バージョンは必ず目視確認する。
  • 悪用の前提はイベントページのコメントが有効なこと。wp post list --post_type=tribe_events で comment_status を確認する。
  • 即時更新できないならコメントを閉じる。承認制だけに頼らない。
  • 更新後は wp core verify-checksums と uploads 配下のPHP、管理者アカウントを確認する。

出典

関連記事

本記事のような更新の遅れや設定の抜けは、Webサイトを9つの守りでまるごと守るサイトドックでまとめて対策できます → https://sitedock.jp

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?