バックアップを戻すときに動き出す脆弱性

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

サイトの引っ越しやバックアップで広く使われているプラグイン、All-in-One WP Migration and Backup に深刻な脆弱性が見つかり、開発元の ServMask がバージョン 7.110 で修正した。識別番号は CVE-2026-19949、影響を受けるのは 7.109 までのバージョンで、深刻度の指標は 8.8 とされている。有効インストール数が 500 万件を超える定番だけに、預かっているサイトのどれかに入っている、という制作者は少なくないはずだ。

見つけたのはセキュリティ研究者の Jack Taylor 氏で、Wordfence を通じて 8 月半ばに開発元へ伝えられ、8 月 20 日に修正版が公開された。報じられている Wordfence の説明によると、原因はアーカイブを復元する際にデータベースの中身を書き換える処理にあり、エスケープされたバックスラッシュや引用符の解釈が正しくなかったという。

仕込みと発動がずれているところが厄介

この脆弱性が少し変わっているのは、攻撃が二段構えになっている点だ。ログインしていない第三者でも、トラックバックを使って細工したデータを投稿に紐づけて置いておける。置かれた時点では何も起きない。管理者がサイトを書き出し、別の環境に取り込んだその瞬間に、保存されていた文字列が SQL として動き出す。

その結果、プラグインが内部で使う取り込み用の秘密キーが公開コメントとして表に出てしまう可能性がある。キーを手に入れた側は、実行可能なコードを含んだ .wpress ファイルを取り込ませることができ、最終的にサイトを掌握される恐れがあると説明されている。バックアップと復元はこのプラグイン本来の用途そのものなので、いつかは引かれる引き金だと考えておいたほうがいい。

BleepingComputer の集計では、修正版が出てしばらく経った時点でも更新を済ませたのは利用者のおよそ 3 割で、残る 325 万件ほどが古いまま動いていた。バックアップ系のプラグインは普段の運用で触らないぶん、入れたまま忘れられやすい。停止していれば危険度は下がるものの、一時的に有効化すれば同じ経路が開くとも指摘されている。移行の予定がなくても、管理画面を開いてバージョンを確かめる価値はある。自動更新を切っている運用では、ここが抜けたままになりやすい。

実務でもうひとつ気をつけたいのが、手元に残っている古いアーカイブの扱いだ。細工されたデータは投稿に紐づく形でデータベースに入るため、すでに書き出した .wpress の中に紛れ込んでいる可能性がある。修正版に上げてから取り込めば処理する側は安全になるが、まずテスト環境に流して様子を見るくらいの慎重さはあってよいと思う。複数のサイトを預かっている制作会社であれば、このプラグインが入っている案件を洗い出すところから始めるのが早い。移行や復旧のために入れて、そのまま残っているケースも案外あるはずだ。

サーバー証明書の寿命が段階的に短くなる

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

証明書の更新は、自動で回っていれば存在すら忘れている作業だ。だが期限を管理表に書いて、年に一度手で入れ替えている現場もまだ珍しくない。その前提が、これから数年かけて成り立たなくなる。

Let’s Encryptが公開している証明書プロファイルの解説ページが9月8日付で更新され、いま選べる発行方式と、それぞれの有効期間や制約が改めて整理された。同じページには業界共通の上限値も書かれている。公開されているTLS証明書の有効期間は現在200日が上限で、2027年3月15日以降に発行するものは100日、2029年3月15日以降は47日までしか持てない。

上限が下がる日程はすでに決まっている

この段取りを決めたのは、認証局とブラウザベンダーが参加するCA/Browser Forumで2025年4月に可決された議案である。告知によると、公開TLS証明書の最大有効期間を398日から47日へ、2026年3月から2029年3月にかけて段階的に引き下げる内容になっている。認証局側は30票のうち25社が賛成で反対はゼロ、ブラウザ側はApple、Google、Microsoft、Mozillaの4社すべてが賛成した。特定の一社の方針ではなく、証明書を発行する側と検証する側の双方が合意した既定路線ということになる。

縮むのは証明書の寿命だけではない。ドメインの管理権を確認した結果を使い回せる期間、いわゆる認可情報の再利用期間も同時に短くなる。こちらは現在200日で、2027年3月15日以降は100日、2029年3月15日以降は10日になる。寿命が縮むだけなら更新の回数が増えて終わりだが、確認結果まで使い回せなくなると、ドメイン確認の手続きそのものを何度も走らせることになる。運用への影響は、むしろこちらのほうが重い。

短くする理由は失効の仕組みが当てにならないから

議案の背景説明は、なぜ寿命を削るのかをかなり丁寧に書いている。要点は、証明書が発行時点の事実を写し取ったものにすぎない、という指摘だ。時間が経つほど、証明書に書かれた内容と実際の状況はずれていく。ドメインが手放された、鍵が第三者の手に渡ったといった変化が起きても、証明書のほうは期限まで有効なままになる。

本来そのずれを埋めるのが失効の仕組みだが、これが十分に働いていないという評価が示されている。失効情報を配る仕組みは、閲覧者の側が第三者のサーバーへ問い合わせを出す必要があり、応答が遅れたり届かなかったりする。外部の読み込みが多いページでは表示速度にも響く。失効させるべき証明書が期待どおりに失効されない例もあると書かれている。それに対して有効期限そのものは、閲覧側が確実に守る。だから期限を短くするほうが、失効の通知に頼るより確実だという整理になっている。

もう一つ挙げられているのが、暗号方式の入れ替えを速く進められることだ。使っているアルゴリズムや実装に弱点が見つかったとき、寿命の短い証明書のほうが世代交代は早く片づく。ここも個々のサイトの都合というより、仕組み全体をどう保つかという話として書かれている。

用意された三つの発行方式

Let’s Encryptが2015年の開始時から90日という期間を選んできたのは、自動化を促すには十分に短く、それでいて手作業でも回せる程度には長い、という判断からだったと自ら説明している。当時は自動化の道具立てがまだ若かった。いまは事情が違うので、90日より短い選択肢を出すことにも抵抗がなくなった、という理由づけになっている。

現在の既定はこれまでどおりのclassicで、有効期間は90日、認可情報の再利用は30日、証明書に載せられる名前は100件までとされている。新しく用意されたtlsserverは、有効期間が45日、認可情報の再利用が7時間まで詰められている。再利用が7時間なのは、認証局が8時間ごとにCAAの再確認を求められているためで、再利用期間をその手前で切っておけば再確認の手間が要らなくなる、という理屈が説明されている。証明書の中身も整理されていて、別欄と重複するコモンネーム、いまのブラウザでは使われない鍵用途の指定、末端の証明書では意味を持たない鍵識別子の拡張が省かれている。ファイルとしては小さくなる方向だ。

三つめのshortlivedは、有効期間が160時間、つまり6日あまりしかない。ここまで短いと失効情報を載せる必要がないという扱いになり、証明書はさらに小さくなる。IPアドレスに対する証明書もこの方式でのみ発行される。IPアドレスはドメインより移り変わりが早いので、確認の頻度を上げたいという判断だそうだ。ただしtlsserverもshortlivedも、載せられる名前は25件までに絞られている。サブドメインを多数まとめて一枚に収めている構成では、ここで引っかかる可能性がある。

既定の九十日が切り替わる日も告知済み

切り替えの日程も先に出ている。2026年5月13日にtlsserverが45日発行へ移り、2027年2月10日には既定のclassicが64日発行、認可情報の再利用10日へ変わる。さらに2028年2月16日にclassicも45日、再利用7時間になる予定だ。いずれも新規発行分から適用されるので、実際に短い証明書を受け取るのはその日以降の最初の更新時ということになる。

つまり、何も設定を変えていないサイトでも、2027年2月を境に証明書は90日から64日へ、2028年にはさらに45日へと自動的に短くなる。利用者側に特別な作業を求めるものではないと書かれてはいるが、更新の周期を前提にした仕掛けを持っているなら、そこは確実に影響を受ける。なお、TLSクライアント認証の用途を含んでいた発行方式は2026年7月8日で提供を終えている。使っていた環境があれば、すでに切り替えが済んでいるはずの部分だ。

更新間隔を決め打ちした設定を見直す

実務として一番効いてくるのは、更新のタイミングをどう決めているかだ。告知では、たとえば60日という固定の間隔で更新している設定は、45日の証明書に対しては成り立たなくなると名指しで書かれている。妥当な動きとして挙げられているのは、有効期間のおよそ三分の二を過ぎたあたりで更新する、という決め方だ。

推奨されているのはARIと呼ばれる仕組みで、いつ更新すべきかを認証局の側から受け取れる。対応しているかどうかも、有効にする方法も、使っているクライアントによって違うとされている。中小規模のサイトでは、証明書の取得をレンタルサーバーの管理画面やホスティング事業者側の仕組みに任せていることが多い。その場合に確かめておきたいのは、事業者がこの仕組みに対応しているか、していないなら更新の間隔がどう設定されているか、という点になる。

もう一つ、期限切れに気づける経路があるかどうかも書かれている。更新が想定どおりに走らなかったときに、知らせが飛ぶ状態になっているか。更新の回数が年に4回から8回、さらにその先へと増えていけば、たまたま失敗した一回が期限切れに直結する確率も上がる。気づいてから手で直せる猶予は、着実に短くなっていく。

手作業の余地が消えていく

手動での更新は推奨しない、と告知にははっきり書かれている。寿命が短くなるほど手作業の回数が増えるからだ。とはいえ、自動化を阻んでいるのは面倒くささだけではない。ドメインの管理権を確認する方法はどれも、クライアントが実際の設備へ触れる必要がある。所定のファイルを置く、TLSの応答を返す、DNSのレコードを書き換える。いずれも権限を渡すことになるので、そこを避けたくて手作業を続けている現場は少なくないはずだ。

この点については、DNS-PERSIST-01という新しい確認方式の標準化が進んでいることが告知されている。更新のたびにDNSのTXTレコードを書き換える必要がなく、一度置けばそのまま使い続けられるのが特徴だ。DNSを自動で書き換える手段を持たない環境でも自動更新に乗れるようになるとされていて、2026年中の提供が見込まれている。DNSの操作権限を外部に渡さずに済むなら、運用を分担している案件でも取り回しは楽になる。

証明書の期限が近いという連絡を年に一度受け取って、手で入れ替える。その段取りは、あと数年で現実的でなくなる。すでに自動更新が回っているサイトなら、確かめるべきは更新の判断基準と、失敗したときに気づける経路の二つで足りる。まだ手で回している環境が残っているなら、上限が200日ある今のうちが、移行を考える時間としては一番余裕がある。

カメラとマイクの許可を求める専用タグが増える

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

ブラウザがカメラやマイクの利用を尋ねてくる、あの小さなダイアログ。長らくJavaScript側の都合で表示されるものでした。ページを開いた瞬間に出てしまったり、一度「許可しない」を押すと二度と出てこなくなったりと、扱いにくさは制作の現場なら心当たりがあると思います。Chromeはこの役目をHTMLの要素そのものに移す作業を進めていて、8月下旬に公開された次期版のベータ告知に、映像専用の camera と音声専用の microphone というタグが並びました。

この一連の取り組みはCapability Elementsと呼ばれていて、先に位置情報を扱う要素が入り、続いてカメラとマイクをまとめて扱う usermedia が少し前の版で使えるようになっています。書き方はタグを置いて中にボタンを入れるだけ。解像度やエコーキャンセルといった希望は、利用者が触る前に専用のメソッドで伝えておきます。ストリームが取れたらイベントが飛んでくるので、成功と失敗のコールバックを自分で組み立てる手間がほとんどありません。ブラウザが単なる許可の門番ではなく、同意の取得からストリームの受け渡しまでを仲介する役に回った、という整理です。今回追加される2つは、映像だけ、音声だけを求める場面に絞った軽い版という位置づけになります。

断られたあとに戻れる道をつくる

この作りが効いてくるのは、実は最初の許可よりも、断られたあとの立て直しの場面です。試験導入の段階で集まった数字が公開されていて、一度拒否した利用者が改めて許可にたどり着ける割合は、従来のダイアログでは10%程度だったものが、新しい要素では65%を超えたという報告があります。別の事業者では取得エラーが約47%減り、また別のサービスでは「マイクが動かない」という声が17%減ったとされています。ブラウザ側の部品を押したという確かな合図があるぶん、自動的な抑制に引っかからず、設定画面の奥まで潜らなくても復帰できる導線が用意されるためです。

その代わり、見た目の自由度はかなり絞られています。文字と背景のコントラストは一定以上が求められ、透明度を下げて見えにくくすることもできません。幅や高さ、文字サイズには上限と下限があり、負のマージンで覆い隠すのも不可、変形は平行移動と縦横比を保った拡大縮小までです。利用者をだます置き方を封じるための線引きで、ブラウザが責任を持つ部品である以上は妥当な制約だと感じます。状態に応じた装飾は用意されていて、許可が下りてストリームが流れている状態を擬似クラスで拾えます。

未対応のブラウザでは、このタグは未知の要素として扱われ、中身がそのまま表示されます。つまり中に従来どおりのボタンを置いておけば、対応していない環境では既存の呼び出しに落とす、という書き分けができます。オンラインの相談窓口や、申し込みフォームで書類を撮って送ってもらう画面など、中小企業のサイトでもカメラを使う場面は少しずつ増えました。今のところChromeが先行して進めている段階ですが、権限まわりの面倒がスクリプトからブラウザ側へ寄っていく流れは、頭の片隅に置いておくと後々効いてきそうです。

拡張機能の旧仕様がストアから完全に消えた

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

ブラウザの拡張機能は、制作の現場で地味に効いてくる道具です。見出し構造の確認、色のコントラスト比の測定、通信内容の観察、テスト用のデータ差し替え。どれも本体の開発者ツールでできることではありますが、ワンクリックで呼び出せる拡張をいくつか常駐させている人は多いはずです。

その拡張機能の古い土台が、2026年8月31日にChromeウェブストアから完全に取り下げられました。長く予告されてきた移行の、最後の一段です。同じ週にはChrome 152の安定版で、別の系統の機能もひとつ静かに削除されています。予告された終わりが実際に来たとき、現場には何が残るのか。今回はそのあたりを整理してみます。

動かなくなった時期と、消えた時期は別

まず順番を整理しておくと、8月31日に起きたのは「急に動かなくなった」ではありません。Chromeの拡張機能の旧仕様は、2025年7月24日のChrome 138の時点で、すべての利用者、すべての配布チャンネルで無効化が完了しています。利用者が設定から手動で戻すこともできなくなりました。企業向けにはポリシーによる猶予が残っていましたが、それもChrome 139で撤去され、そのバージョンに上がった環境では一斉に効かなくなっています。

今回のできごとは、その先の段階です。ストアに残っていた旧仕様の拡張の掲載そのものが消え、更新の配信も、ストアからの再インストールもできなくなりました。Chromeの公式ドキュメントによると、Chrome 138以前で止めてある環境に入っているものはインストール済みの状態で残るものの、そこへ更新が届くことはないとされています。動作の停止が一年以上前、掲載の消滅が今回という、二段構えの終わり方になりました。

この二段構えは、利用者から見ると分かりにくい部分でもあります。無効化が進んだ時期には、拡張の管理画面に警告が出て、止まった拡張の代わりになるものがストアで案内される流れが用意されていました。案内する先そのものが今回なくなったので、これから同じ状況に出会った人は、自力で代替を探すことになります。制作側が顧客の環境を触るときには、この差を頭に入れておいたほうが説明しやすいはずです。

四年半かけて刻まれてきた予告

この移行は、ある朝いきなり通告されたものではありませんでした。公開されている支援終了の年表をたどると、ストアが新規の公開および限定公開の拡張の受け付けを止めたのが2022年1月、非公開の拡張についても止めたのが同年6月です。そこから二年ほど間があき、2024年6月に先行チャンネルで警告バナーの表示が始まり、旧仕様のまま残っていた注目枠のバッジが外されました。

2024年10月には安定版でも無効化が始まり、2025年3月末には既定で無効、ただし利用者が戻せる状態になります。同年7月にその戻す余地もなくなり、そして今回の掲載削除です。足かけ四年半、告知から実行までの期間としてはかなり長いほうだと思います。それでも最後の日には「もう入れ直せない」という形で影響が出るところが、この種の予告の難しいところです。

移行の途中で埋められていった機能の差

移行が長引いた理由のひとつは、新しい仕様で従来と同じことができるのか、という点が最初から解決していたわけではなかったからです。移行開始時の告知によると、この期間にユーザースクリプトの仕組みや、背景処理からDOMを扱うための画面外ドキュメントが追加され、通信の絞り込みに使うルールの上限も、あらかじめ同梱できる分が33万件、動的に足せる分がさらに3万件まで引き上げられています。

あわせて、ルール一覧の安全な更新であれば審査を数分で通す仕組みや、配信した版を巻き戻す機能も用意されました。同じ告知の時点で、活発に保守されている拡張の85%以上が新仕様に移っており、広く使われている通信の絞り込み系の拡張にも新仕様版が用意されていたと説明されています。外部の仕様変更に自分たちの実装を合わせていくとき、何が足りないかを出し合いながら進んだ例として読める部分があります。

移行を進めた側の説明では、新しい仕様の狙いは既存の機能を守りながら、安全性やプライバシー、動作の軽さ、そして信頼性を全体として底上げすることに置かれていました。実装者からの意見を受けて仕様を足していった、という経緯も添えられています。仕様の側が動かないまま期限だけが迫る形にはならなかったので、四年半という長さは、待たされた時間というより、埋め合わせに使われた時間と見るほうが実態に近そうです。

同じ週にもうひとつ外されたもの

8月25日に安定版となったChrome 152のリリースノートには、削除の項目がひとつだけ載っています。三者間のCookieについて現行の方針を維持するという発表を受けて、集計系のAPIが関連する一連の仕組みとあわせて廃止された、という内容です。長く議論されてきた計測手法の置き換えが、静かに畳まれた形になります。

多くの中小企業サイトでは、これに直接ぶつかることはないはずです。ただ、広告や効果測定のタグを入れたまま担当者が代わっている、というサイトは珍しくありません。自社で計測まわりの実装を抱えている場合は、リリースノートのこの行が自分たちに関係するかどうか、一度だけ確かめておくと安心だと思います。

手元の道具立てをどう見直すか

制作会社の側で今回の件が効いてくるのは、検証の手順に拡張機能を組み込んでいる場合です。旧仕様の拡張はもう入手できないので、検証用の端末を作り直したときに同じ環境を再現できません。手順書に拡張の名前が書いてあるなら、それが今も入手できるものかどうかを確かめて、置き換えるか、本体の開発者ツールでの手順に書き直しておくのが現実的です。

もうひとつ、古いChromeのまま固定してある検証端末に旧仕様の拡張が残っている場合は、そこに更新が届かない点を意識しておきたいところです。拡張は閲覧中のページの内容に触れる立場にあるので、直らないまま置いておく前提の道具としては扱いにくくなります。日常的に使う端末と、意図的に古い環境を保つ端末は、分けておくほうが落ち着きます。

顧客の環境について聞かれたときの答え方も、少し整理しておくとよさそうです。古い拡張が動かないという相談は、ブラウザ側の不具合ではなく、予定どおりの廃止によるものです。代わりのものを探すか、その作業を本体の機能で置き換えるか、という話に切り替えるだけで済みます。原因が分かっている変更は、伝え方さえ決めておけば手間の少ない部類に入ります。

予告を受け取る置き場所を決めておく

こうした変更を追いかけるコツは、情報を広く集めることよりも、見に行く場所を決めておくことにあります。ブラウザの各版のリリースノートには、追加された機能と並んで廃止と削除の項目が置かれています。拡張機能まわりの変更点も専用のページにまとまっていて、たとえばChrome 153では、URLの公開接尾辞を問い合わせるAPIの追加や、拡張のアイコンを既定でツールバーに固定する実験が告知されています。追加も削除も、同じ場所に同じ調子で並びます。

削除には猶予が用意されることもあります。Chrome 152では、ブラウザ側で行う変換処理の廃止に向けて、移行期間を確保するための試験参加の枠が始まりました。廃止の予告と、猶予の受け取り方が同じページに書かれているので、月に一度そこを開く習慣さえあれば、慌てる場面はかなり減ります。年表の最後の一行が自分の手元に届く前に気づけるかどうかは、結局のところ見に行く回数で決まります。

プラグインのファイルは変わらないまま管理画面が狙われた

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

WordPressのプラグインは、更新のたびに配布元のファイルが差し替わる。だから「更新していないなら中身は変わっていないはず」と考えるのは自然で、実際その通りであることがほとんどだ。ところが今月、その前提の外側から入られた事例が報告された。プラグインのファイルは一行も書き換わっていないのに、管理画面を開いた管理者のブラウザで攻撃用のコードが動いていた、という話である。

対象になったのはBdThemesというElementor向けアドオンの開発元で、Element PackやPrime Slider、Ultimate Post Kitなど七つの製品が影響を受けた。WordPress.orgの公式ディレクトリでは、調査のあいだこれらの配布が一時停止されている。

更新していないサイトで何が起きていたか

報告によると、これらのプラグインにはBiggoptiという内部の部品が入っていて、開発元のサーバーから宣伝用のバナー情報をJSONで取得し、WordPressの管理画面に表示していた。攻撃者はそのJSONが置かれていたDigitalOcean Spacesのバケットに書き込める状態を手に入れ、正規のバナーデータを細工したものに差し替えた。

プラグイン本体は公式ディレクトリに置かれたまま、一文字も変わっていない。変わったのは、プラグインが管理画面を開くたびに取りに行く先の中身だけだ。セキュリティ企業のWordfenceがファイアウォール側でこの攻撃を検知したのが8月7日、公式ディレクトリでの配布停止が8月8日。汚染されたデータに残っていた日付をたどると、6月下旬には動き始めていた可能性があるとされている。

囲い忘れた一箇所が入口になった

差し替えられたデータが、それだけで害になるわけではない。効いてしまったのは、受け取った値の扱いに抜けがあったからだ。BiggoptiはJSONに含まれるdisplay_idという値を、エスケープしないままHTMLのid属性に埋め込んでいた。つまり外から届いた文字列が、そのままHTMLの一部として書き出される状態になっていた。

これはクロスサイトスクリプティング、いわゆるXSSの典型で、危険度はCVSSで5.4、中程度と評価されている。単体の欠陥としては目を引く数字ではない。ただ、値の供給元が攻撃者の手に渡った時点で、その中程度の欠陥が管理者のブラウザで任意のコードを走らせる経路に変わった。

調査で指摘されているのは、すぐ隣にある別の属性はきちんとエスケープされていた、という点だ。意図的な仕込みではなく、3月に入った変更のときの見落としとみられている。5月に追加された無害化の処理も、この属性までは届いていなかった。

ログイン中の管理者の権限がそのまま使われる

埋め込まれたコードは、アニメーションの開始をきっかけにするイベントハンドラを使い、管理画面が描画された直後に動く。そこから外部のサーバーへ追加のスクリプトを取りに行き、開いている管理者のセッションとnonceを借りる形で、REST API経由で新しい管理者アカウントを作る。

続いて、無害そうな名前の偽プラグインを追加し、その中にウェブシェルを置く。さらにMust-Useプラグインの領域へ居座り用の部品を仕込み、特定のURLパラメータを付けるだけでログインなしに管理者として入れる裏口を用意していた。もうひとつの部品はデータベースへの問い合わせに介入し、作成された管理者アカウントを利用者一覧から隠したうえ、人数の表示までつじつまを合わせていたという。

作られるアカウントの名前や連絡先は、サイトのホスト名から機械的に導ける形になっていた。攻撃する側は被害サイトの一覧を持ち歩かなくても、あとから同じ資格情報を計算し直せる。裏を返せば、調べる側にとっては何を探せばよいかがはっきりしているということでもある。

手元のサイトで確かめられること

この件が厄介なのは、ファイルの比較やプラグインのバージョン確認では手がかりが出てこないところだ。見るべきなのは結果として残ったもののほうで、具体的には管理者アカウントの一覧、プラグインディレクトリとMust-Useプラグインの中身、そしてオプションを保存しているテーブルになる。心当たりのない管理者が増えていないかは、専用のツールがなくても管理画面から確認できる。

より広く見れば、管理画面に外部から取ってきた内容を表示する部品は珍しくない。宣伝バナー、開発元からのお知らせ、キャンペーンの案内など、有償版の販売を持つ製品ほど組み込まれている。今回はその仕組みそのものが悪いというより、外から届いた値を自分のHTMLに置くときの手当てが一箇所抜けていたことが決め手になった。作る側の視点では、遠くから来た文字列は例外なく汚れているものとして扱う、という基本の話に戻る。

制作を請け負う立場だと、納品後のサイトは触る機会が減り、更新の通知が出ていなければ問題なしと見なしがちだ。今回のように配布物が無傷のまま影響が出る攻撃があると分かった以上、管理者の一覧をときどき眺めるくらいの軽い確認は、手間の割に効き目がありそうに思える。

プラグインを配る側に求められる脆弱性報告の手順

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

プラグインやテーマは「使うもの」で、「作って配るもの」ではない。制作の現場ではそういう感覚が普通かもしれません。ただ、案件ごとに小さな自作プラグインを納品したり、テーマを配ったりしている会社は少なくないはずです。欧州連合で動き始めた新しい規則は、そうした立場の人にも関わってきます。

Cyber Resilience Act(サイバーレジリエンス法、CRA)という規則です。欧州委員会の説明によると、2024年12月10日に発効し、主な義務は2027年12月11日から適用されます。そして脆弱性などの報告義務については、それより早い2026年9月11日から適用が始まります。先に動き出すのは報告の部分だ、という順番になっています。

先に始まるのは報告のほう

CRAは、ネットワークにつながるハードウェアとソフトウェア全般を対象に、計画・設計・開発・保守の各段階で安全性を確保することを製造者に求める規則です。欧州委員会は、製品を出したら終わりではなく、製品の寿命が続くあいだ脆弱性を扱い続けることも要件に含まれると説明しています。要件を満たした製品にはCEマークが付き、各国の市場監視当局が運用を見ます。

先行して適用される報告義務は、悪用が確認されている脆弱性や重大なインシデントを、決められた期限内に当局へ知らせるというものです。欧州委員会は2026年7月27日に、規模を問わず事業者が義務を果たせるようにするための実務的な手引きを公開しています。読む側にとっては、9月の適用開始前に手順を確かめておくための材料ということになります。

WordPressの世界ではだれが対象になるのか

WordPressサイトの保守サービスを手がけるWP Umbrellaの解説によると、プラグイン作者はCRAの文脈では製造者にあたります。有料版がある、データを扱っている、会社として保守している。そうした商業的な意図があれば、無料で配っていても対象になり得るという整理です。オープンソースだから関係ない、とは言い切れないわけです。

同じ解説は、コードを書かない制作会社も無関係ではないとしています。第三者のプラグインを選んで納品する立場は流通側にあたり、使っている部品の一覧(SBOM、ソフトウェア部品表)がどこにあるか、セキュリティ更新がどう配られているかを把握しておくことが期待されます。EU向けの案件に自作モジュールを納めていれば、それは自社が作った製品という扱いです。

もっとも、WordPressの構造には難しさもあります。WordPress.orgから配布したプラグインの場合、作者は誰が使っているかを知りません。それでも利用者への通知が求められる、という食い違いが残っている。この点は個々の作者が解決できる話ではなく、配布側の仕組みが変わっていく必要がある、というのが同解説の見立てです。

技術的な中身はまだ標準づくりの途中

Help Net Securityが2026年8月14日に伝えたところでは、CRAの技術的な詳細を埋める17本の標準の草案が、いま意見募集にかけられています。法律は「何を達成すべきか」を定めるだけで「どうやるか」までは書かないため、標準化団体がその部分を担う。CRAを担当する部会の議長は、そうした役割分担だと述べています。

示された草案に沿って作れば適合しているとみなされる仕組みで、今回の対象はパスワード管理ソフトやウイルス対策ソフト、スマートホーム機器、つながる玩具など、リスクが高いとされる区分です。意見を出せるのは欧州経済領域の標準化機関を含む41の加盟組織と、消費者や中小企業の立場を代表する四つの団体で、締め切りは分野ごとに9月半ばから11月半ばの間に置かれています。文言がまだ動くうちに意見が入る、という段取りです。

制作の現場で先にできること

日本の制作会社が明日から欧州の当局に何かを届け出る、という話ではありません。ただ、CRAが求めている作業の中身は、EU向けかどうかに関係なく手元の運用を整えるものでもあります。変更履歴を残す。更新にセキュリティ修正が含まれるときはそれとわかるように書く。脆弱性の連絡先をひとつ決めて公開しておく。可能なら機能追加とセキュリティ修正を分けて出す。WP Umbrellaの解説が挙げているのは、そうした地味な項目です。

保守を請け負っている場合は、どのサイトにどのプラグインが入っていて、いつ更新したかを追える状態にしておくことが効いてきます。何年も更新の止まったプラグインを使い続けている案件があれば、そこは規則以前の問題として見直しどころです。欧州の規則という遠い話に見えて、点検の項目自体は、いま抱えている保守案件にそのまま当てはまります。

外向きの通信先をサイト側で絞れる仕組みがChromeに

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

ページの中から外へ出ていく通信の宛先を、サイト側があらかじめ決めておく。そんな仕組みがChromeのベータ版に入った。Connection Allowlistsと呼ばれる機能で、少し前の版からオリジントライアルとして試験提供されていたものが、次の安定版で正式に出荷される段階へ進んだ。出荷予告によれば、デスクトップとAndroid、WebViewを対象に、利用者側で特別な設定をしなくても有効になるとされている。

使い方はHTTPのレスポンスヘッダー1本だ。Connection-Allowlist というヘッダーに、通信を許可するURLのパターンを並べて返す。ブラウザは接続を張る前に宛先を照らし合わせ、リストに載っていない相手には接続しない。自分自身のオリジンを含めたいときは response-origin という書き方が用意されている。対象になるのはfetchによるサブリソース取得だけでなく、画面遷移やリダイレクト、prefetchやpreconnectといった先読み系の指定、さらにWebSocketやWebTransport、WebRTCまで広い。文書だけでなく、Worker類にも適用できるとされている。

考え方としてはコンテンツセキュリティポリシー(CSP)の connect-src に近いが、CSPが読み込み元を用途ごとに細かく書き分けるのに対して、こちらは許可する宛先の一覧を一箇所にまとめ、接続を確立する手前でまとめて判定する。狙いとしてわかりやすいのは、外部から読み込んでいるスクリプトが何らかの理由で書き換えられ、フォームに入力された内容を見知らぬ宛先へ送り出してしまうような事故だろう。そうした通信を、ブラウザ自身が門番となって止める位置づけになる。

いきなり遮断せずに様子を見られる

現場的にありがたいのは、記録だけを取るモードが最初から用意されている点だ。Connection-Allowlist-Report-Only というヘッダーを使うと、実際の通信は止めないまま、リストから外れた宛先をReporting API経由で受け取れる。開発者ツール側の対応も入っているとされ、稼働中のサイトにいきなり適用して決済や地図が動かなくなる、という事態を避けながら、自分のサイトがどこへ通信しているのかを棚卸しできる。

一方で、現時点で実装を表明しているのはChromiumの系列だけだ。Firefoxはヘッダーの書式をめぐって意見の相違があり議論中、Safariは公式な立場をまだ示していないとされている。守りをこれ一本に預けるのではなく、これまで通りCSPを整えたうえで、対応するブラウザでは壁がもう一枚立つ、と考えるのが現実的だろう。中小企業のサイトでも、アクセス解析のタグ、チャットの窓口、フォーム、外部サービスの埋め込みと、気づけば通信先は増えていく。まずはレポート専用のモードで一度眺めてみると、思っていたより多くの宛先が並ぶかもしれない。

ログイン画面の不備を含むWordPressの臨時セキュリティ更新

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

WordPress本体のセキュリティ更新が公開されました。8月6日に出た臨時リリースで、修正された不具合は12件です。機能追加を伴わない、修正だけを目的とした更新になります。

この種の更新は定期的に出てきますが、今回は未ログインの状態から届く経路が含まれていた点で、優先度が一段高いものになっています。管理画面に入れる人だけが対象、という前提が成り立たない種類の不具合だからです。

ログイン画面から届く経路がふさがれた

今回いちばん重く扱われているのは、ログイン画面で見つかった反射型のクロスサイトスクリプティングです。CVE-2026-64638として登録され、深刻度は9に近い数値がつきました。公式のリリース情報によると、条件がそろうとPHPのコード実行につながる可能性があるとされています。

反射型というのは、送り込まれた内容がそのまま画面に跳ね返って動いてしまう型のことです。データベースに残らないぶん痕跡が追いにくく、あとから気づきにくい種類でもあります。今回変更されたファイルにはログイン画面の本体や出力の無害化を担う処理が含まれており、画面に出す直前のエスケープを補う形の修正が中心になっています。特殊な仕組みを足したわけではなく、基本の処理の抜けを埋めた、という内容です。

ただし、放っておけば勝手に乗っ取られるという話ではありません。攻撃者が用意したリンクを管理者が踏む、といった手順が要ります。とはいえ、細工したURLを開かせるだけで足がかりができるのは、アカウントを持たない相手にも入口があるということです。問い合わせフォーム経由で管理者宛にURLが送られてくる現場を思うと、まったくの他人事にはしにくいところです。

権限の低いユーザーがいるサイトほど確認したい

残りの修正も、後回しにしてよいものではありません。投稿者や寄稿者の権限で保存できてしまうスクリプトの混入、パスワード保護した記事のコメントが一覧に漏れる問題、マルチサイトで登録を開放している場合の権限昇格、URLの検証をすり抜けて内部向けのアドレスへ通信させられる不具合などが並びます。

WordPressの権限は、寄稿者は記事を書けても公開はできない、といった段階で線が引かれています。その前提のもとで運用を組んでいる現場からすると、寄稿者の権限でスクリプトを保存できてしまう状態は、引いていたはずの線が一段ゆるむことを意味します。外部に原稿を頼んでいる場合、相手を疑うかどうかという話ではなく、そのアカウントが乗っ取られたときの被害範囲が変わってくる、と考えたほうが実態に近いはずです。

共通しているのは、外部のライターや複数の担当者が出入りするサイトほど影響を受けやすい、という点です。編集部制で運用しているメディアや、支店ごとに更新担当を置いているサイトは、この機会に権限の割り当てもあわせて見直しておくと落ち着きます。使っていない寄稿者アカウントが残っているケースは、実際にかなり多いはずです。

古い版にもさかのぼって修正が配られた

今回目を引くのは、修正が現行版だけでなく、4.7系まで戻ってそれぞれの系統に配られたことです。7.0系は12件すべて、6系はおおむね8件から11件、5系や4系は7件から8件が該当し、系統ごとに対応版が出ています。4.6以前はすでに対象外です。

本体を大きく上げるのが難しい案件でも、同じ系統の中で当てられる修正が用意されている、という意味になります。古いから手の打ちようがない、ということはありません。ただし、正式にサポートされているのは最新版だけ、という原則自体は変わっていません。古い系統への配布はあくまで好意によるものだと明記されています。制作を引き継いだまま長く動いているサイトを抱えているなら、いまどの系統で止まっているのかを一度洗い出しておく価値があります。

自動更新が生きているかを見ておく

マイナー更新の自動適用が有効なら、公開から数時間のうちに当たっているはずです。問題になりやすいのは、過去の検証や不具合の切り分けで自動更新を止めたまま元に戻していない環境で、こうしたサイトは静かに取り残されます。契約しているサーバー会社の管理画面側で更新をまとめて制御している場合もあるので、どこで止まっているのかを切り分けておくと話が早くなります。

管理画面の更新ページでバージョンを確かめ、必要なら手動で当てる。あわせて、wp-config.phpやサーバー側の設定で自動更新を無効にしていないかも見ておくと、次の臨時リリースのときに慌てずに済みます。更新後にログイン画面と投稿の編集画面がふだんどおり開くかを確認しておけば、ひとまず十分でしょう。

修正が公開されてから実際に狙われはじめるまでの間隔は、年々短くなっているという報告が続いています。次の定例作業のときにまとめて、という進め方は、少なくとも本体のセキュリティリリースに関しては取りにくくなってきました。

日本語を含むメールアドレスへの対応が次期WordPressで見送られた

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

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

カメラとマイクの許可をブラウザに任せるHTMLの新要素

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

ウェブサイトでカメラやマイクを使う場面は、ここ数年で少しずつ増えてきました。オンライン相談の入口、動画で送るお問い合わせ、現場のスタッフが撮影してそのまま投稿する仕組みなど、業種を問わず出てきます。その手前に必ず挟まるのが、ブラウザが表示する「カメラの使用を許可しますか」という確認です。

Chrome 151が2026年7月28日に公開され、この確認の出し方そのものを見直す新しいHTML要素、usermedia要素が使えるようになりました。JavaScriptから許可を求めるのではなく、ブラウザが仲立ちする部品を押してもらう形に変わります。

スクリプトから許可を求める方式のつまずき

これまでカメラやマイクを使うには、JavaScriptでgetUserMediaという命令を呼び、その瞬間にブラウザが許可の確認を出す形が標準でした。書き方としては素直ですが、実際の現場では困りごとがついて回ります。

ひとつは、確認が出るタイミングを利用者が予想しにくいことです。ページを開いた直後に何の脈絡もなく確認が出れば、多くの人はとりあえず拒否します。もうひとつは、拒否したあとの復帰が難しいことです。いったん拒否すると次からは確認すら出ず、ブラウザの設定画面を自力で開いて権限を戻す必要があります。制作側からは、その設定画面への案内文を書き添えるくらいしか打つ手がありませんでした。

迷惑な確認を減らすため、ブラウザ側が自動的に確認を抑え込む挙動も広がっています。まっとうに作ったページが、その網に引っかかって何も起きないという事故も起こり得ます。

ボタンを包むだけの書き方

usermedia要素は、押してもらうボタンをこの要素で包むだけで使えます。中に置いたボタンの見た目はこれまでどおり自由に整えられ、押されたあとの段取りをブラウザが引き受けます。

結果の受け取りは、要素が発火する3種類の出来事を見張る形です。許可されたときのstream、失敗したときのerror、利用者が確認を閉じたときのcancelの3つで、映像や音声の本体はstreamから受け取ります。解像度やエコー除去といった希望は、押される前にsetConstraintsで指定しておきます。従来の書き方で必要だった成功と失敗の分岐や状態管理のコードは、かなり減らせます。

目に見えて変わるのは、確認が出る条件です。従来はスクリプトの都合で確認を出せましたが、この要素ではブラウザが用意した部品が実際に押されるまで確認は出ません。裏を返せば、勝手なタイミングで確認を出す作りが成立しなくなるということでもあり、利用者側から見た予測しやすさは上がります。

拒否されたあとに戻ってこられるかどうか

この要素の効き目がはっきり出ているのが、一度拒否されたあとの復帰です。Chromeの開発者向け情報によると、試験導入に参加したCiscoの計測では、従来の方式で復帰できた人がおよそ1割だったのに対し、新しい要素では6割を超えたとされています。Zoomでは撮影や録音の失敗が約47パーセント減り、Google Meetでは「マイクが動かない」という申告が約17パーセント減ったという数字も挙がっています。

理由は単純で、利用者が自分でボタンを押したという事実をブラウザが確実に把握できるからです。押した本人の意思がはっきりしているぶん、ブラウザは自動的な抑制を回さずに済み、拒否済みの状態からその場で復帰させる専用の流れを出せます。設定画面まで手順を案内しなくてよくなるのは、問い合わせ対応の手間という面でも小さくありません。

今すぐ全面的に置き換えるものではない

現時点で動くのはChrome 151以降で、他のブラウザはこれからです。仕様はW3Cのメディアキャプチャ拡張仕様に載っており、将来はカメラ用、マイク用といった用途別の要素も検討されています。

対応しているかどうかは、HTMLUserMediaElementという名前がブラウザ側に存在するかで判定できます。対応していないブラウザでは要素の中に書いた内容がそのまま表示されるので、中に従来のgetUserMediaを呼ぶボタンを置いておけば、ひとつの記述で両方の環境をまかなえます。新規に組むならこの入れ子の形から始めておくと、対応ブラウザが増えたときに書き直さずに済みます。

カメラやマイクを扱うページは、動くかどうかが問い合わせ件数に直結します。実装の難しさよりも、拒否したまま戻れなくなった利用者をどう救うかが実際の課題だった現場は多いはずで、そこにブラウザ側から手が入ったという意味で、頭の片隅に置いておく価値のある変化です。