← 記事一覧

セキュリティ

LiteSpeed は共有ホスティングの root 奪取を修正した。ただし番号は付けなかった

LiteSpeed Web Server Enterprise 6.3.7 は、1つのホスティングアカウントから共有サーバーの root を取れる脆弱性を静かに修正した。共有ホスティングのモデルそのものが依存する隔離が破られている。CVE も深刻度スコアもなく、悪用の有無への言及もない。警告を出したのは cPanel だった。

MAI
LiteSpeed Web Server Enterprise の開発元である LiteSpeed Technologies のロゴ。

9月11日、LiteSpeed Technologies は LiteSpeed Web Server Enterprise のバージョン 6.3.7 をリリースした。そのリリースログには SECURITY と記された3行が並んでいるが、新しいポスト量子暗号のオプションと、サーバーによる Node.js プロセスの扱いに関する修正との間に埋もれている。その3日後、cPanel がアドバイザリを公開し、少なくともそのうち1行が何のためのものだったかを明らかにした。権限の低いホスティングアカウントが自分のアカウントの外へ抜け出し、そのマシンで root を取得できる権限昇格の脆弱性である。

この脆弱性には今なお CVE 識別子が付いていない。深刻度スコアもない。実際に誰かに対して使われたのかどうかについて、両社のいずれからも説明はない。

影響を受ける範囲

製品LiteSpeed Web Server Enterprise
影響を受けるバージョン6.3.7 より前のすべてのバージョン
修正済みバージョン6.3.7(2026年9月11日リリース)
CVE9月15日時点で未採番
深刻度スコア未公開
悪用の有無両社とも言及なし

cPanel のアドバイザリは、その帰結を率直に書いている。サーバー上に通常のホスティングアカウントを1つ持つ攻撃者は、この脆弱性を使って

同じサーバーでホストされている他のウェブサイトやサーバー自体にアクセスし、改変する

ことができる。

この脆弱性は、CloudLinux のアカウント単位のファイルシステム隔離機能である CageFS も回避する。CageFS は、ある顧客が別の顧客のファイルに手を出せないようにするために、多くの共有ホスティング事業者が頼っている仕組みだ。どのように回避されるのかを両社は説明しておらず、変更履歴に並ぶ項目 — lscgid のリクエスト認証の強化、内部リダイレクト URL の検証強化、.htaccess から設定される内部用環境変数のブロック — のどれがこの問題を塞ぐものなのかも示されていない。

このクラスのバグが、スコア以上に厄介である理由

W3Techs の2026年9月時点の統計によれば、ウェブサーバーが判別できるウェブサイトのうち 14.6% が LiteSpeed を使っている。そのシェアは均等に分布しているわけではない。LiteSpeed Enterprise は Apache の差し替え先としてホスティング事業者に売られている製品であり、その重心にあるのは、まさにこのバグが危険になる環境だ。1台の物理サーバーが互いに無関係な数百から数千の顧客を載せ、それらをソフトウェアだけで隔離している環境である。

このアーキテクチャでは、アカウントの境界がセキュリティモデルのすべてだ。その境界を越える脆弱性は、1つのサイトを侵害するのではない。そのサーバー上のすべてのサイトと、そこに置かれた認証情報、データベース、バックアップまでを侵害する。しかも参加費は安い。攻撃者は管理者をフィッシングする必要も、外部に露出した管理ポートを探す必要もない。脆弱な事業者でホスティングアカウントを1つ買えばいい。数ドルで済み、そこには何の攻撃も要らない。

さらにこれは、今年に入って cPanel サーバー上の LiteSpeed スタックを経由して root に至る3つ目の経路でもある。5月の CVE-2026-48172 と6月の CVE-2026-54420 はいずれも LiteSpeed の cPanel プラグインを突くもので、どちらも実際に悪用され、どちらも CISA の Known Exploited Vulnerabilities カタログに登録された。9月の脆弱性は、コントロールパネル周りの接合部ではなくウェブサーバー本体にある初めてのものだ。つまり「プラグインを削除するか制限する」という小さな緩和策は使えない。脆弱なコンポーネントは、ページを配信しているソフトウェアそのものである。

本当の論点は開示のしかたにある

書くに値するのはバグそのものではない。その中身は両社の外にいる誰も見ていない。論点は、それがどのように世に出たかだ。

LiteSpeed は活発なセキュリティブログを運営している。8月27日には WordPress 向けキャッシュプラグインのクロスサイトスクリプティング2件について、それぞれ CVE 付きで投稿した。9月2日には Patchstack から報告されたサーバーサイドリクエストフォージェリについて投稿した。いずれも実在するが、軽微な問題だ。主力の商用ウェブサーバーでテナント境界を越えて root を取られる問題には、そのどれもなかった。ブログ記事もなく、識別子もなく、独自のアドバイザリもない。管理者に警告が届いたのは、cPanel が書くことを決めたからである。

CVE がなければ、この脆弱性は、業界がまさにこうした事態のために築いてきた仕組みから事実上見えない。脆弱性スキャナは識別子を手がかりに動く。パッチ管理システムも、コンプライアンス報告も、保険会社の質問票も、CISA の KEV カタログも同様だ。今日、ホスティング事業者が資産の棚卸しをしても、この問題はどこにも出てこない。載せるべきものが存在しないからだ。先の2件の LiteSpeed の脆弱性がその仕組みに捕捉されたのは、番号が付いた後であり、しかもどちらの場合もすでに悪用が始まった後だった。

悪用について沈黙していることが、悪用がない証拠になるわけでもない。このスタックの過去2件は、いずれも実際に攻撃に使われていたことが判明している。広く普及したホスティング基盤で、購入したアカウントから root を取れるバグは、この種のものを大規模にスキャンして回る者たちにとって理想的な標的に近い。そして静かなパッチと cPanel のアドバイザリのあいだに空いた3日間は、修正が公開されていながら警告が存在しなかった3日間である。

取るべき対応

LiteSpeed Enterprise を運用しているなら、6.3.7 に更新すること。LiteSpeed が文書化しているアップグレード手順は /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7 である。なお 6.4.0 RC2 が9月14日にリリースされているが、本番のホスティング基盤で手を伸ばすべき修正はリリース候補版ではない。

事業者ではなく利用者の立場なら、正直なところ自分で確認する手立てはない。だから訊くのは妥当なことだ。LiteSpeed のバージョンと、いつパッチを当てたかを答えられるホスティング事業者は、注意を払っている事業者である。更新後、運用者はパッチを結論ではなく出発点として扱い、該当サーバーの CGI の動作とログを確認すべきだ。この脆弱性がいつから悪用可能だったのか、実際に使われていたのかを裏づける情報は、現時点でどこにも公開されていない。

Sources: LiteSpeed Web Server release log · The Hacker News: LiteSpeed Enterprise Flaw Could Let One Hosting Account Gain Root Access on a Shared Server · LowEndTalk: 14 Sep 2026 — LiteSpeed Enterprise security advisory (URGENT) · The Hacker News: CISA Flags LiteSpeed cPanel Plugin Flaw Exploited for Root Privilege Escalation · Security Affairs: CISA adds Cisco Catalyst and LiteSpeed cPanel plugin flaws to its KEV catalog · Cyber Security Agency of Singapore: Critical Vulnerability in LiteSpeed User-End cPanel Plugin · LiteSpeed blog · W3Techs: Usage statistics of LiteSpeed

続けて読む