WordPress本体にプラグインなしの標準構成でも遠隔からコードを実行できる脆弱性が見つかりました。運営元は異例の強制自動更新に踏み切りましたが、管理者が把握しない放置サイトはこの網から漏れてしまいます。自動更新だけでは守れない理由を整理します。
この記事は会員限定です。会員登録すると全てご覧いただけます。
2026年7月18日未明、自分が管理するWebサイトで使っているコンテンツ管理システム(CMS)、「WordPress」の更新処理が完了したというメールが届いていました。最近のCMSはセキュリティアップデートを自動で更新してくれるので、基本的にはこのメールを見るだけでよいのですが、今回に関してはこれが大変重要な事態の始まりだったことに、この時は気が付いていませんでした。
これまではWordPressの脆弱(ぜいじゃく)性といえば、プラグインに起因するものがほとんどでしたが、今回発見されてバージョン7.0.2で対応された脆弱性、通称「wp2shell」は、WordPress本体そのものに残るものでした。ネットワーク上に到達さえできれば(ブログが公開状態にあれば)脆弱性を突いてサーバで不正なプログラムを動かせる、致命的なものです。
今回問題となっている脆弱性「wp2shell」は、脆弱性CVE-2026-63030、およびCVE-2026-60137の組み合わせで発生します。前者はREST APIのバッチ処理における不具合で、深刻度は「Critical(緊急)」。後者はSQLインジェクションで「High(高)」と評価されています。単体では悪用条件が限られますが、2つを組み合わせたwp2shell全体としてはCVSS 9.8の「緊急」に達します。
詳細はここでは省きますが、この2つを組み合わせることにより、認証することなくリモートコントロールができる、つまり「どんなプログラムも外部から実行可能」となる攻撃が可能な脆弱性の組み合わせが発見されたことになります。Searchlight CyberのAdam Kues氏により報告され、「wp2shell」と名付けられました。
今回のポイントは、プラグインを入れていない、素のWordPressでもこの脆弱性が存在し、即座のアップデートが必要ということです。前記の通り、基本的にWordPressではセキュリティアップデートが自動で適用されるため、多くのサイトでは既に対応完了しているものかと思います。
加えて、事態の緊急性から、多くのベンダーがかなり速い動きを見せました。このアップデートがリリースされたのは2026年7月17日で、脆弱性の存在が明らかになったのもほぼ同時でした。コンテンツデリバリネットワーク(CDN)を提供し、多くのサイトのトラフィックが経由することとなるCloudflareは、CDN自体で攻撃性の高いトラフィックを遮断する、Webアプリケーションファイアウォール機能を同日に有効化しました。
また、日本の個人WordPressサイトを多くホスティングする、エックスサーバーにおいても、2026年7月19日にWAF機能をオンにすると発表しています。
ただし、WAFで止めればいいというわけでもありません。クラウド型WAFを提供するベンダー、セキュアスカイも、7月19日時点でWAF対応が実行されたと発表すると同時に、「恒久的な対策としてWordPress公式情報をご確認の上、修正版へのアップデートをお願いいたします」としています。やはり、根本的な対策としてのアップデートは必須です。
W3Techsによると、WordPressはCMS全体の59.1%、世界のWebサイト全体でも41.2%のシェアを持つ、デファクトスタンダートのCMSです。このほぼ全てに「刺さる」脆弱性が明らかになったということは、実際にWebサイトを運営した人でないと本質的な理解は難しいかもしれません。上記のようにパッチの提供だけでなく、その(ほぼ)強制的な適用、ネットワーク上での緩和策の実施などが有効に動くことで、被害が最小化できているのではないかと思います。引き続きウォッチしてください。
しかし問題なのは、あえて自動アップデートを止めたまま運用しているWordPressサイトが多いことです。WordPressなどのCMSは、もしかしたら組織のシステム管理部門がまったく関与しない、シャドーITならぬ「シャドーCMS」になっていることが多く、加えて一度サイトを作ってしまうと保守管理すらもしていない可能性もあります。その場合、バージョンアップによる不具合発生を防ぐため、「あえて」古いバージョンで止めることも往々にして存在します。会社のウェブサイトがWordPressで作られていることすらも気が付いていないかもしれません。
「wp2shell」の影響を受けるのは、WordPress 6.9.0〜6.9.4と7.0.0〜7.0.1です。さらに、連鎖の一部であるSQLインジェクションはWordPress 6.8.0 〜6.8.5も影響を受けます。比較的新しいバージョンだけの問題ではなく、「昔のバージョンで止めていたから安全」とは言えません。今回の脆弱性発見から数日間の動きは、WordPressのみならず、全ての脆弱性対応の教訓となる動きが見えました。
今回、日本では3連休の初日(の早朝)にその脆弱性が明らかになったのですが、公開されたアップデートファイルはPHPのスクリプトであり、誰もが見ることができます。つまり、修正された内容を見ることで、実際にどのような脆弱性だったのかは誰もがチェックできる状態にあります。つまり、攻撃コードがそこから逆算できるのです。
加えて、問題は「パッチを適用する」ことだけではありません。その自動適用の前に攻撃が来ていたとしたら、入口を修正しても既に中に攻撃者の痕跡が残っている可能性もあるわけです。このレベルの脆弱性が明らかになった場合、パッチを適用するとともに「内部の改ざんがないか」「不正なプロセスが既に組み込まれていないか」なども合わせてチェックすべきでしょう。エックスサーバーはこの点に関してもアナウンスしています。
個人的に懸念しているのは、かつてのブログブームでWordPressを作ってはみたものの、投稿も止まり、放置されている可能性です。自動更新機能をオンにしていなかった場合、そこを侵入口としてさらなる被害が広がる可能性があるでしょう。また、WordPressを導入してWebサイトを制作を代行している業者は、IT事業者というよりもデザイン系の会社もあり、保守という考えが抜けてしまっている場合もあります。
システム管理者はこの脆弱性発表を機に、ぜひ自社で管理できていないWordPressサイトがないか、いま一度チェックしていただきたいと思います。そしてサイトそのものを(加えてプラグインを)しっかり管理する仕組みを持ち、今回のような脆弱性が発表されても即座に対応できるよう、体制を整えてください。
今回の脆弱性はまさに自分ごとだったため、本当に勉強になりました。そして、運用の重要性、難しさを感じる、大きな事件だと思います。
3800超のWordPressサイトを改ざん 大規模マルウェア配布基盤が82カ国で暗躍
Microsoft、7月の月例更新で約570件を修正 悪用済みゼロデイ2件にまず対応を
AIで高度化するサイバー攻撃にどう立ち向かう? 各種レポートに見る脅威の現在地とセキュリティの基本
サイバー攻撃17%増 生成AIプロンプト「26件に1件」が高リスクCopyright © ITmedia, Inc. All Rights Reserved.