記事一覧に戻る
security-news2026年8月26日17分で読めます

転換期のホスティングとセキュリティの空白――さくらの開示と、ロリポップの観測性

WP2Shell公表の1カ月後、さくらは第二報で、影響を受けた可能性のある対象を最大136万アカウントまで開示した。一方ロリポップからインシデントの発表はない。だが両社とも共有ホスティングから高付加価値へ「上」に向かう転換期にいる。その足元に残る約38万件をどう守り、利用者が何を確認できるのか。公開情報とShodan観察から情報の非対称を追う。

WordPressWP2Shell共有ホスティングさくらインターネットロリポップGMOペパボ情報開示ShodanAikido Zen

2026年7月17日、WordPressで、認証なしの遠隔コード実行につながる二つの脆弱性(CVE-2026-63030/CVE-2026-60137)が公表された。この二つを組み合わせた攻撃チェーンは「wp2shell」と呼ばれる。対象はWordPress 6.9.0〜6.9.4、7.0.0〜7.0.1。PoCは公表後まもなく出回り、公表当日から探索が観測され、翌18日から大量の攻撃が始まった。WordPress.orgは影響を受けるバージョンへの強制自動更新を有効化している。

その約1カ月後、国内の共有レンタルサーバーをめぐって別の事象が表面化した。さくらインターネットは8月17日、「さくらのレンタルサーバ」の一部環境への不正アクセスを公表した。一方、ロリポップからは、セキュリティインシデントの発表は確認できていない。ただ、公式の障害・メンテナンス情報を時系列で追うと、7月から8月にかけて複数の事象が記録されている。

ここで最初に線を引いておきたい。さくらの不正アクセスがWP2Shellによるものだという事実は確認されていない。さくら自身、侵入経路は調査中としている。ロリポップの障害やメンテナンスについても、WP2Shellとの関連を示す情報はない。本稿で見たいのは、別の共通点だ。さくらもロリポップも、いま事業の転換期にいる。そして、その足元には長年積み上げてきた共有ホスティングがある。同じ時期に、共有ホスティングのセキュリティと、その「外から分かるか」が問われた——それがこの記事のテーマだ。

さくらは「経営として開示した」

さくらインターネットは8月17日、不正アクセスの第一報を公表した。確認されたのは、583アカウントへの不正ログイン、攻撃者による顧客領域への到達、一部サーバーへのマルウェア設置、個人データが第三者に閲覧または取得された可能性だ。確認後には認証情報の無効化やアクセス遮断などの封じ込めを行っている。

8月19日の第二報では、調査の過程で、契約情報等を管理する販売管理システムへの不正アクセスの可能性が新たに判明した。これにより影響を受けた可能性のある会員情報は、最大1,360,563アカウントに及ぶ。うち30アカウントについては、ハッシュ化されたパスワード情報へのアクセスの可能性も判明した。ただしこれは影響が確定した数ではなく、現時点でデータの外部持ち出しは確認されていないという留保がついている。なお販売管理システムへの不正アクセスは、レンタルサーバーへの不正アクセスを検知した8月9日以前に発生した事象で、両者の関連はさくら自身が「調査中」としている。ここを一つの攻撃として結びつけることは、現時点ではできない。

583アカウントから、影響の可能性が136万アカウントまで広がった。それでもさくらは第二報を出した。ここが重要だ。そして興味深いのは、この対応が突然作られたものではないことだ。事件の約2カ月前、2026年6月に提出した有価証券報告書で、さくらはデジタルインフラ企業としてセキュリティ体制をかなり具体的に説明している。公共分野では、政府が求めるセキュリティ要件を満たすため、ガバメントクラウドに対応したセキュリティ基盤を構築するとしている。CISOを中心に情報セキュリティを運営し、重要事項は取締役会にも報告する体制だ。

さらに、インシデント発生時の流れまで書いてある。重要度を判断し、必要に応じてCISOや経営層へ報告する。そして重要なインシデントについては、初動対応、封じ込め、証拠保全、調査、復旧というプロセスを専門部署が開始し、サポート部門や広報とも連携する。2024年10月には、提供サービスのセキュリティを専門に扱うPSIRTをSIRTから独立させている。

今回の開示が、この経営戦略によって行われたと因果関係まで断定することはできない。ただ少なくとも、今回実際に行われた封じ込め、調査、利用者への通知、情報公開という動きは、事件前に会社自身が公開していたインシデント対応の考え方と整合している。

そして、その背景にはさくら自身の大きな転換がある。さくらは、レンタルサーバーから始まった会社から、ガバメントクラウド、GPU、生成AIまでを支える国産デジタルインフラ企業へ事業領域を広げようとしている。政府や企業の重要システムを預かる方向へ進む以上、セキュリティは追加機能ではなく、その事業を成立させる前提になる。

ロリポップも「転換期の最中」にいる

一方、ロリポップを運営するGMOペパボも、大きな転換期にいる。これは推測ではない。GMOペパボ自身が投資家向け資料で、「低単価・利用件数重視」から「高単価・付加価値重視」への転換を明示している。注力プランも、ライト/スタンダードから、ハイスピード/for Gamersへ移すとしている。

ロリポップの契約件数は減少が続いている。2024年末の405,185件から、2025年末に392,002件、2026年3月末に386,339件、そして2026年6月末には381,766件となった。ただし、これはロリポップを縮小して終わらせるという話ではない。むしろブランドを別の方向へ広げようとしている。2026年7月には、AIエージェントで作ったWebアプリを簡単に公開できる「ロリポップ!デプロイナウ」を開始した。

GMOインターネットグループも2025年末、「KUSANAGI」で知られるプライム・ストラテジーを子会社化した。これはロリポップ自体の施策ではないが、GMOグループ全体でもWeb高速化・セキュリティ・マネージド領域を厚くする動きが進んでいる。その中でGMOペパボ自身も、デプロイナウなどを通じて、ロリポップを安価なWebサイト置き場から、高付加価値・AI時代のWebインフラへ広げようとしている。

転換期に残る「約38万件」

問題は、その転換の最中に何が残っているかだ。2026年6月末時点でも、ロリポップには約38万件の契約がある。

WP2Shellについて、ロリポップは7月21日にWordPress本体の重要なセキュリティアップデートを案内した。ロリポップの簡単インストールでは、初期状態でマイナーアップデートの自動更新が有効になっている。一方、自動更新を無効にしている利用者には手動更新を求めている。WordPress.org側でも強制自動更新が有効化されたため、多くのサイトには修正版が配布されたと考えられる。ただしIPAも、環境や設定によっては自動更新が無効だったり、更新に失敗している可能性があるため、実際のバージョン確認を求めている。約38万件という規模の共有ホスティングでは、すべての利用環境が同じ状態にあるとは限らない。

ここからが、今回気になったところだ。

ロリポップ自身の記録を時系列で並べる

個別のWordPressサイトでエラーが出ていることだけを見ても、セキュリティ事案かどうかは分からない。そこで今回は個別サイトを追うのではなく、ロリポップ自身が公表した障害・メンテナンス情報だけを時系列で並べてみた。

7月8日〜21日:全サーバー対象の緊急メンテナンス。 WP2Shellが公表される前から、ロリポップでは「サーバーの安定稼働のため」として、すべての利用者・すべてのサーバーを対象とする緊急メンテナンスが始まっていた。対象サーバーではWeb表示、FTP、SSH、WebDAV、ユーザー専用ページが一時利用できなくなるもので、当初予定より対応に時間を要し、7月21日19時05分に完了した。

7月17日:WP2Shell公表。 WordPressの認証不要RCEにつながる二つの脆弱性が公開され、探索・攻撃が観測され始めた。

7月18日:eco-1でDDoS。 午前1時44分から2時26分まで、DDoSの影響でWeb表示ができない障害が発生した。

7月21日:WordPressの重要アップデートを案内。 ロリポップが利用者に対し、WordPress 6.8.6、6.9.5、7.0.2以上への更新を案内した。

7月29日〜30日:全サーバーで生ログを取得できない障害。 7月29日4時頃から翌30日12時04分まで、アクセス解析の生ログをダウンロードすると「該当のログは空でした」と表示され、正常に取得できない状態になった。対象はすべてのサーバーだった。

7月30日:DDoS。 同日午前3時02分から3時44分まで、DDoSの影響により一部利用者のWebサイトへアクセスしづらい状態が発生した。

8月6日:データベース障害が約18時間継続。 午前1時44分頃から19時27分まで、データベースサーバーで「データベース接続確立エラー」などが発生。バックアップオプションでも、DBバックアップが完了しない場合があると案内された。

8月10日・11日:eco-1で連日のDDoS。 8月10日は8時34分から9時20分まで、翌11日は3時44分から5時31分まで、eco-1でDDoSの影響によるWeb表示障害が発生した。

8月21日:ユーザー専用ページ障害とMySQL緊急メンテナンス。 15時27分頃から16時41分まで、ユーザー専用ページへログインできない障害が発生した。同日、mysql401・mysql402を対象とする緊急メンテナンスも掲載されている。

ここに並べた事象が、一つの原因によって起きたことを示す情報はない。まして、WP2Shellと結びつける根拠もない。DDoSは以前からロリポップで発生しており、DB障害やログ取得障害も通常の運用障害である可能性は十分にある。したがって、「7月から8月に障害が多かった」とさえ、平常時との比較なしには断定できない。

ただし、全サーバー緊急メンテナンスの期間中にWP2Shellが公表され、その後、WordPress更新案内、全サーバーの生ログ取得障害、DB障害、DDoS、MySQL緊急メンテナンスなどが公式に記録された。ここまでは事実として時系列に残せる。公開情報だけでは、これらの事象間の関連性は判断できない。外から分かるのは、そこまでだ。

外から見える構成にも差がある

もう一つ、今回のShodan調査で気になった点がある。最初に注意しておきたいのは、Shodanが表示するCVEは、そのすべてが実際に悪用可能な未修正脆弱性であることを意味しないということだ。取得したサービスのバナーやバージョン情報から関連付けた未検証のCVEもあり、誤検出もあり得る。

その前提で、同じ virt.lolipop.jp の共有IP帯を比較すると、8月26日にShodan上で確認できたCVE候補数には大きな差があった。157.7.107.71は17件、157.7.107.28は150件超だった。この数字を「一方のサーバーには150件の未修正脆弱性が存在する」と読むことはできない。一方で、同じロリポップの共有ホスティング帯でも、Shodan上の観測結果には大きな差があることは分かる。

長年運用されてきた共有ホスティングでは、異なる時期に構築され、その後それぞれ更新されてきた環境が併存している可能性がある。これは、経営の「転換」を考えるときに重要だ。新しいサービスを作るだけでは終わらない。既存環境をどこまで統一するのか。古い環境をどう更新するのか。既存利用者をどのタイミングで新しい基盤へ移すのか。約38万件という規模になると、それ自体が大きな技術課題になる。

実は、両社とも「上」に向かっている

ここまで見ると、さくらとロリポップは正反対の会社ではない。むしろ両社とも、従来の共有ホスティングから「上」に向かっている。

GMOペパボは、低単価・大量のホスティングから、高単価・高付加価値へ、そしてAI時代のWebインフラへとロリポップの商品価値を広げようとしている。さくらは、レンタルサーバーからクラウド、ガバメントクラウド、GPU・AIを含む国産デジタルインフラへと会社そのものの役割を広げようとしている。そして両社とも、その出発点には長年利用されてきた共有ホスティングがある。ここに今回の本当のテーマがある。

転換期に問われる「誰が守るか」

さくらでは、実際に重大なインシデントが確認された。だから公表した。ロリポップについては、そもそも公表すべきセキュリティインシデントが存在するのか分からない。したがって、「さくらは透明、ロリポップは不透明」と単純に比較することはできない。

ただ、一つ見える違いはある。さくらは事件が起きる前から、検知、経営への報告、封じ込め、証拠保全、調査、復旧という流れを公開資料に書いていた。そして実際に問題が起きたとき、そのプロセスの一部が利用者からも見える形で進んだ。

一方、共有ホスティングの利用者から見ると、自分のWordPressに何が起きたのかを確認する手段は必ずしも多くない。ホスティング事業者からセキュリティインシデントの発表がなければ、本当に何もなかったのか、自分のサイトだけで何か起きていたのか、まだ調査されている途中なのか——その区別は利用者にはつかない。これはロリポップ固有の問題ではない。共有ホスティングにおける観測性の問題だ。

「分からない」を少しでも減らす

まず利用者自身でできることはある。WordPressが修正版になっているか確認する。管理者アカウントに知らないユーザーが増えていないかを見る。プラグインやテーマ、不審なPHPファイルの変更を確認する。アクセスログが利用できるなら、不審なリクエストが来ていないかを見る。バックアップも確認する。

ただし、一般的なWebアクセスログだけで、リクエストがアプリケーション内部でどこまで成立したかを完全に復元できるとは限らない。そこで、ホスティング事業者とは別に、アプリケーション側にも観測点を持つという方法がある。

Aikido ZenはWordPressのアプリケーション内で動作するIn-App Firewallで、WP2Shellが依存するSQLインジェクションのような攻撃を実行時に検知・ブロックする。外置きのWAFやCDNを置き換えるものではない。ホスティング事業者側の状況そのものが見えるわけでもない。それでも、外部から自分のWordPressへ到達した攻撃について、自分のアプリケーション側に防御と記録を持つことはできる。

「攻撃が来ていたのか」「何を遮断したのか」を、自分の側でも確認できる。その観測点を一つ増やす意味は大きい。

→ 無料で守るWordPress ― Aikido Zenを入れてみた


本稿で取り上げたロリポップの障害・メンテナンスは、同社が公開した情報を時系列に整理したものであり、それぞれに共通原因があることや、WP2Shellとの関連を示すものではない。また、さくらインターネットが公表した不正アクセスとWP2Shellとの関連も確認されていない。ShodanのCVE候補数は2026年8月26日にShodan上で確認した直近クロール由来の表示値であり、実在する未修正脆弱性の件数を意味しない。さくらインターネットおよびGMOペパボの被害状況・経営方針・契約数・セキュリティ体制については各社の公開資料および報道に基づく。

キーワード

  • WordPress
  • WP2Shell
  • 共有ホスティング
  • さくらインターネット
  • ロリポップ
  • GMOペパボ
  • 情報開示
  • Shodan
  • Aikido Zen
A

Aikido Community Japan

公開日: 2026/8/26

最終更新: 2026/8/27

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。