タグ: セキュリティ

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

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の解説が挙げているのは、そうした地味な項目です。

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

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の次のバージョンにあたる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日の公開予定で、こちらは通常どおりの日程で進んでいる。

更新の通知が来たらできるだけ早く当てる。WordPressサイトを預かる立場では長く正しい習慣として語られてきましたし、その前提はいまも変わりません。ただ2026年に入ってから表面化したいくつかの事例は、その習慣が暗黙に置いている「配信されてくる更新そのものは信頼できる」という部分に、これまでとは違う角度から光を当てました。

狙われたのはプラグインのコードに残っていた穴ではなく、プラグインが利用者の手元に届くまでの経路のほうです。脆弱性を探して突くのではなく、正規の更新に紛れ込んで入ってくる。防ぐ側から見ると、注意を向ける場所が一段ずれる話になります。

所有者が変わったあとに仕込まれた休眠コード

4月初旬に問題になったのは、Essential Pluginという作者名で公式ディレクトリに並んでいた30本あまりのプラグインでした。カウントダウンタイマー、クリックで開くポップアップ、お客様の声の表示といった、小規模サイトで気軽に足される種類のものが並んでおり、合計の稼働数は数十万件規模とされています。

経緯として報じられているのは、この一群がまとめて売買され、開発者が交代していたという点です。WordPress.orgのプラグインは、作者が変わっても配布の枠組みはそのまま引き継がれます。利用者側の管理画面には、以前と同じ名前のプラグインに更新が来たようにしか見えません。

不正なコードが加えられたのは2025年8月、互換性対応をうたった版でした。そこから約8か月のあいだ、そのコードは何もしないまま眠っていたと分析されています。動き出したのは2026年4月上旬で、外部から指示を受け取って処理を実行する経路が有効になり、検索エンジンのクローラーに対してだけ表示されるスパムや転送が仕込まれました。WordPress.orgのプラグインチームは4月7日に該当する全プラグインの配布を停止し、翌日には強制的な更新で通信部分を無効化しています。

公式ディレクトリの外でも同じ形が起きた

6月には別の形の事例が公表されました。ShapedPluginという開発元の有償版プラグイン、具体的にはWooCommerce向けの商品スライダー、お客様の声、投稿一覧表示の三製品で、開発元自身のビルドと配信の仕組みが侵害されていたというものです。

こちらで問題になったのは、公式ディレクトリに置かれている無償版ではなく、開発元のサーバーから直接配信される有償版のほうでした。つまり影響を受けたのは、対価を払って正規に自動更新を受けていた利用者だけということになります。混入は5月下旬、利用者からの報告が上がり始めたのが6月上旬、開発元が事実を認めたのが6月中旬という流れでした。

盗み出されたとされる情報は、管理者のログイン情報、二段階認証の秘密鍵、データベースの接続情報、メール送信サービスの認証情報、そして受注データにまで及びます。セキュリティメディアの報道では、一連の侵害はCVE-2026-10735として整理されています。有償版だから安全、公式ディレクトリだから安全、という単純な線引きが成り立たないことを、二つの事例は逆方向から示した形です。

気づくまでに時間がかかる理由

Essential Pluginの件で目を引くのは、仕込まれてから発覚するまでのおよそ8か月という長さです。仕込む側からすれば、加えた直後に動かす必要はありません。しばらく普通に動く版を配り、更新が行き渡り、疑いが薄れたころに起こせばよい。監視する側の目線に合わせて時間をずらされると、更新直後の挙動を見るだけでは捕まえられなくなります。

もうひとつは、公式ディレクトリに所有者交代を扱う仕組みが用意されていないという構造の問題です。プラグインが売買されて委譲されても、利用者に通知が飛ぶわけではなく、新しい担当者による最初の更新に追加の審査が入るわけでもありません。稼働数の多いプラグインは、それ自体が売り物として価値を持ちます。数万件のサイトに更新を届けられる立場が、市場で取引できてしまうという事実のほうが、個々の脆弱性より扱いが難しい部分かもしれません。

被害の出方が静かであること

今回のような侵害でやっかいなのは、サイトを見ている限り異変がわからないところです。Essential Pluginの件で配られたスパムは検索エンジンのクローラーにだけ見せる作りで、運営者が自分のサイトを開いても、いつも通りのページが表示されます。気づく糸口は検索結果の見え方や、Search Consoleの警告、ホスティング側からの連絡といった、サイトの外から届く信号のほうになります。

認証情報の窃取はさらに静かです。抜かれた時点では何も起きず、しばらく経ってから別の入口として使われます。管理画面のログイン履歴に見覚えのないものが混ざる、送信していないメールが自社ドメインから出ている、といった形で後から現れることが多く、そのころには最初の原因までたどるのが難しくなっています。

運用側でできる現実的な備え

まず効くのは、入れているプラグインの数を減らすことです。装飾のために一つ、フォームのために一つ、と足していった結果として、10本20本と並んでいるサイトは珍しくありません。一本ごとに、その開発元の更新経路を信頼するという判断が積み上がっていると考えると、使っていない機能のために枠を空けておく理由はあまりありません。

次に、自動更新をどこまで任せるかの線引きです。本体のマイナー更新は自動に任せるとして、プラグインについては稼働数の多いもの、更新頻度の高いものほど、当てる前に一拍置く運用にも意味があります。ただし更新を止めれば安全という話ではなく、既知の脆弱性を放置するほうが確率としてははるかに危ないので、遅らせるとしても数日という幅に留めるのが現実的でしょう。

加えて、更新の中身を軽く確かめる習慣も持っておきたいところです。プラグインの更新画面には変更内容へのリンクが並んでいますし、公式ディレクトリなら開発の記録も公開されています。毎回すべてを読む必要はありませんが、しばらく静かだったプラグインに突然大きな更新が来た、作者名の表示が変わっている、といった違和感は、目を通していれば引っかかります。今年の二件も、外形的な変化としては読み取れる材料が残っていました。

三つ目は、変化に気づける状態を作っておくことです。ファイルの改変を検知する仕組み、wp-config.phpや読み込み処理の周辺に見慣れない記述が増えていないかの確認、そして管理者アカウントの棚卸し。侵入を完全に防ぐ前提ではなく、入られたあと早く気づく前提で組んでおくほうが、この種の攻撃には噛み合います。

依存の数を意識するという話

WordPressの強みは、必要な機能をプラグインで足していける柔軟さにあります。制作会社としてもその恩恵は受けてきましたし、ゼロから作るより速く安く仕上げられる場面はいくらでもあります。ただ、その柔軟さは同時に、他人が書いたコードを自動で受け取り続ける関係を何本も抱えることでもあります。

プラグイン単体の良し悪しだけでなく、誰が作っていて、どういう経路で更新が届いていて、その開発元がいまも同じ人たちなのか。ここまで気にして選ぶのは手間ですが、今年の二件はその手間が無駄ではないことを示しています。次に一本足そうとしたとき、それが本当に必要かどうかを一度考えてみる。当たり前のようでいて、いちばん効く判断はそのあたりに残っている気がします。

WordPress本体に、ログインしていない相手がサーバー上で任意のコードを実行できてしまう脆弱性の組み合わせが見つかり、開発チームが緊急の修正版を公開しました。プラグインやテーマ側ではなく本体そのものの問題で、特別な設定や特定の拡張を入れていないサイトも対象になります。

公開は2026年7月17日。研究者が付けた「wp2shell」という呼び名で各所のセキュリティメディアが報じており、公開から数日のうちに実際に狙われている事例も確認されています。WordPressを扱っている制作者としては、いったん手を止めて手元の案件を見直しておきたい内容です。

本体だけで成立してしまう経路

今回問題になったのは二つの弱点です。ひとつは、WordPress 6.9で導入されたREST APIのバッチ処理用エンドポイントで、複数のリクエストをまとめて処理する際に権限の確認が正しく働かない場合があるというもの。もうひとつは、WP_Queryのauthor__not_inというパラメータに残っていたSQLインジェクションの穴で、こちらは6.8の系統から存在していたとされています。

単独で見ればどちらも即座に致命傷というわけではないのですが、順につないでいくと、認証を一切通らないまま任意のコードの実行まで到達します。プラグインを一つも入れていない素のWordPressでも成立する点が、今回いちばん重く受け止められている理由です。REST APIは投稿画面やブロックエディタが日常的に使っている入口なので、単純に閉じてしまえば済むという性質のものでもありません。

対象になる版と修正が入った版

修正版として出ているのは 7.0.2、6.9.5、6.8.6 の三つです。7.0.0から7.0.1、6.9.0から6.9.4、そして6.8系の古い版が対象に含まれます。自分の案件がどの系統で止まっているかによって、上げるべき先が変わる形です。

数年前に納品してそのまま動いている中小企業のサイトほど、メジャー更新を意図的に止めているケースが多いはずです。テーマや古いプラグインとの相性を心配して更新を保留する判断自体は珍しくありませんが、今回のように本体側で認証を通らない経路が見つかった場合は、その保留がそのまま危険の持ち越しになります。

なお、SQLインジェクション側の穴は6.8の系統から存在していたとされる一方で、実際に危険な連鎖として成立するのはREST APIの入口が加わった6.9以降です。古い版だから安全という話ではなく、修正版が出ている以上はどの系統でも上げておくのが素直な対応になります。

強制的な自動更新という対応

WordPress.orgは、対象となるサポート中のインストールに向けて自動更新を強制的に配信する措置を取りました。マイナー更新が自動で当たる仕組みは以前から用意されていましたが、深刻度に応じてここまで踏み込んだ形で運用されるのは、それだけ状況が急いでいるという合図と読めます。

ただし、この仕組みに全面的に寄りかかるのも避けたいところです。自動更新を明示的に無効化している環境、ファイルの書き換えを禁止している構成、独自の配置で運用しているサイトなどでは、そもそも配信が届きません。届いているつもりで届いていない、という状態がいちばん危ないパターンです。

受託で複数のサイトを預かっている立場だと、更新方針が案件ごとにばらばらというのもよくある話です。どのサイトが自動更新に任せてあって、どのサイトが手動運用なのか。今回のような場面で真っ先に効いてくるのは、その一覧がすぐ出てくるかどうかという、地味な管理の部分だったりします。

制作者側で確認しておきたいこと

まずは管理している各サイトのバージョンを実際に開いて確認するのが先です。更新が当たっているサイトはそれで終わりですが、当たっていないサイトが一つでも出てきたら、その環境で自動更新が働いていない理由を確かめておく価値があります。サーバー側で遮断する運用を取っている場合は、バッチ処理用のエンドポイントへの外部からのアクセスを一時的に止める手も選択肢に入ります。

抜けやすいのは、日常の運用から外れているサイトです。検証用に残したままの複製、しばらく更新していない古い案件、担当が変わって誰も見ていないサブドメイン。攻撃する側は運用の熱心さで対象を選り好みしないので、忘れられているサイトほど先に踏まれます。案件一覧を開いて、更新の当たり具合を一通り眺めておくだけでも、この週末の作業としては十分に意味があります。