短い間隔で続くWordPressの修正版から見える狙われどころ

つくば市のホームページ制作会社

10月6日、WordPress 7.1.3が公開されました。セキュリティ修正7件と不具合修正4件を含む保守版で、公式は早めの更新を勧めています。7.1系では、9月17日の7.1.1、9月22日の7.1.2に続いて、ひと月足らずのあいだに三度目のセキュリティ修正となりました。

間隔がこれだけ詰まると、正直なところ「また更新か」と感じます。ただ、三つの修正版の中身を横に並べてみると、どこが繰り返し狙われているのか、運用のどこを見直せばよいのかがかなり具体的に見えてきます。今回は公式の発表と各版の変更内容をもとに、中小企業のサイトを預かる立場から読み解いてみます。

九月半ばから続いた修正版の流れ

まず時系列を整理しておきます。9月17日の7.1.1は大きめの保守版で、セキュリティ修正11件に加え、コアの不具合修正17件、ブロックエディターの不具合修正21件を含んでいました。報告されたセキュリティ上の問題の多くは、ログインしたユーザーによる操作が前提のものです。

その5日後、9月22日に出た7.1.2は修正1件だけの版でした。ただしその1件は、ページテンプレートの解決処理におけるパストラバーサルで、認証なしで狙え、条件次第ではリモートからのコード実行につながるという重いものです。変更されたファイルも wp-includes/template.php ひとつに絞られており、急ぎで出された修正だったことがうかがえます。

そして10月6日の7.1.3です。今回は1件ごとの深刻さよりも、管理画面、書き出し、埋め込み、問い合わせ処理と、触れている範囲の広さが目立ちます。

7.1.3で直された箇所

公式の発表に挙がっている修正は次のとおりです。

  • コメント管理画面での保存型XSS。承認待ちのコメントを経由して悪用できるもので、Trail of Bitsの研究者が報告
  • WP_Http::make_absolute_url() メソッドでのサービス妨害(DoS)
  • WordPress標準の書き出し機能(WXR形式)での二次的なSQLインジェクション
  • 投稿者(Author)権限のユーザーが記事を先頭に固定できてしまう弱点
  • 非公開や未公開の投稿に付いたコメントが、認証なしで見えてしまう問題。Patchstackの研究者が報告
  • Imgurの埋め込みでのXSS
  • {status}_{type} フックに渡る引数を偽装でき、アクション名の衝突につながる問題。WordPressのセキュリティチームが報告

変更されたファイルの一覧には、wp-admin/js/common.js、wp-admin/includes/export.php、REST APIの投稿コントローラー、カスタマイザー関連、class-wp-http.php、class-wp-oembed.php、class-wp-query.php、post.php が並びます。どれも日常的に動いている部品で、特定の設定をしているサイトだけの話ではないと考えておくほうが安全です。

コメント欄はずっと入口であり続けている

三つの版を並べて最初に気づくのは、コメントまわりの修正が何度も出てくることです。7.1.3では、承認待ちコメントを経由した管理画面での保存型XSSと、非公開投稿のコメントが認証なしで見える問題が直されました。さかのぼると7.1.1でも、段落の整形処理を経由した認証不要の保存型XSS(コメントの承認が条件)や、ログインしたユーザーなら誰でもコメントの親子関係を付け替えられる問題が修正されています。

ここで押さえておきたいのは、「承認しなければ表に出ないから安全」とは言い切れないという点です。報告の説明を読むかぎり、承認前のコメントが管理画面に表示される段階が関わっています。つまりスパムの山を確認するために管理画面を開く、その日常の作業が攻撃の起点になりうるわけです。

実務の面では、コメント機能をそもそも使っていないサイトなら、設定でコメントの受け付けを止めておくのがいちばん手堅い対策です。会社案内が中心の中小企業サイトでは、テーマの初期設定のままコメント欄が開いていて、誰も読まないスパムが溜まり続けているという例を今でもよく見かけます。使っているサイトでも、古い記事のコメント受け付けを一定期間で閉じる設定は検討する価値があります。

権限の低いアカウントと書き出し機能

二つ目の傾向は、投稿者や寄稿者(Contributor)といった、権限の低いアカウントを前提にした問題が続いていることです。7.1.3の「投稿者が記事を先頭に固定できる」件は影響こそ限られますが、7.1.1では寄稿者以上の権限で任意の投稿を上書きできる問題や、下書きと承認待ち記事のスラッグが寄稿者以上に見えてしまう問題が直されています。REST APIのテンプレート処理での、認証済みユーザーによるパストラバーサルも同じ版に含まれていました。

外部のライターに寄稿者アカウントを発行している、退職した担当者のアカウントが残っている、といった状況は珍しくありません。こうしたアカウントのパスワードが漏れれば、権限が低くても修正前の穴を突く足がかりになります。更新とあわせて、使われていないアカウントを整理しておくと安心です。

もうひとつ見落としやすいのが、書き出し機能での二次的なSQLインジェクションです。二次的というのは、先にデータベースへ保存された値が、あとで別の処理に使われる段階で問題を起こす型を指します。WXR形式の書き出しは、サーバー移行やサイトの複製、バックアップの代わりとして制作会社がよく使う機能です。普段は誰も触らない機能でも、移行作業のときに一斉に使われる、という点は意識しておきたいところです。

古い系統への移植と「支援の対象は最新版だけ」

WordPressには、修正を古いメジャー版にも移植するという慣例があります。7.1.1のときは、7.0から4.7までのすべての系統に修正版が出ました。発表によると、7.0から6.7までは11件すべての影響を受け、系統が古くなるにつれて影響を受ける件数は減り、4.7では6件だったとされています。7.1.2の1件は、4.7までのすべての系統が影響を受けていました。4.6以前には、もうセキュリティ修正は届きません。

7.1.3についても、修正は厚意として、セキュリティ修正の対象となっている4.7までの系統に必要に応じて移植され、準備ができ次第出していくと説明されています。ここで公式が毎回添えているのが、「積極的に支援しているのは最新版だけ」という一文です。古い系統に修正が届くのはあくまで厚意であり、不具合修正までは届きません。

PHPの版や、更新の止まったプラグインとの相性を理由に、古い系統に据え置いているサイトは今もあります。移植版が出ている以上、すぐに危険というわけではありませんが、最新版より遅れて届く可能性があることや、修正の範囲がセキュリティに限られることは、据え置きを選ぶときの前提として持っておくべきでしょう。

続く修正版を受け止める段取り

では、短い間隔で届く修正版にどう付き合えばよいのでしょうか。制作会社として保守を受け持つ立場から、確認しておきたい点を挙げます。

まず、マイナー版の自動更新が有効になっているかどうかです。公式の発表でも、バックグラウンドでの自動更新に対応しているサイトでは更新が自動で始まるとされています。自動更新を止めて手作業で管理している場合は、修正版の公開から適用までに何日かかっているかを一度振り返ってみてください。7.1.2のように認証なしで狙える重い修正が出たとき、その日数がそのまま無防備な期間になります。

次に、更新後に何を確かめるかです。今回の7.1.3は、管理画面のスクリプト、書き出し、カスタマイザー、埋め込み、投稿の問い合わせ処理に手が入っています。ステージング環境がある場合は、管理画面のコメント一覧、カスタマイザーでの表示確認、外部サービスの埋め込みを含むページ、記事一覧の並び順あたりを見ておくと、思わぬ表示崩れに早く気づけます。

そして、更新とは別に続けたいのが、コメント機能とアカウントの棚卸しです。三つの版を通して、コメントと低い権限のアカウントが繰り返し入口になっていることを考えると、使っていない機能を閉じ、使っていない人のアカウントを消すことは、修正版を待つ以外にこちらから打てる数少ない手立てです。

修正版が続くのは落ち着かないものですが、裏を返せば、外部の研究者やセキュリティ企業からの報告が受け止められ、数十人規模の協力で修正が形になっている表れでもあります。7.1.3の発表には、修正に関わった人の名前がずらりと並んでいました。届いた修正を淡々と当て、そのたびに中身へ少し目を通しておく。地味ですが、それがいちばん確かな付き合い方だと考えています。

消しても戻るWordPressの裏口は片付ける順番が肝心

つくば市のホームページ制作会社

改ざんされたWordPressサイトで、怪しいファイルを消したのに数秒後には元どおり、という経験がある制作者は少なくないと思います。セキュリティ企業のSucuriが、まさにその状態を作り出すマルウェアの分析結果をブログで公開しました。注入されたコードに残っていた目印から「SC」と呼ばれています。

Sucuriによると、SCは同じ裏口を少なくとも8か所に分けて置いています。.user.ini の auto_prepend_file で毎リクエストの前に読み込まれるローダー、wp-content 直下の db.php と advanced-cache.php というドロップイン、有効なテーマの functions.php の末尾に足されたブロック、そしてキャッシュ系に見せかけた偽プラグインが mu-plugins と通常の plugins の両方に置かれていたそうです。どれか一つでも残っていれば、ほかの全部を書き戻す作りになっています。

やっかいなのはファイル以外の置き場所です。本体はオプションテーブルの行にも圧縮して保存され、サーバーの共有メモリにも書き込まれていたとされています。さらにWordPressのcronに再配置用のフックが登録され、関連する亜種ではデータベースのトリガーで管理者アカウントを作り直す例もあったとのことです。ファイルを完璧に掃除しても、次のアクセスでデータベースや共有メモリから全部よみがえるわけです。

削除より先に止める

裏口としての働きも一通りそろっています。プラグイン一覧や更新チェックから自分を隠し、ユーザー一覧に出ない管理者を作り、セキュリティ系プラグインを無効化して削除する指示も受け取れます。指示はブロックチェーンの公開ゲートウェイ約20か所を経由して読み取る方式で、一つを遮断しても残りが使われます。ネットショップでは決済画面に不正なスクリプトを差し込まれるおそれもあるとされています。

Sucuriが示す片付け方の要点は「順番」です。まず auto_prepend_file の読み込み先を無害な中身に置き換えてから設定を外します。PHPがこの値を最大300秒キャッシュするため、先に読み込み先を消すとアカウント内のPHPがすべてエラーになるからです。次にデータベースの行、共有メモリ、cron、トリガー、隠れた管理者といったファイル以外の複製を消し、最後にファイルを一度に片付けます。テーマの functions.php は、目印で囲まれた部分だけを削ってテーマ本来のコードは残します。

中小企業のサイトを預かる立場で覚えておきたいのは、消したファイルが戻ってきたら「掃除が終わっていない合図」と受け取ることです。同じファイルを何度も消すより、データベースやcron、ユーザーテーブルに目を向けるほうが近道になります。共有サーバーでは共有メモリをホスティング会社にしか消せない場合もあるので、早めに相談できる窓口を確かめておくと安心です。侵入のきっかけは既知の脆弱性が多いとされているので、更新を止めないことと、復旧後に関係するパスワードをすべて変えることもあわせて進めたいところです。

innerHTMLに代わるHTMLの差し込み方がそろってきた

つくば市のホームページ制作会社

JavaScriptで画面の一部を書き換えるとき、多くの現場ではいまも innerHTML に文字列を代入する書き方が使われています。手軽で、どのブラウザでも動き、昔のサンプルコードもほとんどがこの形です。ところがこの秋、この「HTMLの文字列を差し込む」という基本動作のまわりで、ブラウザ側の整備が一段進みました。

9月16日にベータ版となったChrome 155では、HTMLを差し込む新しいメソッド群と、差し込みながら少しずつ流し込むストリーミング用のメソッドが入っています。Firefoxは今年2月の148で、差し込むときに危険な部分を取り除く setHTML() を先に出荷しました。安全性と速さという別々の課題に、同じ入り口から手が入りつつある、というのが今回の見立てです。

innerHTMLが抱えてきた二つの弱点

innerHTML の弱点は、大きく分けて二つあります。一つ目は安全性です。ユーザーが入力した文字列や外部から取ってきたデータをそのまま代入すると、紛れ込んだイベント属性などから任意のスクリプトが動く、いわゆるクロスサイトスクリプティング(XSS)の入り口になります。Mozillaの解説では、XSSは10年近くにわたってウェブの脆弱性の上位三つに入り続けているとされています。

二つ目は、同じような目的のメソッドが乱立していることです。Chromeのドキュメントでは、innerHTML、outerHTML、insertAdjacentHTML、createContextualFragment、setHTMLUnsafe などを並べたうえで、上書きなのか追記なのか、危険なタグを取り除くのか、スクリプトは実行されるのか、といった違いを即答できる開発者は少ないだろうと率直に書いています。確かに、制作の現場でもこの違いを意識して使い分けている例はあまり見かけません。

さらにもう一点、これらはすべて「差し込むHTMLが最初から全部そろっている」ことが前提です。サーバーから届く途中のHTMLを順に表示していく、というHTML本来の強みを、JavaScriptからの差し込みでは活かせませんでした。

危険な部分を取り除いてから入れるsetHTML

安全性の側の答えが、HTML Sanitizer APIと、その中心にある setHTML() です。使い方は innerHTML への代入をメソッド呼び出しに置き換えるだけで、差し込む前にブラウザが危険な要素と属性を取り除きます。MDNによると、既定の設定では script、iframe、embed、object などの要素や、onclick のようなイベント属性がすべて落とされ、さらにクリックジャッキングやなりすましに使われうる要素、コメント、data- 属性まで取り除かれます。

許可する要素を自分で指定することもできます。たとえば段落と太字だけを通す、といった「許可リスト型」の設定を作れば、想定外のタグは一切入りません。MDNは、危険なものを列挙して外す方式より、必要なものだけを列挙して通す方式のほうが安全だと説明しています。将来新しい危険な要素が見つかっても、許可リストに入っていなければ最初から通らないためです。

これまでこの役割は、DOMPurifyのような外部ライブラリが担ってきました。MDNは、ブラウザに組み込まれた方式のほうが、解析の文脈や実行されうるコードをより正確に把握できるため、安全な方のメソッドを使うなら外部ライブラリは不要になるという立場です。ただし、この機能はまだ主要ブラウザすべてでは使えない段階にあり、特にSafariが未対応である点は押さえておく必要があります。

名前をそろえた差し込み用メソッド群

Chrome 155で入るのは、差し込む位置ごとに名前をそろえたメソッド群です。要素の中身を置き換える setHTML() を軸に、要素ごと置き換える replaceWithHTML()、前後に足す beforeHTML() と afterHTML()、子要素の先頭と末尾に足す prependHTML() と appendHTML() が用意されています。ベータ版の告知では、これらが insertAdjacentHTML() の実質的な置き換えになると位置づけられています。

それぞれには、危険な部分の除去をしない「Unsafe」付きの版もあります。名前だけ見ると使ってはいけないもののようですが、Chromeのドキュメントは、これは入力の信頼度に応じてリスクを意識してほしいという注意書きであり、使うなという意味ではないと説明しています。Unsafe版では、オプションを指定すれば差し込んだHTML内のスクリプトを実行させることもでき、初期値は実行しない設定です。

地味な変更に見えますが、名前の規則が一つにまとまることの効果は小さくありません。コードを読んだ人が「このメソッドは安全側か」「どこに入るか」を名前だけで判断できるようになれば、レビューや引き継ぎのときの見落としが減ります。複数の人が触るサイトほど、こうした読みやすさは効いてきます。

届いた分から順に流し込むストリーミング

もう一つの柱が、ストリーミング用のメソッドです。上の各メソッドには streamHTML() や streamAppendHTML() のような対応版があり、Streams APIの書き込み口を返します。fetch() で取ってきた応答をそのままつなげば、サーバーから届いた分から順に画面へ反映できます。Chrome 151からは、応答を文字列の流れとして取り出す textStream() という便利なメソッドも加わり、中間の変換処理を書かずに済むようになりました。

これまで、ページの一部をJavaScriptで差し替える作りでは、応答をすべて受け取ってから一気に入れるのが普通でした。Chromeのドキュメントは、単一ページアプリケーションが最初の読み込み以外ではHTMLの逐次表示の恩恵を受けられないことを大きな弱点として挙げ、この新しいメソッドでそこを埋められるとしています。共通のフッターのような部品を別ファイルから取り込み、キャッシュを効かせる使い方も例に挙がっています。ただし、JavaScriptが動かないと表示されない以上、最初の画面で見える部分に使うのは避けるべきだという注意も添えられています。

同じ取り組みの一部として、HTMLの中で後から中身を差し替える仕組みも進んでいます。場所の目印を置いておき、ページの後半で template 要素に for 属性を付けて中身を送ると、目印の位置にはめ込まれる、という方式です。重い処理を待つ部分だけを後回しにして、先に骨組みを表示できます。こちらはChrome 150から使えるとされています。

ブラウザごとの足並みと当面の付き合い方

ここまでの話を整理すると、各ブラウザの足並みはまだそろっていません。setHTML() による安全な差し込みはFirefoxが先行し、Chromeは差し込み位置ごとのメソッドとストリーミングを前に進めています。一方でSafariはSanitizer APIに対応しておらず、MDNでも主要ブラウザで広く使える段階にはないと表示されています。

Chromeのチームは、新しいメソッドの形をそのまま使えるようにする補助ライブラリをnpmで公開しています。ただしドキュメント自身が、この補助ライブラリは実際には流し込まず、全部受け取ってからまとめて差し込むと明記しています。安全な差し込みの部分も、ブラウザ側のSanitizer APIがなければ成り立ちません。つまり補助ライブラリは、書き方を先取りするためのもので、機能そのものを全ブラウザで再現するものではない、と理解しておくのがよさそうです。

もう一つの論点は、Trusted Typesとの関係です。これは危険になりうる差し込み口に、決められた変換処理を必ず通させる仕組みです。Mozillaは、setHTML() を採用したあとなら、setHTML() だけを許して他の危険な差し込み方を禁じる厳しい設定にしやすくなり、今後の書き間違いによるXSSの再発を防げると説明しています。Content Security Policyが大がかりな改修を必要としたため広く普及しきらなかった、という反省も同じ記事で触れられており、今回の仕組みは「コードの置き換えを小さく済ませる」ことに重きが置かれています。

中小企業のサイト運用で見ておきたいところ

では、日々のサイト制作や保守で何をすればよいか。すぐに全面的な書き換えが必要な話ではありません。ただ、お知らせの一覧をJavaScriptで読み込んで表示する部分や、問い合わせフォームの入力内容を確認画面に出す部分など、外から来た文字列を innerHTML で差し込んでいる箇所は、どのサイトにも意外と残っています。まずはそうした箇所を把握しておき、Safariを含む主要ブラウザで使えるようになった段階で、setHTML() への置き換えを検討する、という順番が現実的です。

WordPressのサイトでも、テーマやプラグインのJavaScriptに同じような書き方が含まれていることがあります。自社で書いた追加のスクリプトであれば、置き換えの候補として一覧にしておくだけでも、将来の改修の見積もりがしやすくなります。外部のプラグインについては、作者側の対応を待つことになりますが、どの部分が外から来たHTMLを扱っているかを知っておくことには意味があります。

ストリーミングのほうは、表示速度を気にする規模の大きなサイトや、画面の一部を頻繁に差し替える管理画面のような作りで先に効いてくるはずです。普通のコーポレートサイトでは急いで取り入れる理由は少ないものの、HTMLを後から流し込めるようになると、ページの組み立て方の選択肢が確実に増えます。長く制作を続けてきた立場から見ても、innerHTML ひとつで何でも済ませていた時代から、目的に応じて安全な道具を選べる時代へと、基本の部分が静かに入れ替わり始めているように感じます。

WordPressにAPIキーを暗号化して預ける仕組みが入る見込み

つくば市のホームページ制作会社

決済、メール送信、地図、予約システム。WordPressで作るサイトは、外部サービスとつながるたびにAPIキーやパスワードのような「鍵」を預かります。その鍵がどこにどう保存されているか、納品のときに意識したことはあるでしょうか。WordPress本体の開発チームが公開した次期版の計画に、この鍵の保管方法を根本から整える「Secrets API」が入っています。

いまはプラグインの設定と同じ場所に平文で置かれている

Make WordPress Coreに8月末に投稿された提案によると、現在のWordPressには「秘密の値」を扱う専用の仕組みがありません。APIキーを必要とするプラグインは、サイトのキャッチフレーズなどと同じオプションテーブルに、暗号化せずに書き込むしかないのが実情です。提案者も、これはプラグイン作者の落ち度ではなく、ほかに選択肢がないためだと書いています。

問題は、このテーブルがデータベースのダンプやバックアップ、ステージング環境の複製にそのまま含まれることです。制作会社が検証用にコピーしたデータベースにも、クラウドに置いたバックアップにも、本番の鍵が読める形で残ります。一部のプラグインは独自に暗号化していますが、方式はばらばらで、まとめて点検することができません。

提案されている仕組みの中身

提案では、wp_set_secret()とwp_get_secret()を中心とした少数の関数と、値を包むオブジェクトが用意されます。保存時の暗号化は常に有効で、無効にする設定はあえて設けないとされています。暗号化できる設定にしておくと、結局多くのサイトが平文のまま残るからだ、という理由です。

ほかにも実務で効いてきそうな設計がいくつかあります。

  • 取り出した値はログやvar_dump()の出力では伏せ字になり、生の文字列を得るには明示的な呼び出しが必要
  • 値を取り出す経路にはフィルターを置かない。フィルターがあると、どのプラグインでも全部の鍵を横取りできてしまうため
  • 値の書き出し機能はなく、移行先やステージングでは入力し直す前提。確認用には値そのものではなく指紋(fingerprint)を使う
  • 上書きしても直前の値を一つだけ残し、入力ミスや切り替え途中の不具合に備える
  • WP-CLIからも扱えるようにし、コマンドの引数に鍵を書いてシェルの履歴に残る問題も減らす

既存の設定値を自動で移し替えることはせず、プラグイン作者が自分の判断で移す関数を用意する方針です。移した鍵には「作り直しが必要」という印が付きます。すでにバックアップに平文で残っている以上、暗号化しただけでは不十分で、鍵そのものを発行し直すのが本当の対策だという考え方です。

守れるものと守れないもの

提案は効果の範囲をはっきり線引きしています。守れるのは、データベースの流出、クラウドに置いたバックアップ、SQLインジェクションによる読み取り、設定画面のスクリーンショットやデバッグログからの漏れといった経路です。一方、WordPressの中でコードを実行されてしまった場合は防げません。鍵は使うために取り出せる必要があり、WordPressとして動くコードなら同じように取り出せるからです。

それでも、流出の多くはデータベースやバックアップ経由で起きるという前提に立てば、盗まれたデータベースの価値を下げる意味は大きいと考えられます。鍵へのアクセスが一か所にまとまるので、誰がいつ変えたかを記録できるようになる点も見逃せません。

7.2に入るかどうかと、制作現場の準備

9月18日に公開されたWordPress 7.2のロードマップでは、再認証を求める「sudoモード」やApplication Passwordsの強化と並んで、Secrets APIがセキュリティ面の柱に挙げられています。7.2のベータ1は10月20日から22日、正式版は12月上旬の予定です。ただしロードマップ自体が、掲載項目がすべて入るとは限らないと断っていて、提案でもベータ1までに間に合わなければ7.3へ見送るとしています。管理画面の設定画面は7.3以降に回し、まずはAPIとWP-CLIを固める段取りです。

本体に入ってもすぐに何かが変わるわけではなく、各プラグインが対応して初めて効果が出ます。それまでの間にできるのは、自分たちが納品したサイトにどんな鍵が保存されているかを把握しておくことでしょう。データベースを検証環境にコピーするとき、そこに本番の決済キーやメール送信の認証情報が入っていないか確かめるだけでも、事故の芽は減らせます。プラグインの更新履歴に対応の知らせが載りはじめたら、預かっている鍵を発行し直すよい機会になりそうです。

Firefoxが古い鍵交換方式を既定で使わなくなった

つくば市のホームページ制作会社

9月15日に公開されたFirefox 156で、HTTPS通信の最初のやり取り(TLSハンドシェイク)に関する既定の設定が変わりました。MDNの開発者向けリリースノートによると、有限体Diffie-Hellmanと呼ばれる方式のうち、ffdhe2048とffdhe3072という2つのグループが、既定では提示されなくなっています。目立つ新機能ではありませんが、サーバーを預かる側としては一度確認しておきたい変更です。

鍵交換は、ブラウザとサーバーが暗号化に使う鍵を安全に取り決めるための手順です。現在の主流は楕円曲線を使うECDHEで、今回外れたのはそれより前から使われてきた有限体の方式にあたります。リリースノートでは、これらのグループにしか対応していないサーバーとは接続の取り決めが成立しなくなる一方、ほぼすべてのサーバーはECDHEに対応していると説明されています。つまり、大半のサイトでは何も起きない見込みです。

変更の経緯と影響が出そうな場面

この変更はMozillaのバグ管理システムに約11か月前に寄せられた提案から始まっています。提案者は、Chromium系のブラウザがこれらのグループを使っていないことや、Firefoxがすでに量子計算機を見越した新しい鍵交換方式(X25519MLKEM768)に対応していることを挙げ、既定で無効にするよう求めていました。その後、FFDHE系の暗号スイートが有効な場合にだけこれらを鍵共有の候補に含める形に修正され、156で反映されています。

影響が出るとすれば、長く設定を見直していないサーバーです。たとえば社内向けの管理画面や、古い機器に組み込まれたウェブ設定画面、何年も前の設定ファイルを引き継いだまま動いているサーバーなどが考えられます。こうした環境で鍵交換の方式が有限体のものに絞られていると、Firefoxだけ接続エラーになるといった形で表面化するかもしれません。ChromeやSafariでは開けるのにFirefoxでは開けない、という問い合わせが来たときは、証明書だけでなく鍵交換の設定も疑ってみる価値があります。

確認の方法としては、外部のSSL診断サービスでサーバーが対応している鍵交換方式を調べるのが手軽です。ECDHE系、できればX25519が有効になっていれば今回の変更で困ることはまずありません。レンタルサーバーやマネージド環境であれば、事業者側で既に現代的な設定になっている場合がほとんどです。一方、nginxやApacheを自前で運用している場合は、暗号スイートや鍵交換の指定を昔の推奨設定からコピーしたままになっていないかを見ておきたいところです。設定を変えたときは、主要なブラウザで実際に開けるかを確かめてから本番に反映すると安全です。

証明書の有効期間が段階的に短くなる流れもあり、HTTPSまわりの設定は一度作れば終わりというものではなくなってきました。自社で管理しているサーバーや、納品後に手を入れていない顧客のサイトがあれば、次の保守のついでに暗号設定の一覧も眺めておくと安心です。

手を入れていないサイトにも届くブラウザ側の変更

つくば市のホームページ制作会社

ブラウザの更新情報というと新しいCSSやAPIに目が向きがちですが、9月に出たChrome 154とFirefox 155、156の開発者向けリリースノートを読み比べると、こちらが何も変えていなくても既存サイトの見え方や動き方に関わる変更がいくつか含まれていました。新機能の紹介とは少し角度を変えて、納品済みのサイトや社内システムを抱える側が気にしておきたい項目を並べてみます。

その1 HTTPのまま開くと確認画面が出るのが既定に

Chrome 154では、暗号化されていないhttpの接続でサイトを開こうとしたとき、利用者に確認を求める動作が既定で有効になりました。管理者向けには企業ポリシーでこの既定を制御する手段も用意されています。

公開サイトの多くはすでにHTTPS化されていますが、気になるのは周辺部分です。印刷物やQRコードに載せたhttpのURL、古い記事の中に残った内部リンク、LAN内で動く機器の管理画面などは、これまで素通りだったところで一度立ち止まる形になります。httpからhttpsへの転送がきちんと効いているか、紙の販促物に刷ったURLが今どうなっているかを、この機会に確かめておくと安心です。

その2 古い鍵交換方式だけのサーバーにFirefoxがつながらなくなる

Firefox 156では、TLSの接続開始時に既定で提示する鍵交換の方式から、有限体Diffie-Hellmanのffdhe2048とffdhe3072が外れました。リリースノートによると、これらの方式しか扱えないサーバーとは接続の取り決めが成立しなくなるとされています。

ほとんどのサーバーは楕円曲線を使うECDHEに対応しているため、一般的なレンタルサーバーやCDN経由のサイトで問題になることはまずないはずです。ただ、長く更新されていない自前のサーバー、古い業務用機器の管理画面、社内の古いシステムなどはこの限りではありません。「Firefoxでだけ開けない」という問い合わせが来たときの確認項目として覚えておくと役に立ちます。

その3 ポップオーバーやダイアログが意図せず閉じにくくなった

Chrome 154では、ポップオーバーやダイアログの外側を押したときに閉じる「ライトディスミス」の判定が、押し下げと離す操作の組み合わせからクリックイベントに切り替わりました。これにより、スマートフォンで画面をスクロールしただけのときや右クリックしたときに、開いていたメニューが勝手に閉じてしまう現象が起きにくくなります。

利用者にとっては素直な改善ですが、標準のpopover属性やdialog要素の挙動に合わせて独自の処理を足しているサイトでは、閉じるタイミングが以前と少しずれる可能性があります。スマートフォンでメニューを開いたまま縦にスクロールしてみる、といった簡単な確認をしておくとよさそうです。

その4 読み込みに失敗したモジュールを後から読み直せる

Firefox 155では、ネットワークエラーやMIMEタイプの誤りで読み込みに失敗したJavaScriptのモジュールが、失敗した状態のまま記憶されなくなりました。サーバー側が復旧すれば、同じ指定で読み込み直したときに成功するようになります。JSONやCSSのモジュール、動的なimportも対象です。

サーバーの一時的な不調やデプロイ中の瞬断で、ページを開き直すまで一部の機能が動かないという状況が減る方向の変更です。逆に言えば、配信側でMIMEタイプの設定を誤っていた場合、再試行のたびに同じ失敗を繰り返すことになるので、サーバー設定の見直しは引き続き大切です。

その5 開発者ツールの表示サイズが端数まで出るように

Firefox 156の開発者ツールでは、インスペクターで要素を選んだときに出るビューポートの幅と高さが、四捨五入されずに表示されるようになりました。ブラウザの拡大率が中途半端なときや高精細なディスプレイでは、これまでの表示が実際と食い違っていたためです。

レスポンシブデザインの切り替え幅を確かめる際、境界ぎりぎりで表示が崩れる原因を追うときに小数点以下の値が見えるのは助かります。制作中に表示される数字が以前と違って見えても、不具合ではなく正確になった結果と受け止めてよいでしょう。

どれも派手な変更ではありませんが、何年も前に納品したサイトほど影響を受けやすい種類の話です。隔週で更新が届く時代になり、こうした細かな挙動の変化は今後も積み重なっていきます。新機能を追いかけるのと同じくらい、既存のサイトに何が起きうるかを定期的に拾っておくことが、運用を任される側の地道な仕事になりそうです。

npmの公開に人の承認を挟む流れが強まっている

つくば市のホームページ制作会社

WordPressのブロックテーマやプラグインを作っていると、npmを使わない日はほとんどありません。ビルド用のツール一式も、CSSの処理も、小さな便利ライブラリも、たいていnpm経由で入ってきます。そのnpmで、9月に入ってから公開の手順まわりの変更が立て続けに発表されました。一つひとつは地味な更新ですが、並べてみると「パッケージを公開する最後の一押しは人間がやる」という方向がはっきり見えてきます。

今回は、GitHubの変更履歴(Changelog)に9月に載った三つの更新と、6月に予告されたnpm v12の既定値の変更、そしてその背景にある8月のワーム被害をつなげて、制作の現場から見た意味を考えてみます。

8月に起きたことを振り返る

話の出発点は、8月4日に起きたnpmパッケージの大規模な乗っ取りです。Datadog Security Labsの分析によると、キャッシュ用ライブラリとして広く使われているkeyvのGitHubリポジトリに不正なコミットが入り、そこから公開された版に悪意あるコードが仕込まれました。同じ手口はcacheable系のパッケージ群やectoにも広がり、flat-cacheやfile-entry-cacheといった、名前を見れば依存関係の奥で見覚えのあるパッケージも含まれていました。コミュニティではChainDropと呼ばれています。

仕組みとしては、パッケージのインストール時に自動で走るpreinstallスクリプトから読み込み役のファイルを起動し、そこから本体を動かすというものです。本体は開発者の端末やCIの環境から、GitHubやnpmのトークン、クラウドの認証情報、環境変数などを集めて外部へ送り出します。さらに、盗んだnpmトークンのうち二要素認証を迂回できる設定のものを見つけると、そのトークンで書き込める別のパッケージにも同じ仕掛けを入れて勝手に新しい版を公開する、という自己増殖の機能まで備えていました。

見落とせないのは、keyvの問題の版が、GitHub Actionsのワークフローから正規の手順で公開され、正しい来歴証明(provenance)まで付いていたという点です。Datadogは、来歴証明は「どこでどう作られたか」を示す証拠であって、安全かどうかの判定ではないと指摘しています。ワークフローそのものが乗っ取られていれば、証明は悪意あるコードの出どころを忠実に記録してしまうわけです。

ステージ公開という考え方

こうした流れを受けて、npmが力を入れているのがステージ公開(staged publishing)です。これは、新しい版をいきなりレジストリに出すのではなく、いったん「公開待ち」の状態に置き、メンテナーが二要素認証を通したうえで承認して初めて公開される、という手順です。

9月3日の更新では、この仕組みまわりに三つの変更が一般提供になりました。一つ目は、トークンを使わずにCIから公開する信頼済み公開(trusted publishing)の設定を、一つのパッケージに複数持てるようになったこと。安定版、プレリリース版、検証用といったワークフローを分けて運用できるようになり、これまでOIDCでまかなえない経路のために長期間有効なトークンを残しておく、といった回避策が要らなくなります。

二つ目は、公開待ちのパッケージはマルウェアの検査が終わるまで承認ボタンが押せなくなったこと。三つ目は、npmjs.comの版一覧で、それぞれの版が承認されたのか、却下されたのか、まだ待ち状態なのかという履歴がメンテナーから見えるようになったことです。

興味深いのは、信頼済み公開の設定は既定で「ステージまで」しかできず、直接の公開は設定ごとに明示的に有効にしないと使えない、という点です。GitHubは設定をステージ専用のままにしておくことを勧めています。ワークフローが乗っ取られても、人の承認がなければレジストリまで届かない。8月の件で破られた部分を、ちょうど塞ぐ形になっています。

トークンにも「ステージまで」の権限ができた

9月18日には、細かく権限を絞れるアクセストークン(granular access token)に、読み書きのうち「ステージのみ」という選択肢が加わりました。このトークンを使う自動化の処理は、npm stage publishで版を公開待ちに出すことはできますが、npm publishで直接公開しようとすると拒否されます。二要素認証の迂回を許可する設定にしていても同じです。

背景には、npmが2027年1月をめどに、二要素認証を迂回するトークンによる直接公開を廃止する予定だという事情があります。信頼済み公開にすぐ移れない現場向けの、移行の足がかりという位置づけです。ただし、ステージ専用トークンも配布タグの付け替えや版の非推奨化といった書き込み権限は残っているため、ほかの書き込み用トークンと同じように慎重に扱うよう注意書きがあります。利用にはnpm CLI 11.15.0以降、Node.js 22.14.0以降が必要とされています。

8月のワームが増殖に使ったのは、まさに二要素認証を迂回できる書き込み用のトークンでした。ステージ専用に切り替わっていれば、盗まれても勝手に新しい版を世に出すことはできません。ここでも、狙われた経路に対してピンポイントで手が打たれているのがわかります。

アカウントを取り戻したあとの猶予期間

9月9日の更新はもう少し地味で、リカバリーコードでサインインしたアカウントに、72時間の保留期間を設けるというものです。これまでは影響の大きいアカウントだけに適用されていた保護が、すべてのnpmアカウントに広がりました。

保留中は、サインインやパッケージの閲覧、インストールはできますが、公開やアクセストークンの作成といった影響の大きい操作が止まります。期間が過ぎれば自動で解除され、問い合わせなどは必要ありません。リカバリーコードが盗まれてアカウントを乗っ取られた場合に、すぐに悪意ある版を出されるのを遅らせるための仕組みです。自分で使った覚えがないのに公開できなくなったら、すぐにnpmのサポートに連絡してほしいとされています。

インストールする側の既定値も変わる

ここまでは公開する側の話でしたが、使う側にも大きな変更が予告されています。6月に発表されたnpm v12の破壊的変更では、npm installの挙動のうち、これまで自動で動いていたものを明示的に許可する方式に切り替えるとされています。

中心になるのは、依存パッケージのpreinstall、install、postinstallといったスクリプトを、既定では実行しなくなるという変更です。ネイティブ拡張のビルドも対象に含まれます。どのパッケージのスクリプトが止まるかはnpm approve-scriptsで一覧でき、信頼するものだけを許可すると、その許可リストがpackage.jsonに書き込まれます。あわせて、Gitリポジトリやhttpsのtarballといった外部の場所から依存を取ってくる動作も、既定では許可しない方向です。これらはnpm 11.16.0以降で警告として先に確認できます。

8月のワームが最初に動き出したきっかけはpreinstallスクリプトでした。インストールしただけで任意のコードが走るという、長年の前提そのものに手が入るわけで、影響は小さくありません。

制作会社の現場で見直しておきたいこと

npmにパッケージを公開していない制作会社でも、使う側としての備えは必要です。まず、案件ごとのリポジトリでnpmのバージョンを上げ、どのパッケージがインストール時にスクリプトを実行しているのかを一度洗い出しておくと、v12への移行で慌てずに済みます。古い案件ほど、ビルドの途中でネイティブ拡張を組み立てるパッケージが紛れていることがあり、許可リストの作成に意外と手間がかかるかもしれません。

次に、CIに置いているトークンの棚卸しです。今回の分析では、盗まれた情報の中心がCIの環境変数や認証情報でした。保守契約で複数のサイトを預かっている場合、デプロイ用の鍵やサーバーの認証情報がCIにまとまって置かれていることも多いはずです。npmのトークンに限らず、権限が広すぎないか、使っていないものが残っていないかを確かめておく価値はあります。

自社でプラグインやライブラリを公開しているなら、信頼済み公開とステージ公開への移行を検討するよい時期です。承認の手間は増えますが、少人数の現場ほど「誰かのアカウントが一つ破られたら終わり」という状態になりやすく、人の目を一段挟む意味は大きいと感じます。

私たちRESONIXでも、テーマやプラグインの開発にnpmを日常的に使っています。便利な仕組みの上に乗っている以上、その仕組みが変わる方向は追いかけておきたいところです。今回の一連の変更は、自動化を減らすのではなく、自動化の最後に人の判断を戻すという整理の仕方で、ほかのツールにも広がっていきそうな考え方だと思います。

WordPressの修正版で見直したい投稿者アカウントの扱い

つくば市のホームページ制作会社

WordPress.orgから、WordPress 7.1.1の公開が案内されました。コアの不具合修正が17件、ブロックエディターの不具合修正が19件、そしてセキュリティ修正が11件含まれた保守・セキュリティリリースです。公式はセキュリティリリースであることから、すぐに更新するよう勧めています。自動バックグラウンド更新が有効なサイトでは、更新は自動的に始まるとされています。

ログインできる人が起点になる修正が多い

今回の修正一覧を眺めて目につくのは、何らかのアカウントでログインしていることが前提になる項目の多さです。たとえば、寄稿者(Contributor)以上の権限で任意の投稿を上書きできてしまう問題、下書きやレビュー待ちの投稿のスラッグが寄稿者から見えてしまう問題、ログインしたユーザーなら誰でもコメント(メモを含む)の親子関係を付け替えられる問題が挙げられています。テンプレートを扱うREST APIでは、認証済みユーザーによるパストラバーサル(本来見えない場所のファイルを指定できてしまう問題)も修正されました。マルチサイト環境で、サイト管理者がネットワーク専用のプラグインをネットワーク全体で有効化できてしまう問題や、XML-RPC経由でCSS編集権限の確認をすり抜けられる問題も含まれています。

一方で、ログインしていない訪問者が関わる項目もあります。本文の段落整形を担う wpautop() に、コメント経由でスクリプトを埋め込めるストアド型XSS(保存された悪意あるスクリプトが表示時に動く問題)があり、コメントが承認されることが条件とされています。ほかにも、カスタムヘッダーに対応した一部テーマでのXSSや、細工したURLによってWordPress.orgにある未有効化のテーマが自動でインストールされ、プレビューされてしまう問題などが並んでいます。

制作の現場から見ると、これは「管理者だけが使うサイト」より「複数人で更新するサイト」で気にしたい内容です。広報担当や外部ライターに寄稿者アカウントを渡している企業サイト、会員登録を受け付けているサイトでは、ログインできる人の範囲がそのまま影響範囲になります。更新を当てるのはもちろんですが、使われていないアカウントが残っていないか、必要以上の権限を渡していないかを、この機会に棚卸ししておくと安心です。コメント欄を開いているサイトなら、承認の運用を誰が担っているかも確認しておきたいところです。

セキュリティ修正は、修正を受け取れる対象の古いブランチ(現在は4.7まで)にも順次バックポートされるとのことです。ただし公式が積極的にサポートしているのは最新版だけだと改めて書かれているので、古い系統に留まっているサイトは、この機会に最新版へ上げる計画も立てておくのがよさそうです。次の大型版となる7.2は12月に予定されています。保守契約で複数サイトを預かっている場合は、自動更新が止められている環境がないかもあわせて見ておくと、取りこぼしを防げます。

修正版が出てから数か月後に狙われた卸売向けプラグイン

つくば市のホームページ制作会社

WooCommerceと組み合わせて使う有料プラグイン「WooCommerce Wholesale Lead Capture」の脆弱性が、実際の攻撃に使われていると報じられました。卸売の取引先を登録フォームで受け付けるためのプラグインで、推定の稼働数はおよそ6,000サイトと大きくはありません。それでも取り上げたいのは、修正版が公開されたのが2月20日で、攻撃が目立ちはじめたのが6月以降だったという時間差のほうです。

更新を後回しにしていたサイトが、修正から何か月もたってから狙われる。WordPressの運用ではよく聞く話ですが、今回はその流れがかなりはっきり数字に出ています。

何が起きていたのか

対象は CVE-2026-27540 として登録された脆弱性で、バージョン2.0.3.1以前が影響を受けます。セキュリティ研究者の Teemu Saarentaus 氏が報告し、2.0.3.2で修正されました。深刻度は、Wordfence の評価で CVSS 9.8、CVE を採番した Patchstack の評価で9.0とされています。

Wordfence が9月14日に公開した技術解説によると、同社のファイアウォールはこの脆弱性を狙った攻撃を10万件以上遮断しました。攻撃が集中したのは6月4日から17日にかけてで、7月1日と8月30日にも山があったそうです。BleepingComputer や Infosecurity Magazine がこの報告を取り上げ、修正から約4か月後に悪用が本格化した点を伝えています。

許可する拡張子を攻撃者が決められた

仕組みを見ると、原因はかなり素朴なところにあります。このプラグインは登録フォームのファイル添付を受け付けるために、ログインしていない訪問者でも呼び出せるAJAXの処理(wwlc_file_upload_handler)を持っています。

この処理はアップロードされたファイルの拡張子を「許可リスト」と照合していましたが、そのリストをサーバー側のフォーム設定からではなく、送られてきたリクエストの中身(file_settings というパラメータ)から読み取っていました。つまり攻撃者が自分で「php も許可」と書き添えれば、PHPファイルがそのまま通ってしまうわけです。さらに、WordPress標準のアップロード関数を呼ぶ際にファイル種別の確認を切っていたため、拡張子のチェックが唯一の関門になっていたとされています。

実際の攻撃では、shell.php のような名前のファイルが送り込まれていました。サーバーの情報を表示し、ブラウザから追加のファイルを書き込めるアップロード画面を持つ、いわゆるWebシェルです。一度置かれてしまうと、そこを足がかりに別の不正なファイルを増やされる可能性があります。

ユーザーから届いた値を「設定」として信用してしまうのは、自作のフォーム処理でも起こりうる落とし穴です。問い合わせフォームや応募フォームでファイル添付を受け付けている案件では、許可する形式がどこで決められているかを一度見直しておくと安心です。

有料プラグインの更新が遅れやすい事情

今回の件でもうひとつ考えたいのが、更新の届き方です。公式ディレクトリで配布される無料プラグインと違い、有料プラグインは配布元のライセンス認証を通じて更新を受け取る形が多く、ライセンスの期限切れや認証の外れで、更新通知そのものが管理画面に出ていないことがあります。制作を請け負ったあと、ライセンスの更新が誰の担当なのか曖昧なまま運用が続いているケースも珍しくありません。

また、Infosecurity Magazine は、ファイアウォールのルールは既知の攻撃を止めてくれるものの、プラグイン自体を直すわけではない点を強調しています。セキュリティ系プラグインを入れているから大丈夫、とは言い切れず、脆弱なバージョンが残っている限り、防御の網をすり抜ける手口が出てくれば危険はそのままです。

使っているサイトで確かめたいこと

このプラグインを導入しているなら、まずバージョンが2.0.3.2以降になっているかを確認します。そのうえで、Wordfence は次のような点検を勧めています。

  • アップロード用のディレクトリに、見覚えのないPHPファイルや最近作られたPHPファイルがないか
  • アクセスログに、admin-ajax.php へ wwlc_file_upload_handler を指定したリクエストが残っていないか
  • 管理者一覧に、心当たりのないアカウントが増えていないか

侵入の形跡が見つかった場合は、不審なファイルやアカウントを消すだけでなく、裏口が残っていないかまで確かめる必要があります。BleepingComputer によると、仕込まれた仕掛けをすべて取り除くのは難しいため、安全な時点のバックアップから復元する対応が推奨されています。なお、ログに該当する記録がないことは、無事の証明にはならないとも添えられています。

導入数の少ないプラグインほど話題になりにくく、気づいたときには修正版の公開から時間がたっている、ということが起こりがちです。管理画面に更新通知が出ていないことを「最新の証拠」と受け取らず、配布元の更新履歴と見比べる習慣が、こうした時間差の攻撃に対するいちばん確実な備えになりそうです。

プラグイン作者にも届きはじめた欧州の報告義務

つくば市のホームページ制作会社

欧州連合のサイバーレジリエンス法(Cyber Resilience Act、以下CRA)のうち、報告に関する部分が2026年9月11日から動き出した。欧州委員会の説明によると、この日以降、デジタル要素を含む製品のメーカーは、攻撃に悪用されている脆弱性と、製品の安全性に影響する重大なインシデントを当局へ届け出る義務を負う。法律全体の適用開始は2027年12月とされているので、報告の部分だけが先に立ち上がった形になる。

欧州の規制と聞くと遠い話に思えるが、WordPressのプラグインやテーマを世に出している作り手には、まったくの他人事とも言い切れない。脆弱性の調整を手がけるPatchstackは、この条文が公開ソフトの作り手にどう関わるかを、WordPressを例に取り上げている。

届け出るものと、その締め切り

報告が必要になるのは二種類ある。実際に悪用が確認されている脆弱性と、製品の安全性に影響する重大なインシデントである。締め切りは短い。認識してから24時間以内に早期警告を出し、72時間以内に概要と初期評価を含む通知を提出する。最終報告は、悪用中の脆弱性であれば修正措置が利用できるようになってから14日以内、重大インシデントであれば72時間通知から1か月以内とされている。あわせて、影響を受ける利用者に何が起きたかと身の守り方を伝えることも求められる。

提出先は一本化されていて、欧州のサイバーセキュリティ機関であるENISAが運用するSingle Reporting Platform(単一報告窓口、SRP)に集約される。メーカーは一度出せばよく、主たる拠点のある国のセキュリティ対応組織、いわゆるCSIRTに届き、原則としてENISAにも同時に共有される。最初に受け取ったCSIRTは、その製品が流通している他国のCSIRTへ遅滞なく共有する仕組みになっている。

公開物か、商用製品かの線引き

ここで気になるのが、誰が義務の当事者になるのかという点である。欧州委員会のページでは、オープンソースソフトウェアのスチュワードに対する報告義務は第24条3項に基づくもので、適用は2027年12月11日からと明記されている。一方でPatchstackは、GPLで公開されていても有料版など収益を得る手段があるプラグインの販売者は、スチュワードではなくメーカーに当たるという整理を示している。営利の意図がまったくない公開プラグインを法人の従業員が保守している場合はスチュワードに当たる、という例も添えられている。同社によれば、スチュワードには制裁金は科されないが、非準拠の製品を欧州市場から取り除くための手段は残るという。

オープンソースであることと無償であることが一致しないWordPressの世界では、この線引きは意外と身近に響く。人気のあるプラグインの多くは、公開されていながら商用の意図を持った製品でもあるからだ。同社は、WordPress周辺で知られている脆弱性の半分以上を自社が調整してきたとしており、影響範囲の広さがうかがえる。

窓口の使い勝手という現実的な話

制度の中身以上に現場に効きそうなのが、窓口の操作である。PatchstackはSRPにAPIがなく、報告1件につき3つのフォームを手作業で埋める必要があると指摘している。提出にはEU Loginの個人アカウントと多要素認証が必要で、アカウントは個人に紐づく。24時間という締め切りを考えると、事が起きてから登録を始めるのでは間に合わない恐れがある。同社は、アカウントだけでも先に用意しておくことを勧めている。

その負担を引き受ける動きも出ている。Patchstackは9月11日付で、公開ソフトの保守担当者向けに、指定代理人として報告を代行する仕組みを無料で使える形で提供し始めたと発表した。報告件数が増え、SRPにAPIが用意されないままであれば、1件あたりの課金を将来的に導入する可能性があるとも書き添えられている。

受託制作の側から見ると

日本で中小企業のサイトを作っている立場なら、自分が報告義務の当事者になる場面はそう多くないだろう。ただ、納品したサイトに組み込んだ有料プラグインの作者が欧州市場に製品を出しているなら、悪用が確認された脆弱性の情報が、これまでより早く表に出てくる可能性はある。

更新の判断材料が増えること自体は、受け取る側には悪い話ではない。ただ、公表が早くなるということは、修正版が出てから適用するまでの猶予が短くなるということでもある。どのサイトにどのプラグインが入っていて、誰が更新を見ているのかを手元で把握しておく。規制そのものは欧州の話でも、そこを通って流れてくる情報の速さは、地方の小さな制作現場にも同じように届く。