WordPressのヘルプデスク用プラグインに認証なしの脆弱性　3.4.0に上げる

米国立標準技術研究所（NIST）は11月13日（日本時間）、WordPress用のプラグイン「ELEX WordPress HelpDesk & Customer Ticketing System」の脆弱性「CVE-2026-119077」を脆弱性データベースのNVDに載せた。認証のない攻撃者が、サイトのサーバーでコードを実行し得る。修正版の3.4.0は11月12日に出ているので、使っているサイトはバージョンを確かめて上げる。

3.3.9以前の全バージョンが当たる

このプラグインはELEXtensionsが作るヘルプデスクの機能で、問い合わせをチケットとして受け付け、担当者に割り振る。メールで届いた問い合わせをチケットにする機能や、チケットの自動の振り分けも持ち、2020年5月からWordPress.orgで配られている。WordPress.orgの掲載ページの表示では、有効なインストールは200以上だ。NVDとWordPress.orgの記載は次のとおりだ。

• 対象: WordPress用プラグイン「ELEX WordPress HelpDesk & Customer Ticketing System」
• 当たるバージョン: 3.3.9以前の全バージョン
• 直ったバージョン: 3.4.0（WordPress.orgで11月12日に公開）
• CVE番号: CVE-2026-119077
• 深刻度: CVSS 3.1で9.8（脆弱性を登録した米Wordfenceの評価）
• 弱点の種類: CWE-502（信頼できないデータの逆シリアル化）

NVDの説明では、原因は2つ重なっている。サーバー側で利用者の認証を確かめておらず、さらに外から送られたデータを逆シリアル化する時に、作ってよいクラスを絞っていなかった。このため、認証なしにPHPのオブジェクトを作らせ得る。CVSSのベクトルは、ネットワーク越しに、権限も利用者の操作も要らずに攻撃できる評価だ。NVDの状態は「Deferred」で、NIST自身の評価は付いていない。9.8はWordfenceが付けた値だ。

管理画面でバージョンを確かめる

WordPressの管理画面の「プラグイン」の一覧で、このプラグインのバージョンの表示を見る。3.3.9以前なら当たる。WP-CLIを使えるサーバーでは、WP-CLIの一般的なコマンド「wp plugin get elex-helpdesk-customer-support-ticket-system --field=version」でも確かめられる。複数のサイトを運用する組織は、各サイトの「wp-content/plugins」の下にこのプラグインのフォルダーがあるかも見たい。同じ一覧の「自動更新」の列で、このプラグインの自動更新が有効かどうかも分かる。

11月12日公開の3.4.0に上げる

3.4.0以降に上げる。直前の3.3.9に上げたサイトも、3.3.9は当たる範囲に入るので、もう一度上げる必要がある。3.4.0の変更履歴には「Security fix: Resolved a vulnerability issue.」とだけある。WordPress.orgで3.3.9と3.4.0のコードを比べると、3.4.0は、チケットの情報を読み出す20か所あまりの逆シリアル化の処理を、オブジェクトを作らせない独自の関数に置き換えていた。チケットの操作を受け付ける別の2つのファイルの同じ処理も、3.4.0で直っている。3.4.0の動作の条件はWordPress 3.0.1以上、PHP 7.1.8以上で、WordPress 7.1まで試験済みとある。条件は3.3.9と同じで、今の環境のまま上げられる。上げた後は、一覧でバージョンの表示が3.4.0以降になったかを確かめる。NVDの記載に回避策は無く、3.4.0以降に上げるほかない。

悪用の報告はまだ無い

CVE-2026-119077は、11月13日の時点で、米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っていない。NVDの記載にも悪用の報告は無い。WordPress.orgで3.4.0が公開されたのは11月12日13時ごろ（日本時間）で、NVDへの掲載はその約30時間後だった。Wordfenceの公告の本文は、編集部が11月13日に読もうとした時には取得できず、悪用の状況は確認できていない。

SAGUSでは当たらなかった

SAGUSは、開発に使う端末の作業場所を、grepで「elex-helpdesk」「wsdesk」と、WordPressの設定ファイルの名前「wp-config.php」で検索し、どれも見つからなかった。検索は、依存関係の定義と設定ファイル、コードの全体を対象にした。本番のサイトとRolloutのサイトでは、このプラグインの説明ファイルのパスとWordPressのログイン画面のパスに問い合わせ、どちらも404だった。SAGUSはこのプラグインを使っておらず、今回の脆弱性には当たらなかった。

編集部の見方

編集部は、この件の要点は修正版の変更履歴の短さにあると見る。3.4.0が出たのはNVDへの掲載の前日で、履歴の「脆弱性を直した」の一文からは、認証なしにコードを実行され得る深刻さは読めない。3.3.9も別の脆弱性の修正で、直前に上げた運用者ほど対応は済んだと思いやすい。導入が200以上の小さなプラグインでは、セキュリティの情報を追う人がいないサイトもあるだろう。WordPressのプラグインの自動更新を有効にしておけば、今回なら修正は掲載の前に入り得た。掲載で修正の中身が知られた後は、上げていないサイトが狙われやすくなると編集部は見る。