Opinionニュース

Hostingerで共有サーバー侵害。400環境の認証情報が読まれた恐れ

2026/11/11更新 2026/11/118分で読める

Hostingerは米国フェニックスの共有ホスティングサーバー1台への不正アクセスを公表した。攻撃者は顧客サイトの脆弱性から入り、Webサーバー製品の未知の欠陥を使ってサイトごとの隔離を破った。コードを実行されたか、認証情報を読まれた可能性があるアカウントは約400件に及ぶ。[1]

提供会社は影響を受けたサイトを別サーバーへ移し、攻撃前のバックアップから復元した。Webサーバー製品の恒久修正も全共有サーバーへ適用済みである。だが、基盤側の復旧と、顧客が使うデータベース認証情報やアクセストークンの安全確認は同じ作業ではない。

共有サービスを使う企業は何を確認すべきか。答えは通知対象かを確かめたうえで、侵害された可能性のある秘密情報を交換し、その秘密で到達できる外部サービスのログまで追うことだ。パッチ適用だけでは、攻撃者がすでに読んだ可能性のある値を無効にできない。

1サイトの侵入からサーバー管理者権限へ

Hostingerによると、攻撃者は11月5日、顧客サイトの脆弱なコンテンツ管理システムを通じてサーバーへ入った。その後3日間をかけ、LiteSpeed Web Serverの未知の脆弱性を発見して悪用した。サイトを分離するCloudLinux CageFSを越え、最終的にサーバーの管理者権限であるrootへ到達したという。[1]

共有ホスティングは、1台のサーバーを複数の顧客が使う。各サイトを隔離できていれば、ある顧客のサイトが侵害されても他の顧客へは広がりにくい。今回は最初のサイト侵害とWebサーバーの欠陥が連鎖し、その防波堤が破られた。

攻撃者の処理は共有Webサーバーの利用者として動き、通常の通信に紛れた。監視が不審な活動を検知したのは11月8日で、Hostingerがインシデントを宣言したのは翌9日12時26分UTCだった。侵入から検知までに時間差があり、隔離だけでなく、共用基盤を横断して異常を見つける監視も必要になる。

データセンターに並ぶサーバーラックのイメージ — 共有ホスティング基盤を示すイメージ。写真：Carl Lender、Wikimedia Commons、CC BY 2.0。トリミングして使用。

約400アカウントで確認された範囲

Hostingerは、攻撃者が約400アカウントでコードを実行したか、データベース認証情報やアクセストークンを読んだと説明している。一方、社内の管理システム、バックアップシステム、Hostingerアカウントへのログインを処理するシステムが侵害された証拠はない。バックアップが復号された証拠も確認していない。[1]

この説明から言えるのは、影響が全顧客へ広がったと確認されたわけではなく、5000台超のうち1台のサーバーに関係する顧客が対象だということだ。同時に「証拠がない」は、調査した範囲で確認していないという意味であり、約400アカウントに関する認証情報のリスクを取り消す言葉ではない。

認証情報が読まれた可能性は、サイトの復元とは切り分けて考える必要がある。復元したファイルが正常でも、同じデータベースのパスワードや外部APIのトークンが有効なままなら、別の経路から使われる余地が残る。復旧したサイトが表示できることと、秘密情報が安全であることは別の確認になる。

恒久修正が閉じた穴

LiteSpeedは11月10日、LiteSpeed Web Server 6.3.7 Build 9を公開した。変更履歴にはドキュメントルート外への不正なファイルアクセスを防ぐ修正が記載されている。suEXECを介さないスクリプト実行を防ぐため、Apache設定の処理も強化した。CageFSからの脱出に関係する修正である。[2]

Hostingerは同日16時03分UTCまでに、この修正を全共有ホスティングサーバーへ入れた。影響サーバーから全アカウントとサイトを移し、攻撃前のバックアップから復元したほか、内部認証情報も交換した。元のサーバーはオフラインにし、調査用の証拠として保存している。[1]

修正版の公開は同じ欠陥を使った再侵入を防ぐうえで大きい。ただし、Hostinger自身も調査は継続中としている。恒久修正の適用済みという事実を、全容解明や全顧客の秘密情報の交換済みという意味に広げてはいけない。