さくらインターネット不正アクセスから考える「プロバイダ側の侵害」という脅威モデル

はじめに

2026年8月17日、さくらインターネットが「さくらのレンタルサーバ」の一部顧客環境への不正アクセスを公表しました。

そして2日後の8月19日、調査が進む中でさらに深刻な事実が判明しています。顧客の契約情報などを管理する販売管理システムへの不正アクセスの可能性も確認され、影響を受けた可能性のある会員情報は最大136万563アカウントに上るとのことです。

今回の事案で特に注目すべきなのは、この一文です。

第三者が当社管理環境を経由して「さくらのレンタルサーバ」の一部お客さま環境へ不正アクセスを行っていたことを確認しました。

「利用者のパスワードが弱かった」「フィッシングに引っかかった」という話ではありません。サービス提供側の管理環境が足場にされた可能性がある、という構造的な問題です。

この記事では、今回の事案の経緯を整理しながら、「プロバイダ側の侵害」という脅威モデルについて考えてみます。また、Criminal IPのIT資産検索を使って、さくらインターネットのネットワーク上にどのような公開資産が見えるかも確認してみました。

事案の経緯（2026年8月20日時点）

2026年8月9日
さくらインターネットの管理するサーバー環境で異常を検知
調査を開始

2026年8月17日（第一報）
583アカウントへの不正ログインを確認
一部サーバーへのマルウェア設置を確認
「顧客領域内に保存された情報」「利用者識別子」が
閲覧または取得された可能性があると公表
「通信の秘密」に該当する情報へのアクセスが
可能な状態だったことも確認

2026年8月19日（第二報）
販売管理システムへの不正アクセスの可能性を追加で確認
影響を受けた可能性のある会員情報が最大136万563アカウントに拡大
レンタルサーバーへの不正アクセス検知（8月9日）以前に
発生した事象と判明、両者の関連性を調査中

侵入経路・発生時期・影響を受けたデータの範囲については、外部専門機関と連携して調査が継続されており、本記事執筆時点ではまだ明らかになっていません。

「管理環境を経由して」という一文の意味

今回の事案の性質を決めているのは583や136万という数字よりも、「当社管理環境を経由して」という部分です。
建物に例えると分かりやすいです。

通常の不正アクセス：

利用者の入口（パスワード）が破られて侵入される
→ 利用者側でパスワードを強化することで対策できる

今回の可能性：

運営側が使う管理用通路を通って顧客側へ侵入
→ 利用者側でできることが限られる

これが「プロバイダ側の侵害」という脅威モデルです。

なぜこれが重要なのか

共有ホスティング環境では、複数の顧客のデータが同じ物理インフラ上に存在しています。この環境では「テナント分離」（各顧客の領域を互いに分離する仕組み）が重要です。

しかし、管理環境が侵害されると、テナント分離の外側から顧客環境へアクセスできる可能性があります。つまり、利用者がどれだけセキュリティを強化しても、管理側の問題は防げないというケースが生じます。

サーバー上に置かれた情報のリスク

今回の事案で「顧客領域内に保存された情報」が閲覧・取得された可能性が示されています。
レンタルサーバーを利用しているエンジニアにとって、今すぐ確認しておきたいのはサーバー上に置かれている認証情報です。

特に注意が必要なファイル：

.env                    # APIキー、DBパスワードなど
wp-config.php           # WordPressのDBパスワード、秘密鍵
config/database.yml     # Railsのデータベース設定
config/credentials.yml.enc  # Railsの暗号化済み認証情報
.htpasswd               # Basic認証のパスワードファイル
id_rsa                  # SSHの秘密鍵

これらのファイルがサーバー上に存在する場合、第三者がサーバーにアクセスできる状態だったとすれば、含まれている認証情報が取得された可能性があります。

今できること：

• さくらインターネットからの個別案内を確認する
• サーバー上の.envや設定ファイルに記載されているAPIキー・DBパスワードのローテーションを検討する
• さくらのコントロールパネルのログイン履歴を確認する
• サーバー上に不審なファイルが設置されていないか確認する

ただし、さくらインターネットは8月17日時点で全利用者への一律のパスワード変更を求めていません。対象者への個別案内があるとのことで、公式サイトの情報を継続的に確認することが重要です。

Criminal IPでさくらインターネットの公開資産を見てみた

今回の事案とは直接の因果関係はありませんが、Criminal IPのIT資産検索で、さくらインターネットのネットワーク上に見える公開資産を確認してみました。

これはさくらインターネットから提供されているIPアドレスの中でも外部から確認可能な資産を表しています。

検索クエリ：as_name: "SAKURA Internet Inc."

（画像：as_name: "SAKURA Internet Inc." の検索結果）

また、検索結果の中に、気になる資産が複数確認できました。

SMBとNetbiosが外部に公開されているIP

（画像： 外部公開されている一部IPの詳細）

公開ポートを見ると、22/SSH、80/HTTP、139/Netbios、445/SMB、5985/Unknown、8001・8008・8081/Unknownが確認できます。

139（Netbios）と445（SMB）はWindowsのファイル共有に使われるプロトコルで、本来は社内ネットワーク内で使われるべきポートです。インターネットに直接公開されているのは通常の状態ではありません。SMBはWannaCryをはじめとする複数のランサムウェアが悪用した経路として広く知られており、インターネットに公開された状態は攻撃者にとって格好のターゲットになります。

注意： この資産はさくらインターネットのネットワーク上に存在することが確認できます。ただし、顧客が管理するVPSやサーバーである可能性もあり、今回の不正アクセス事案と直接関連があるとは言えません。いずれにせよ、「さくらインターネットが提供するネットワーク上にこのような状態の資産が外部から見える」という事実自体が、攻撃者にとっての情報になりえます。

OpenSSH 4.3が稼働している資産

別の資産では、2022番ポートでOpenSSH 4.3が稼働していることが確認できました。

OpenSSH 4.3は2006年リリースのバージョンです。現在から約20年前のソフトウェアがインターネット上でそのまま動き続けているということになります。

Criminal IPでこの資産を確認すると、2022番ポートだけで43件のCVEが検出されており、そのうちいくつかはCVSSv3でCriticalと評価されています。

（画像：OpenSSH 4.3が稼働している資産の脆弱性一覧）

さらに注目したいのが、検出されたCVEの中にGitHub上にPoCが公開されているものが含まれているという点です。PoCが存在するということは、脆弱性の悪用に高い技術力が不要になることを意味します。

バナーを確認すると、鍵交換アルゴリズムにはdiffie-hellman-group1-sha1（Logjam攻撃に脆弱）、暗号化アルゴリズムにはRC4（arcfour）やMD5ベースのMACが含まれていました。いずれも現在のセキュリティ基準では無効化が推奨されているアルゴリズムです。

これはOpenSSH特有の問題ではなく、「古いソフトウェアが更新されないまま稼働し続けるとどういう状態になるか」を示す典型的な事例です。前述のパッチ管理の難しさと直結しています。

さらにこの資産では、8080番ポートでApacheが稼働しており、Directory Listing（ディレクトリ一覧表示）が有効になっていることも確認できました。Directory Listingが有効な状態では、サーバーのディレクトリ構造やファイル一覧がブラウザから丸見えになります。攻撃者にとっては設定ファイルや認証情報ファイルの存在を確認するための情報収集の手がかりになります。

注意： この資産もさくらインターネットのネットワーク上に存在することが確認できます。ただし、顧客が管理するVPSやサーバーである可能性もあり、今回の不正アクセス事案と直接関連があるとは言えません。いずれにせよ、「さくらインターネットが提供するネットワーク上にこのような状態の資産が外部から見える」という事実自体が、攻撃者にとっての情報になりえます。

プロバイダ側の侵害に対して利用者ができること

「管理環境を経由して侵入された」可能性がある以上、利用者側でできることには限界があります。ただし、被害を最小限にするための備えはあります。

認証情報をサーバーに置かない

最も重要な対策は、秘密情報をサーバーに平文で置かないことです。

• APIキーや認証情報は環境変数として管理し、ソースコードやファイルに直接書かない
• クラウドの場合はSecrets Manager（AWS）やSecret Manager（GCP）などのマネージドサービスを使う

ただし、レンタルサーバーという環境の性質上、ある程度の設定ファイルはサーバー上に存在せざるを得ない場合もあります。

権限の最小化

• データベースアカウントはWebアプリに必要な最小限の権限（SELECT/INSERT/UPDATEなど）のみ付与する
• 管理者権限のアカウントをWebアプリが直接使わない

多層防御の考え方

ホスティング事業者への信頼と、自分自身のセキュリティ対策は別の話です。
今回の事案が示すのは、「信頼できるサービスプロバイダを選ぶことと、万が一侵害された場合の影響を最小化する設計をすることは、どちらも必要」ということです。

まとめ

今回のさくらインターネットの事案は、侵入経路がまだ明らかになっていない調査中の案件です。断定的な結論を出すのは時期尚早ですが、「当社管理環境を経由して」という説明は、利用者側の対策だけでは防ぎきれない類の侵害の可能性を示しています。

エンジニアとして意識しておきたいのは、どんなに信頼できるサービスを使っていても、そのサービス自体が侵害された場合のリスクを考えておくことです。サーバー上の認証情報の棚卸し、権限の最小化、重要な情報の暗号化・・・これらは「もしも」の時に被害範囲を限定するための備えです。

続報が出次第、侵入経路や具体的な影響範囲が明らかになると思います。公式からの案内を継続的に確認しつつ、今回の事案を「自分たちのインフラ設計を見直すきっかけ」として捉えてみてください。

参考

• 当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて（さくらインターネット公式・第一報）: https://www.sakura.ad.jp/corporate/information/newsreleases/2026/08/17/1968225614/
• 当社システムへの不正アクセスに関するお知らせ（第二報）: https://www.sakura.ad.jp/corporate/information/newsreleases/2026/08/19/1968225633/
• Criminal IP IT資産検索：https://search.criminalip.io/ja