1. HOME
  2. ブログ記事一覧
  3. WordPressの更新はなぜ必要?実際に届いたSQLインジェクション攻撃

2026.08.24 WordPressの更新はなぜ必要?実際に届いたSQLインジェクション攻撃

WordPressの更新はなぜ必要?実際に届いたSQLインジェクション攻撃

Webサイトを公開するということは、世界中のどこからでもアクセスできる状態になるということです。それは同時に、悪意ある通信の対象にもなり得るということでもあります。

先日、AtlickのWebサイト(atlick.com)のアクセスログに、WordPressのREST API「/batch/v1」を狙った通信が記録されていました。

リクエストには、SQLインジェクション攻撃で使われる「union select」という文字列が含まれており、同一IPから短時間に繰り返し送信されるケースも確認しました。

今回はWAF(Web Application Firewall)によってすべてブロックされ、現時点でWebサイトへの影響は確認されていません。

また、WordPress本体も脆弱性が修正されたバージョンを使用していました。

この記事では、実際に届いたこの攻撃をもとに、WordPressを更新する意味と、更新だけで十分といえるのかについて解説します。

WordPressのREST API「/batch/v1」を狙ったSQLインジェクションをWAFでブロックした実際のログ

何が狙われたのか

今回狙われたと考えられるのは、WordPressのREST APIに用意されている「/batch/v1」を悪用する、wp2shellと呼ばれる脆弱性チェーンです。

脆弱性チェーンとは、複数の脆弱性を組み合わせ、より深刻な攻撃につなげる手法を指します。

REST APIは、外部のアプリケーションなどからWordPressのデータを取得・操作するための仕組みです。

そのうち「/batch/v1」には、複数のREST APIリクエストをまとめて処理する役割があります。

2026年7月、WordPressでは「REST APIのバッチルートの混同」と「SQLインジェクション」という2つの脆弱性が公表されました。

前者によって本来は認証が必要な処理へ外部から到達し、後者を悪用することで管理者権限を奪取できる可能性があります。

最終的には、サーバー上で任意のコードを実行できる状態(RCE)にまで発展する、深刻な脆弱性チェーンです。

wp2shellがバッチルートの混同、SQLインジェクション、管理者権限の奪取、任意コード実行へ発展する攻撃チェーン

今回、Atlickで検知した通信は、アクセス先が「/batch/v1」で、リクエストには「union select」が含まれていました。

これらの特徴はwp2shellを狙う通信と一致しており、管理者権限の奪取や任意コードの実行へつながる攻撃チェーンの一部だった可能性が高いと考えられます。

なぜWordPressを更新する必要があるのか

WordPressの脆弱性が公表されると、その情報は修正版を適用するためだけでなく、攻撃者が悪用方法を探す材料にもなります。

攻撃手法が公開されれば、自動化されたツールに組み込まれ、脆弱なバージョンを使用しているWebサイトが広く探索される可能性があります。

今回のwp2shellに関する脆弱性と修正版が公表されたのは、2026年7月17日です。

その後、Atlickでは8月10日と15日に「/batch/v1」を狙った通信を検知しました。

脆弱性の公表から1か月も経たないうちに、実際のWebサイトへ攻撃が届いていたことになります。

WordPressの公式発表と、GitHubで公開されている公式セキュリティアドバイザリ(SQLインジェクションREST APIのバッチルートの混同)では、影響を受けるバージョンと修正版が次のように示されています。

使用しているバージョン影響修正版
6.8.0〜6.8.5SQLインジェクション6.8.6
6.9.0〜6.9.4wp2shellの脆弱性チェーン6.9.5
7.0.0〜7.0.1wp2shellの脆弱性チェーン7.0.2

Atlickでは攻撃を受けた時点で、今回の脆弱性が修正されたバージョンを使用していました。

更新を放置せず修正版を適用していたことで、今回狙われた脆弱性にはすでに対応済みでした。

WordPressを更新する目的は、常に最も新しいバージョンへ変更することではありません。

新機能を追加するためだけでもなく、すでに知られている脆弱性を修正し、既知の攻撃が成立しにくい状態を維持することが重要です。

今回の攻撃から分かるWordPressの安全対策

今回の不正な通信を実際に遮断したのはWAFです。

WAFが不正な通信のパターンを検知し、WordPressで処理される前にすべてブロックしました。

加えてAtlickでは、WordPress本体に脆弱性が修正されたバージョンを適用し、今回公表された脆弱性にも対応していました。

このように、入口での防御となるWAFと、根本的な対策となる修正版の適用を重ねることで、どちらか一方だけに依存しない多層的な防御につながります。

WAFで不正な通信をブロックし、脆弱性修正版で既知の問題に対応するWordPressの多層防御

ただし、WordPressを更新していればすべての攻撃を防げるわけではなく、WAFもあらゆる通信を必ず遮断できるものではありません。

WordPressの更新には注意も必要です。特に大きな機能変更を伴うメジャーアップデートでは、使用中のテーマやプラグインとの互換性が失われ、Webサイトの表示や動作に不具合が出ることがあります。

そのため、更新内容を確認し、可能であればテスト環境で動作を確認してから反映することが望ましいといえます。

セキュリティ修正を含む更新は速やかに適用し、大きな変更を伴う更新は計画的に進める。

この使い分けが、WordPressを安全に運用することにつながります。

Webサイトは公開後の保守が重要

今回はAtlickのWebサイトへ実際に届いた攻撃を例に、WordPressを更新する理由と、更新だけでは十分といえない理由について解説しました。

Webサイトは公開した時点で完成するものではなく、公開後も攻撃の対象になる可能性があります。

今回はWAFが不正な通信をすべてブロックしました。加えて、WordPressにも脆弱性の修正版を適用しており、多層的な備えが整っていました。現時点でWebサイトへの影響は確認されていません。

WordPressを安全に運用するためには、更新内容を確認しながら必要な修正版を適用すること、そしてWAFやアクセスログを通じて日頃の状況を把握しておくことが重要です。

Atlickでは、Webサイトの制作は公開して終わりではなく、公開後の運用・保守までを含めて成り立つものだと考えています。