WordPressプラグインの脆弱性報告はどのように行われるのか?

WordPress セキュリティ、緊急アラート&パッチ情報、脆弱性報告、対応、Patch Applied、WordPress プラグイン 脆弱性報告、脆弱性への対応・対策、Security Report、Fix & Updates

先日「WordPressのセキュリティリリースが増えているのはAIのせい?」というニュースを書いたが、その後SNSなどで「最近のWordPressは脆弱性が増えている」と考える人が多いように見受けられる。実態としては「生成AIでバグハントの頻度・精度が上がったために脆弱性として報告されるケースが増えている」だけなのだが。

さて、この記事では実際にバグハントがどのように行われるのかと、その裏側について解説したい。これは筆者が公開しているプラグインGianismで実際に発生したケースである。

なお、経路としてはWordPressプラグインレビューチームから連絡が来る場合と、Patchstackから連絡が来る場合の2つのケースがある。基本的にはどちらも同じフローだが、この記事ではPatchstackから報告が来るケースを取り上げよう。

バグハンターからの連絡

さて、筆者はある日、WordPressのSlackで次のようなDMを受け取った。

Patchstackの人からDMが!(さらしてすいません)

Patchstackのサイト上に脆弱性情報として記録され、その内容はプラグイン作者だけが知ることができる。そのためにはPatchstackにVendorとして登録し、なおかつプラグインのreadme.txtにdisclosureリンク(上記のDMに記載)を書いておくことが求められる。

筆者はFAQセクションにリンクを設定した。

実はこのときすぐ対応しようとしたのだが、以下の2点でつまずいてしまった。

  1. mVDP(managed Vulnerability Disclosure Program=脆弱性開示プログラム管理画面)へのアカウント登録。筆者のWordPressアカウントのメールアドレスとVendor登録しようとした会社のドメインが異なっていたことが原因。
  2. readme.txtに貼ったdisclosureリンクがtrunkにあるだけではダメだった様子。最新タグのreadme.txtも書き換える必要があった。

上記の理由から筆者は「GitHubにイシュー登録して、あとでやろう」と思っていたのだが、なんとそのまま30日が経過し、脆弱性が開示されてしまう。

開示後の対応

Claude Codeでイシューの棚卸しをしていたところ、「緊急度高」で脆弱性対策をすべし、と指摘され、筆者はこのイシューの存在を思い出した。まだVendor登録は済んでいなかったのだが、30日が過ぎて脆弱性が開示されたことにより、筆者はその脆弱性がXSSであり、投稿者以上の権限を持つ者が悪意のあるJavaScriptを入稿できてしまう可能性があることを知る。

修正自体はPCP (Plugin Check Plugin)を使うことでエスケープ漏れを片っ端からつぶしただけである。ほんとうはこちらもCI/CDに組み込んでチェックの自動化を行うべきなのだが、ひとまず後回しに。脆弱性というのはこのようにシンプルな見落としから発生することが多い。

パッチバージョンの公開(6.0.1)を行うと、どうやらPatchstackの中の人が修正状況を確認してくれたようで、状態が”patched”に変更された。非常にありがたい話である。

Patchstackでの表示

また、新バージョンが公開されたことでreadme.txt記載のPINコードが有効になり、筆者はmVDPに入れるようになった。本来であれば、このmVDPで開発者だけに脆弱性の詳細が開示される。

脆弱なままのプラグインはどうなる?

さて、筆者は「忘れる」という怠惰によって数ヶ月脆弱性を放置してしまったが、場合によってはそのまま対応しない、という可能性もありえる。脆弱性を放置すると、WP Scanの脆弱性データベースなどに公開されてしまうので評判的にピンチなのだが、もうすでにメンテナンスしていないプラグインは修正されないだろうし、なにより、これらのセキュリティ系のサービス・プラグインを利用していないユーザーは自分が脆弱なプラグインを利用していることを知る由も無い。

昨今効率化の一気に進んでいるプラグイン・レビューチームがこの事態を静観していることはなく、おそらくだが、脆弱性の修正されないプラグインはどんどん公式ディレクトリから取り下げられるようになるだろう。そして、そうすると先述の通りユーザーはそれを知らないので「そういえば最近ずっとアップデートされないな」というだけになる。「危険な無知」とでも呼ぶこの状況を放っておくのはよくないので、おそらくプッシュ型の通知機能が検討されることになるだろう。

まとめ

以上、WordPressプラグインの脆弱性報告の仕組みについて実例を交えつつ解説した。一般的にWordPressの脆弱性は実際の被害が発生してから公表されるのではない。潜在的な問題があった時点で開発者へ報告がいき、しかるべき時期を経てから公開される、という流れだ。筆者は愚かにも放置してしまったが、最前のシナリオとしては「自動更新で常に最新バージョンを使っていれば問題ない」である。

もちろんこれはあくまでベストケースであり、たとえばすべてのプラグインを自動更新に設定している人は稀だろう。プラグインを更新しなかったことによるリスクをどう回避するかがWordPressの未来を決定づけるはずだ。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください