NTTスマートコネクトの共用レンタルサーバ「スマイルサーバ」で、収容サーバjm9・jm10が2026年7月24日から長期停止。公表資料・メンテナンス履歴・外形観測から、事業者が事件直前まで緊急のセキュリティ対策を繰り返していたにもかかわらず二台が止まった経緯を追い、共用ホスティングの責任境界とバックアップ設計の構造的限界を論じる。
スマイルサーバのトップページを開くと、いまも新着情報の一番上に、こう出ている。
「【重要なお知らせ】一部のサービス停止について」
NTTスマートコネクトが運営する共用レンタルサーバ「スマイルサーバ」。ページには「NTTグループならではの安心感・信頼感」「レンタルサーバー事業20年の実績」「平均稼働率99.998%」「日々、専任スタッフがセキュリティパッチを適用」——信頼を約束する言葉が並ぶ。導入実績には、官公庁、警察、消防、医療機関、教育機関、社会福祉法人の名が連なる。
その同じページの新着欄からリンクされた先で、二台の収容サーバが、二週間以上止まり続けている。
リンクの文言は「サービス停止」。集客の入口に、「不正アクセス」の四文字は出てこない。
そして、この記事で見ていきたいのは、この事業者が怠けていたという話ではない。むしろ逆だ。彼らは、驚くほど頻繁に、セキュリティのための工事を続けていた。事件の直前にも、二夜連続でセキュリティ対策を行っている。それでも、二台は止まった。なぜか。
7月24日、金曜18時。サポートの故障情報に、二行の告知が載った。
「本日、当社サーバにおいてメンテナンスを実施しています。対象：収容サーバ jm9、jm10.etius.jp のお客様」。
予告のない、金曜夜の、全サービス停止だった。翌25日には、「作業に当初の想定より時間を要しており、完了までの見通しが長期化」と案内された。そして26日、日曜日。同社は初めて言葉を変えた。
「サービス停止後、原因究明および安全性の確認を進めてまいりましたが、その後の調査において、対象環境に外部からの不正なアクセスを示す痕跡を確認いたしました」。
この文章の順番は、少し気になる。停止が先で、原因究明が後に書かれている。監視が攻撃を検知し、それを受けて遮断した、とは書かれていない。文章どおりに読めば、「止めた。調べた。不正アクセスの痕跡が見つかった」という順序だ。
もちろん、ランサムウェアなどの事案でも、最初のユーザー向け告知が「障害」や「メンテナンス」になり、調査を経て攻撃と判明することは珍しくない。だから、この順番だけを根拠に、攻撃の性質までは決められない。公表資料から確認できるのは、7月24日に停止し、26日に不正アクセスの痕跡を確認した、という事実だ。誰が、何を、いつ捉えてサービスを止めたのか——その検知の経緯は、公表されていない。
実際、ある制作会社は、公式発表の三日ほど前から、自社が管理する顧客サイトが表示できなくなっていたと記録している。
停止したのは、jm9とjm10だった。多数ある収容サーバの中から、事業者はこの二台を止めた。少なくとも、この二台には止める必要のある何かがあった。では、二台に共通するものは何だったのか。
公表資料から確認できる事実と、そこから考えられることを、分けて見ていきたい。
まず、確認できることから。停止した二台のうち、jm10には、事件直前まで外から異常なトラフィックが向かっていた。同社の故障情報によれば、7月12日から21日まで、そして22日から23日にかけて、jm10とjm11で「サーバ高負荷に伴う海外からの通信遮断」が実施されている。対象はHTTP、HTTPS、WebDAV。そしてその翌日、24日にjm9とjm10が停止した。
時系列としては、かなり近い。ただし、高負荷がそのまま侵入を意味するわけではない。大量のアクセスは、DDoSかもしれないし、クローラーやボットかもしれない。しかも、jm10と一緒に高負荷を受けていたjm11は、今回停止していない。逆に、停止したjm9は、この高負荷の記録には入っていない。だから「海外から攻撃されて二台が落ちた」とは言えない。言えるのは、停止の直前、この基盤の一部が外から強い負荷を受けていた、ということだ。
その同じ時期、事業者は別の動きもしていた。7月14日と15日、同社はjm2からjm14に及ぶ広い範囲で、二夜連続の「セキュリティ対策」を目的とした緊急メンテナンスを実施している。停止のわずか十日前のことだ。
では、なぜ、広く対策していたはずの中で、jm9とjm10だけが止まったのか。
ここに、共用ホスティングという仕組みの核心がある。
この基盤では、OSや土台の部分は事業者が管理する。一方で、その上に載るWebアプリケーション——PHPやCGIで書かれた各社のサイト——は、顧客がそれぞれ自分で用意し、設置する。仕様書にも、この責任の分かれ目ははっきり描かれている。事業者はOSや共通基盤に横断的な対策を打てる。だが、jm9に載っている顧客群と、jm11に載っている顧客群とでは、インターネットに公開されているコードそのものが違う。
さらに、事件の少し前、5月15日に、同社は古いPHP(7.4)を使う顧客に対し、新しいバージョンへの移行を、8月31日を期限として求めていた。つまり事故の時点は、古いPHP 7.4から新しい環境への移行期間の途中だった。顧客ごとに動かしているアプリケーションも異なる。
ここから一つの仮説が立つ。収容サーバごとに載っている顧客のアプリケーションが違えば、インターネット側から見た攻撃面も同じではない。侵入の起点が特定の収容サーバに偏った理由として、顧客側のコードの違いは候補になり得る。
ただし、ここには飛躍を置かないよう注意したい。顧客のWebアプリケーションへ侵入しただけで、収容サーバ全体を止める必要が生じるとは限らない。攻撃者が顧客領域を操作できることと、事業者が収容サーバごと全サービスを停止することの間には、距離がある。もし今回そこから共用基盤側まで影響が及んだのであれば、その間には、権限昇格や、テナントの境界を越える脆弱性や、共有コンポーネント・管理面への到達など、もう一段の経路が必要になる。それが実際にあったのかどうかは、公表資料からは分からない。
言えるのは、「事業者が守れる層」と「顧客が管理する層」の境目に、管理の隙間が生まれ得る、という共用ホスティングの構造が、公開資料から読み取れることだ。そして今回、その構造の中で、二台だけが止まった。
なお、この基盤は仮想化されている。仕様書には、事業者の運用範囲として「ハードウェア／ハイパーバイザ／OS」の層が明記されている。ただし、jm9という収容サーバ名が、そのまま一つの仮想サーバに対応するのかどうかまでは、公開資料からは分からない。基盤が仮想化構成であること自体は確かだ、というところに留めておく。
保守の履歴には、もう一つ気になる日がある。2026年5月21日。同社は緊急メンテナンスを実施し、jm9・jm10を含む広い範囲の収容サーバで、PHPの「SOAP」モジュールを無効化した。理由も明記されている。
「PHPにおける重大な脆弱性 CVE-2026-6722 が確認されたため、緊急対策として、影響を受ける該当モジュールを無効化いたします」。さらに、「本対応は暫定対策であり、恒久対策として後日PHPのバージョンアップを予定しております」と続く。
CVE-2026-6722は、この年5月に公表された、PHPのSOAP拡張に関する深刻な脆弱性だ。特定の条件下で、対象サーバ上での任意コード実行につながり得る。SOAP機能を使うアプリケーションが、外部から送られてくるデータを処理する場合に問題になる。
ここから分かることは二つある。一つは、事業者が5月の時点で、基盤上のPHPに重大な脆弱性があると認識し、緊急対応していたこと。もう一つは、その対応が「SOAPモジュールを無効化する」という暫定措置で、PHPそのものの更新は後日に回されたことだ。
なぜ、まず応急処置なのか。共用サーバでは、多数の顧客がそれぞれ異なるPHPアプリケーションを動かしている。PHPを一斉に新しいバージョンへ上げれば、動かなくなるサイトが出る可能性がある。顧客ごとに使っているCMSもプラグインも違う。事業者が基盤を更新したくても、顧客側のアプリケーションとの互換性を無視して進めることはできない。だからまず危険な機能を止め、根本対応を後に回す。共用ホスティングでは、そうせざるを得ない場面がある。
そして、その後の7月に、今回の二台が停止した。
CVE-2026-6722が侵入経路だったという証拠はない。SOAPを無効化した後の出来事であり、まったく別の経路だった可能性もある。PHP本体、CMS、プラグイン、認証情報、管理系——入口はいくらでも考えられる。だから言えるのは、侵入経路のことではない。事業者が5月の時点ですでに、基盤上に重大な脆弱性があり、緊急対応が必要な状況に直面していた——その事実だ。
その緊急対応は、一度ではない。同社のメンテナンス履歴をさかのぼると、緊急メンテナンスの多さが目につく。2026年に入ってから、通常の工事とは別に、緊急メンテナンスだけで七回。特に7月は、今回の停止直前の二週間にも、緊急工事が立て続けに行われている。そして停止後の8月1日にも、止まっているjm9・jm10を除く残りの基盤に対して、再び「セキュリティ対策」の緊急メンテナンスが実施されている。
CVEが出る。緊急対応する。危険な機能を止める。バージョンを上げる。その記録が、延々と続いている。
これを見て、「管理がずさんだった」と読むのは違うと思う。むしろ逆だ。脆弱性が公表されるたびに対応している。放置していたのではなく、塞ぎ続けている。それでも次の穴が出る。
この頻度が示しているのは、事業者の怠慢ではない。共用ホスティングという仕組みが背負っている、保守の難しさそのものだ。
一つの基盤に、多数の顧客のコードが載る。そのコードからは、毎日のように新しい脆弱性が見つかる。しかし、すべてを事業者が自由に更新できるわけではない。事業者はOSや基盤を守れる。だが、顧客のCMSやプラグインまでは勝手に直せない。一方の顧客も、自分のサイトを更新できるはずだが、実際には制作会社へ任せたまま何年も動かしているケースがある。
事業者と顧客が、それぞれ別の層を管理する。そして、その境目には、管理の隙間が生まれ得る。事業者は、そうした隙間を埋めるために、緊急メンテナンスを繰り返す。真面目にやっても、終わらない。今回の事案が見せているのは、そんな構造だ。
7月27日の案内には、こうある。
「復旧までに長期間を要する見込みです。また、調査の結果によっては、データを復旧できない可能性もございます。お客様のお手元にバックアップをお持ちの場合は、そちらをもとに再構築を」。別の案内では、「再構築の代行作業は承っておりません」とも書かれている。
この二つの文は重い。ホスティング事業者が、自社のバックアップから元の環境を戻すとは言わず、顧客自身に、手元のバックアップから新しい環境を作り直すよう求めているからだ。
仕様を見ると、その理由が少し分かる。
同社のバックアップには、大きく二つある。事業者が運用のために取得するバックアップと、有料の「データバックアップオプション」だ。前者について、仕様書には「設備の故障などの理由によりデータを消失した場合」に備えるものだと書かれている。さらに、「当社が取得しているバックアップデータにつきましては、お客さまへの提供は実施いたしません」とも明記されている。つまり、これは顧客が自由に取り出して使えるバックアップではない。
さらに重要なのは、事業者側でバックアップを取得していても、ハードウェア故障やサーバソフトウェア障害以外の原因でデータが失われた場合には、そのバックアップから顧客のファイルを戻せないとしていることだ。必要なデータは、FTPで顧客自身のコンピュータへバックアップするよう案内されている。
不正アクセスによるデータ喪失は、ハードウェア故障でもサーバソフトウェア障害でもない。つまり今回のような事態は、少なくとも仕様上、事業者側バックアップからの復旧を約束した範囲の外にある。
有料のデータバックアップオプションもある。だが、その保存先が本番環境から物理的・論理的にどこまで分離されているかは、公開資料からは分からない。今回、そのバックアップ自体が被害を受けたとは公表されていない。だから、「バックアップまで破られた」とは言えない。ただし、7月27日に事業者自身が「お客様のお手元にバックアップをお持ちの場合は」と書いた事実は残る。
さらに、この基盤では、サーバのroot権限は事業者側が管理する仕様になっている。顧客は、自分が使う領域より下にあるOSや仮想化基盤には手を出せない。そこが破られれば、顧客自身には守りようがない。
ここで問われているのは、バックアップがあるかどうかではない。そのバックアップを、誰が管理しているのか。本番もバックアップも同じ事業者に預け、その事業者自身が事故の当事者になったとき、最後に戻れるコピーが、自分の手元に残っているか。共用ホスティングを使う側にとって、本当に考えるべきなのはそこだ。
公表資料だけでは見えにくい影響を、利用者の公開された記録が補っている。
停止後、複数の利用者が、代表メールが使えないことと、自社サイトが見られないことを、同時に訴えている。医療機関、企業、クリエイター。スマイルサーバが導入実績として掲げる、まさにその利用者層だ。共用サーバでは、Web、メール、データベースなどが同じ収容基盤の上に載る。そのため収容サーバが止まれば、顧客にとってはWebだけでなく、メールまで同時に失われることがある。
そして、代替環境の案内を受けた利用者たちは、公開された記録の中で、同じようなことを書いている。これは元の環境を戻す「復旧」ではない。新しいサーバ環境を用意し、メール設定もDNSもWebサイトのデータも、自分たちで作り直さなければならない、と。データも自動では引き継がれない。ある利用者は、障害発生から新しい環境が使えるようになるまでの間に届いたはずのメールは取得できない、と記している。
これが、「データを復旧できない可能性」という言葉の、利用者側から見た意味だ。単にファイルが何個か失われるという話ではない。その間に、取引先や患者や顧客から送られていたはずのメールが、戻らない可能性がある。そして、環境を作り直す作業は、被害を受けた顧客自身が担う。
過去にも、似た事例はある。デンマークのCloudNordicでは、一次・二次のバックアップまで暗号化され、多くの顧客が事業者上のデータを失った。韓国のNAYANAでは、サーバとバックアップが暗号化され、自力での復旧を断念して多額の身代金を支払った。米国のRackspaceは、当初「セキュリティインシデント」と説明し、その後ランサムウェアだったと認め、元の環境を復旧させず別サービスへの移行を選んだ。
これらと今回には、違いもある。過去の事例では、攻撃が広がり、基盤全体が大きな被害を受けた。今回、公表されている停止対象は二台だ。もし、二台から先へ広げなかったのが監視や分離の成果だったのであれば、それは防御が機能した結果として評価されるべきだ。
ただし、二台で止まったからといって、共用ホスティングという仕組みの問題が消えるわけではない。
今回、被害を受けたのは、継ぎ接ぎだらけで放置された無名の事業者ではない。NTTグループの「安心と信頼」を掲げ、長年サービスを続け、脆弱性が出るたびに緊急メンテナンスを行い、事件の直前にも二夜連続でセキュリティ対策をしていた事業者だ。それでも、二台は止まり、「データを復旧できない可能性」が案内された。
ここには、「管理がずさんだったから」という分かりやすい説明では片づけられないものがある。あるのは、構造だ。
多数の顧客のコードを一つの基盤に集める。事業者はOSや基盤を守る。顧客はCMSやアプリケーションを守る。だが、その境界はきれいには分かれない。顧客のアプリを事業者が勝手に更新することはできず、事業者の基盤を顧客が守ることもできない。その間に、誰も管理しきれない隙間ができる。事業者が真面目に対応し続けても、すべての穴を完全に塞ぎ続けるのは難しい。
スマイルサーバの事案が突きつけているのは、その現実だと思う。
自分のデータの最後の一部を、預けた先だけに置いていないか。バックアップは、サービスとして買うことはできる。だが、預けた事業者そのものが破られたとき、そのバックアップは本当に自分を救ってくれるのか。トップページに「安心・信頼」と書かれていることは、その問いへの答えにはならない。
金曜の夜に「メンテナンス」と呼ばれたものは、そういう問いを、静かにこちらへ投げ返している。
本稿は、公開されているDNS・外部の一観測点からの応答、同社の公表資料およびメンテナンス履歴、ならびに報道と利用者の公開された記録に基づく外形的な分析である。侵入経路・被害の実態・復旧作業の内実、バックアップの被災有無、および二台が停止した個別の原因について、当事者による確定的な発表がなされたものではない。個々の利用者の投稿は、被害の傾向を示す範囲で要約し、逐語の引用や発信者の特定は避けた。なお、証明書透明性ログについても確認したが、7月30日前後の証明書の一斉発行は、事故前から予定されていた証明書更新工事で説明できるため、事故対応の証拠としては扱っていない。
安藤 典久
公開日: 2026/8/12
最終更新: 2026/8/12
セキュリティの最新情報をお届けします。