さくらインターネット不正アクセスとは｜583と136万の関係・「影響なし」が指す範囲・確認手順

さくらインターネット不正アクセス——2026年8月17日に公表されたこの事案は、8月19日の第二報で性質が変わった。第一報は「さくらのレンタルサーバ」の583アカウントへの不正ログインという話だったが、第二報では会員の契約情報等を管理する「販売管理システム」への不正アクセスの可能性が加わり、対象となり得る会員情報は1,360,563アカウントになった。しかもこの新事象は、第一報の起点だった8月9日の検知よりも前に発生している。本記事では公式発表・適時開示・FAQという一次資料だけを使って、①時系列がどちら向きに伸びたのか、②583と1,360,563はどういう関係なのか、③第一報の「影響は確認されておりません」は何を守っていたのか、④2要素認証の必須化範囲から読める残余リスク、⑤FreeBSDである「さくらのレンタルサーバ」で実際に通る確認コマンド、を整理する。

開発者を狙う供給網まわりの攻撃と防御の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 をご覧ください。

さくらインターネット不正アクセスの時系列——第二報が伸ばしたのは「後ろ」ではなく「前」だった

続報が出たインシデントを追うとき、多くの場合は被害が時間軸の後ろへ広がる。調査が進んで「さらにこんな被害も見つかった」という形だ。今回はそうではない。

第二報の記述はこうなっている。「当該アクセスについては、先般公表した『さくらのレンタルサーバ』に対する不正アクセスを検知した8月9日以前に発生した事象であり、現在、関連性を含めて調査を継続しております」。販売管理システムへのアクセスは、第一報の起点だった8月9日の検知より前に位置している。

これは時系列の読み方を変える。第一報だけを見ていたときの図式は「8月9日に検知し、8月17日に公表するまで8日」だった。第二報を加えると、この事案の実際の開始点は8月9日ではないことになる。どこまで遡るかは公表されていない。

・確定している日付：8月9日（レンタルサーバ環境の異常検知・調査開始）、8月17日（第一報公表）、8月19日（第二報公表・適時開示・FAQ公開。第二報のページは18:40時点の更新と表示されている）
・確定していない日付：販売管理システムへのアクセスが発生した具体的な時期（「8月9日以前」とのみ記載）、レンタルサーバへの侵入開始時期、マルウェアが設置された時期
・確定していない関係：販売管理システムの件と、レンタルサーバの件が同一の侵入に由来するかどうか。公式は「関連性を含めて調査中」としている

第二報が販売管理システムの件を見つけた経緯も書かれている。「販売管理システムへの不正アクセスについては、レンタルサーバーサービス『さくらのレンタルサーバ』に対する不正アクセスの調査過程で確認されたものです」。レンタルサーバの調査を進めた結果として別系統の事象が浮かんだ、という順序だ。ここから「同じ攻撃者の一連の行動である」と読みたくなるが、公式は関連性を調査中と明言している。本記事では2つを別々の確定事実として扱い、結びつけない。

さくらインターネット側が実施している対応

利用者が何を確認すべきかを考える前提として、事業者側で何が行われているかを押さえておく。第二報の「現在実施している対応」には7項目が挙げられている。

・不正なアクセスに利用された認証情報の失効
・マルウェアの除去
・関連システムの監視強化
・販売管理システムを含む影響範囲の確認
・外部専門機関によるフォレンジック調査
・関係機関への報告および情報共有
・対象となるお客さまへの個別通知

第一報の段階で「認証情報の無効化、アクセス遮断、その他必要な封じ込め対応を実施済み」とされており、第二報はその後の調査・監視・通知のフェーズに入っていることが読み取れる。マルウェアの除去は事業者側が実施しているため、利用者が自分で駆除する話ではない。後述する確認手順は、除去の代替ではなく「攻撃者が置いていった可能性のあるもののうち、利用者領域に残る種類のもの」を見るためのものだ。

なお第一報の「現在実施している対応」には、「さくらのレンタルサーバ」のデータベースアップグレード機能・プラン変更・移行ツールなどの一部機能の制限も挙げられていた。この3つはいずれも、利用者の権限では完結せず事業者側の自動化が顧客データを読み書きしたり別の場所へ移したりする操作という共通点を持つ。ただし機能が制限された理由は公表されていない。侵入に使われたからかもしれないし、調査中にデータが動くのを避けるためかもしれない。ここから経路を逆算することはできない。

583と1,360,563は足し算ではない——公式が「含みます」と書いた包含関係

第二報でもっとも誤読されやすいのが、2つの数字の関係だ。583と1,360,563が並ぶと、別々の被害が2件あって合計136万台後半、と読みたくなる。

公式資料はそう書いていない。第二報の表には注記が付いている——「※1,360,563アカウントは既に公表している『さくらのレンタルサーバ』のお客さまを含みます。」 2つは別勘定ではなく、含む・含まれるの関係にある。

3つの数字それぞれの意味を、公式の文言のまま押さえておく。

影響を受けた可能性のある情報の中身も、第二報の表に列挙されている。583アカウント側は利用者識別子と、お客様環境に保存された情報（メールデータ、ウェブサイトデータ、ログ情報、その他顧客領域内に保存されたファイル等）。1,360,563アカウント側は契約情報（会員ID、会社名、部署名、住所、氏名、電話番号、メールアドレス、生年月日、性別、FAX番号、契約サービス、契約期間、請求金額等）だ。

この2つは性質がまったく違う。前者はサーバー上に置いたファイルとメールの中身、つまり利用者が自分で置いたものである。後者は契約者としての属性情報、つまりさくらインターネットに預けたものだ。前者は自分の手元で確認できるが、後者は確認しようがない。だから対応も分かれる。

30という数字だけが桁違いに小さいことについては、公式が理由を書いていない。136万件の会員情報にアクセスの可能性があるのに、ハッシュ化パスワードは30件にとどまる——この差が何に由来するのかは公表資料からは判断できないため、本記事では説明を試みない。

さくらインターネット不正アクセスで誤読されやすい2点——「影響なし」の軸と、583という数字

第一報は短い発表だったが、そこには読み違えやすい箇所が2つある。ひとつは「影響は確認されておりません」というリストの射程、もうひとつは583という数字が何を数えたものかだ。第二報はこの両方に、間接的にだが答えを与えている。

「影響は確認されておりません」が指していたのは提供環境であって会員情報ではない

ここが今回の続報でもっとも実務的な意味を持つ部分であり、第一報だけを読んで安心した利用者が最も引っかかりやすい場所でもある。

第一報には、影響が確認されていないサービスが名指しで4つ挙げられていた。さくらのVPS、さくらのクラウド、さくらの専用サーバ PHY、高火力 PHY。VPSやクラウドだけを契約している利用者の多くは、この一覧を見て「自分は対象外だ」と判断したはずだ。

だが第二報を読むと、その判断の射程が見えてくる。第二報にはこう書かれている——「なお、販売管理システムは当社サービスの契約情報等を管理するシステムであり、『さくらのクラウド』をはじめとした各サービスの提供環境とは別のシステムです」。

この一文は二重の働きをしている。ひとつは、クラウド利用者に対して「あなたが動かしている環境そのものは別系統だ」と安心させる働き。もうひとつは、第一報の「影響は確認されておりません」が最初から提供環境についての記述であって、会員情報を射程に入れていなかったことを、公式資料の中で確定させる働きだ。

そして公式FAQは、この点を利用者向けに言い切っている。「対象はレンタルサーバー利用者のみか」という問いに対する答えは、「対象範囲はレンタルサーバー利用者に限定されるものではございません」だ。

つまり整理するとこうなる。

・提供環境の軸：レンタルサーバは影響あり。VPS・クラウド・専用サーバ PHY・高火力 PHY は第一報時点で影響が確認されていない
・会員情報の軸：販売管理システムに保存された会員情報が対象。契約しているサービスの種類を問わない。さくらインターネットに会員登録がある時点で対象に含まれる可能性がある
・この2つは独立している：環境が無事でも会員情報の側で対象になり得るし、その逆もあり得る

自分が1,360,563に含まれるかどうかを利用者側から確定させる手段は無い。公式FAQは「現時点では、対象範囲について調査を継続しており、個別のお客さまが対象に含まれるかどうかを確定的にお伝えできる段階にございません」としたうえで、予防的措置としてパスワード変更を勧めている。対象確定の通知を待ってから動く設計にはなっていない、と読むのが妥当だ。

「当社管理環境を経由して」——583はパスワードが破られた話ではない

範囲の話を押さえたところで、もうひとつの誤読、583という数字に戻る。レンタルサーバーで「N件の不正ログイン」と聞くと、通常は利用者側の認証情報が破られた話——パスワードリスト攻撃や総当たり、利用者のPCからの認証情報窃取——を思い浮かべる。その図式なら対策は利用者側にある。強いパスワードにする、二要素認証を入れる、という話になる。

しかし第一報の書き方はそうなっていない。「第三者が当社管理環境を経由して『さくらのレンタルサーバ』の一部お客さま環境へ不正アクセスを行っていたことを確認しました」。侵入の起点は利用者のアカウントではなく、事業者側の管理環境だ。

この違いは実務的な意味を持つ。共有ホスティングでは、利用者が触れる領域の外側に、事業者だけが触れる管理層がある。プラン変更、データベースの作成や移行、バックアップ、アカウントの発行と停止——こうした操作は個々の顧客の権限では実行できない。裏返せば、その層はすべての顧客環境に対して横断的な権限を持っている。管理層が侵害された場合、そこから見える顧客環境の数は、利用者側の設定の堅牢さとは独立に決まる。

だから583は「583人が弱いパスワードを使っていた」ことを意味しない。不正ログインが判明したアカウントの数であり、同社は「影響を受けた可能性のあるお客さま環境について調査を継続しております」と注記している。

同時に、これは「利用者にできることは何もない」という意味でもない。攻撃者が到達したあとに何を置いていったか——マルウェア、追加された管理者アカウント、書き換えられた設定——は利用者側の領域に残る。第一報が利用者に対して「身に覚えのないファイルや管理者アカウントが追加されていないか」「ウェブサイトやアプリケーションに不審な変更が行われていないか」「心当たりのないログインやメール送信等が発生していないか」の確認を求めているのは、この残留物のためだ。

2要素認証の必須化範囲が、いま残っているリスクの地図になる

ここからは、公式発表そのものではなく、さくらインターネットがこの事案より前に公表していた仕様を使って、いま自分に残っているリスクを地図にする。

同社は2025年9月10日付の告知で、2025年12月3日に会員認証時の2要素認証を必須化すると公表している。重要なのはその適用範囲だ。告知は「2要素認証が必須となるのは会員メニューだけですか？」という問いに対し、「会員IDとパスワードを使って認証する全てのページが対象です」と答え、対象と対象外を具体名で挙げている。

必須化の告知そのものは2025年9月10日付で、文面は「必須化することといたしました」という予告の形をとっている。それが実施済みの状態として運用されていることは、レンタルサーバ側のマニュアルが現在形で「サーバーコントロールパネルの2要素認証は、会員メニューの2要素認証必須化の対象外です」と注意していることから確認できる。除外規定が現在形で書かれているということは、本体の必須化が動いているということだ。

この表を並べると、公式FAQが予防的措置として挙げた変更対象——サーバーパスワード（FTP）とメールアカウントのパスワード——が、ちょうど第二要素で守れない側に位置していることが見えてくる。会員メニュー系はすでに第二要素が必須化されているが、レンタルサーバのサーバーコントロールパネルは必須化の対象外で、メールソフトの認証にいたっては仕組み上2要素認証を適用できない。パスワードの強度と鮮度だけが防御になる層だ。

そのうえで、この地図から出てくる行動は具体的だ。

・サーバーコントロールパネルの2要素認証を有効にする。公式マニュアルの対象プランにはライトを含む全プラン（ライト／スタンダード／プレミアム／ビジネス／ビジネスプロ／マネージド／メールボックス／ビジネスメール）が挙がっている。後述するコマンドを1つも実行できないライトプランの利用者でも、これは実行できる
・追加ユーザー／メールアドレス側も忘れない。公式は「通常ログイン可能なアカウントがある場合、そのアカウントが操作できる範囲は2要素認証の保護対象外となります」と注意している。初期アカウントだけ有効にしても、未設定の追加アカウントが残っていればその範囲は守られない
・会員メニュー側の設定も併せて確認する。公式マニュアルは「サーバーコントロールパネルは会員メニューからもログインできますので、合わせて会員メニューの2要素認証の設定をお願いいたします」と明記している。入口が2つある以上、片方だけでは経路が残る
・信頼済みブラウザの登録を棚卸しする。会員側の必須化告知は「特定のブラウザからであれば2要素認証なしでログインすることが可能です」と説明している。便利な機能だが、必須化されていても省略経路が存在することは把握しておく

さくらのレンタルサーバ不正アクセス後に自分の環境を確認するコマンド——OSはFreeBSD

ここからは、サーバー上に残った可能性のある痕跡を自分で見る話に移る。第一報の「お客さまへのお願い」は散文で書かれている——「身に覚えのないファイルや管理者アカウントが追加されていないか」「ウェブサイトやアプリケーションに不審な変更が行われていないか」「心当たりのないログインやメール送信等が発生していないか」。何を見るべきかは分かるが、どう見るかは書かれていない。

前提：プランによって打てる手が違う

まず自分のプランを確認する必要がある。さくらインターネットの公式仕様によれば、ライトプランはSSH・データベース・cronのいずれも提供対象外だ。つまりライトプランの利用者は、以下のコマンドを1つも実行できない。

ライトプランの場合は、コントロールパネルのファイルマネージャー、またはFTPクライアントで接続し、ファイル一覧を更新日時の降順に並べ替えて見慣れないファイルがないかを目視する経路になる。ライトはデータベースを持たないためWordPressなどのCMSも動いておらず、確認対象は静的ファイルとメール周りに限られる。前節で触れたとおり、サーバーコントロールパネルの2要素認証はライトプランでも設定できるので、目視確認と併せて有効化しておく価値がある。

FreeBSDであることの落とし穴

スタンダード以上でSSHが使える場合も、そのままLinux向けの調査コマンドを貼り付けると動かない。さくらのレンタルサーバのOSはFreeBSDであり、find・stat・grep・チェックサム系のコマンドがGNU版とは別実装だからだ。インシデント対応の記事やチートシートはLinux（GNU coreutils）前提で書かれていることが多く、コピー＆ペーストすると次のように弾かれる。

1. 最近書き換えられたファイルを洗い出す

最初に見るのは更新日時だ。第二報で事象の起点が8月9日より前へ動いた以上、期間はさらに広めに取る。

# www 配下で、指定日以降に「内容が」変更されたファイル（mtime）
find ~/www -type f -newermt "2026-07-01" -ls

# 内容ではなく「メタデータが」変更されたファイル（ctime）。
# 攻撃者が touch で mtime を偽装しても ctime は巻き戻せないため、
# mtime と ctime の結果が食い違うファイルは優先して見る
find ~/www -type f -newerct "2026-07-01" -ls

# 日付ではなく相対日数で見る場合（-mtime は GNU/BSD 共通で使える）
find ~/www -type f -mtime -60 -exec ls -lT {} \;

-newermt / -newerct はBSDの find が持つ -newerXY 形式で、X に比較する時刻の種類（m=更新、c=メタデータ変更）、Y に t（引数を時刻文字列として解釈）を指定する書き方だ。GNU由来の -printf は使えないので、整形が必要なら -ls か -exec ls -lT を使う。ls -lT はBSDの ls で年まで含む完全なタイムスタンプを表示するオプションになる。

2. Webシェルの典型パターンを探す

マルウェア設置が確認されている以上、PHPファイルに実行系の関数が仕込まれていないかを見る。BSDの grep はPCRE（-P）を持たないため、拡張正規表現 -E と POSIX 文字クラスで書く。改ざん 確認の実務としては、ここが中心になる。

# 難読化・動的実行の典型キーワードを含む PHP を列挙
grep -rl --include="*.php" -E "eval[[:space:]]*\(|base64_decode|assert[[:space:]]*\(|gzinflate|str_rot13|preg_replace[[:space:]]*\(.*/e" ~/www

# 画像ディレクトリに PHP が置かれていないか（正規の構成ではまず存在しない）
find ~/www -type f -name "*.php" -path "*upload*"
find ~/www -type f -name "*.php" -path "*image*"

# .htaccess による拡張子の乗っ取りがないか
find ~/www -name ".htaccess" -exec grep -l "AddType\|AddHandler\|php_value\|auto_prepend_file" {} \;

.htaccess の確認を入れているのは、AddType application/x-httpd-php .png のような1行で、画像に見えるファイルをPHPとして実行させる細工が成立するためだ。ファイル名だけを見ていると見落とす。

3. 永続化の足がかりを確認する

侵入されたあと再侵入されないためには、置き土産のほうが重要になる。公開鍵とcronは代表的な永続化ポイントだ。

# 自分が登録した覚えのない公開鍵が混ざっていないか（1行=1鍵）
cat ~/.ssh/authorized_keys 2>/dev/null

# 鍵ファイル自体がいつ変更されたか
ls -lT ~/.ssh/ 2>/dev/null

# cron に不審なエントリがないか（スタンダード以上・最大10個）
crontab -l 2>/dev/null

もうひとつ、コマンドではなくコントロールパネルで確認すべき残留物がある。メールの転送設定だ。さくらのレンタルサーバでは転送先の設定はコントロールパネル側（対象メールアドレスの「設定」→「詳細設定」→転送先アドレス）で管理されるため、シェルから見に行くのではなくパネル上で各アドレスの転送先を1つずつ確認する。

これを挙げているのは、第一報が「通信の秘密に該当する情報」に言及しているためだ。転送設定は、一度仕込まれると以後の受信メールを継続的に外部へ流し続ける。パスワードを変えても消えない種類の残留物であり、しかもメール本文は通信の秘密そのものにあたる。優先度は高い。

4. CMSの管理者アカウントと認証情報を洗う

WordPressなどを動かしている場合、追加された管理者アカウントの確認が要る。第一報が明示的に「管理者アカウントが追加されていないか」を挙げている項目だ。データベースはスタンダード以上で利用できる。

# WordPress の管理者ユーザーを一覧（DB名・ユーザー名・接頭辞は wp-config.php に合わせる）
mysql -h <DBサーバ名> -u <DBユーザー> -p <DB名> -e \
  "SELECT u.ID, u.user_login, u.user_email, u.user_registered
   FROM wp_users u
   JOIN wp_usermeta m ON u.ID = m.user_id
   WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';"

# サーバー上に平文で置かれている認証情報の在処を洗い出す
find ~/www -type f \( -name "wp-config.php" -o -name ".env" -o -name "*.ini" \) -exec ls -lT {} \;

最後の1行が、この事案でとくに重要になる。第二報の表は、583アカウント側の情報として「その他顧客領域内に保存されたファイル等」を挙げている。サーバー上のファイルに平文で書かれた認証情報は、まさにこの「顧客領域内に保存されたファイル」だ。wp-config.php のデータベースパスワード、.env の外部APIキー、決済やメール配信のトークン——これらはサーバーのログインパスワードを変えても無効化されない。偽TanStackパッケージが.envを狙ったnpmサプライチェーン攻撃 と同様に、狙われるのは常に「そこに置いてある鍵」のほうだ。外部サービスのキーについては、Gemini APIキーの不正利用を防ぐ管理と監視の実践 で扱ったような発行元側でのローテーションと利用状況の確認が必要になる。

5. ログを見る——ただし残っていない可能性がある

第一報の確認項目には「心当たりのないログインやメール送信等が発生していないか」が含まれている。これに対応する手段は2つある。

ひとつはコントロールパネルだ。さくらのレンタルサーバでは、サーバーコントロールパネルの「セキュリティ」→「サーバーログイン履歴」からログイン履歴を確認できる。SSHが使えないライトプランでも参照できる経路なので、プランを問わず最初に見るべき場所になる。なお公式ヘルプは、メールアドレスとパスワードでログインするとメール設定しか表示されず履歴に到達できない、と注意している。初期ドメインまたは追加ドメインでログインする必要がある。

もうひとつがアクセスログだが、ここには重要な前提がある。さくらのレンタルサーバのアクセスログは、利用者が「保存する」設定にしていなければ蓄積されない。 保存設定をしている場合は /home/アカウント名/log/access_log_[日付] に置かれ、当日分はテキスト、前日以前はgzip圧縮される。保存期間は最大24か月まで選べる。

# ログが実際に存在するか（保存設定をしていなければ空か存在しない）
ls -lT ~/log/ 2>/dev/null | head -20

# 当日分（非圧縮）— 認証まわりへのPOSTを抜く
grep -h '"POST ' ~/log/access_log_* 2>/dev/null | grep -v "\.gz" | tail -50

# 前日以前（gzip圧縮済み）— BSDでは zcat ではなく zgrep / gzcat を使う
zgrep -h "wp-login\|xmlrpc\|/uploads/.*\.php" ~/log/access_log_*.gz 2>/dev/null | tail -50

# アクセス元IPの多い順（awk / sort / uniq は BSD でもそのまま使える）
zgrep -h "" ~/log/access_log_*.gz 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

ログについては、「見た結果なにも無かった」と「そもそも記録が無い」を混同しないことが重要だ。アクセスログを保存する設定にしていなければ、侵害の痕跡が無いのではなく観測手段が無い。さらに公式ヘルプは、ディスク使用量が80%を超えるとログの保存機能が停止すると明記している。設定していたつもりでも、容量逼迫で途中から記録が止まっているケースがありうる。

影響範囲マトリクス——自分はどこまで確認すべきか

ここまでの確認手順は、利用形態によって重みが変わる。第二報で会員情報の軸が加わったため、契約しているサービスを問わず全員に共通する行がひとつ増えている点に注意してほしい。影響を受ける可能性の欄は公表時点で判明している情報に基づく整理であり、調査継続中である点は全行に共通する。

最終行が、第一報だけを読んでいたときとの最大の差になる。提供環境の欄が「確認されていない」でも、会員情報の欄は全員共通で埋まる。 この2列を1列に潰して読んだことが、「自分は対象外」という誤読の正体だった。

「通信の秘密」と「個人データ」——1つの事案に走る2つのクロックと、2本の続報チャネル

第一報には次の一文がある——「攻撃者がお客さま情報および通信の秘密に該当する情報へアクセス可能な状態であったことを確認しております」。

「通信の秘密」は日常語ではなく、電気通信事業法上の法的概念だ。さくらインターネットは電気通信事業者であり、この語を使った時点で、個人情報保護法とは別系統の報告義務が発生する。実際、第一報の対応欄には「総務省、個人情報保護委員会等の関係機関への報告および情報共有」と、2つの官庁が併記されている。

総務省の手引きは、この重複を明示的に注意している。「一の漏えい等事案が、『通信の秘密の漏えい』『特定利用者情報の漏えい』『個人データの漏えい等』の複数に該当する場合、電気通信事業者はそれぞれ所要の報告を行う必要があります」。1つのインシデントに対して、様式も期限も別々の報告が並走するということだ。

注目すべきは期限が揃っていないことだ。通信の秘密の詳報は30日以内で固定される。一方、個人データの確報は原則30日だが、個人情報保護法施行規則第7条第3号——「不正の目的をもって行われたおそれがある行為による漏えい等」——に該当する場合は60日以内に延びる。不正アクセスはまさにこの3号の典型例として挙げられている類型だ。つまり同じ1つの事案について、（両トラックの認知日が同じであれば）通信の秘密のトラックのほうが先に期限を迎える構造になっている。

なお3本目の「特定利用者情報の漏えい」は、指定を受けた指定電気通信事業者のみが対象となる。さくらインターネットがこの指定を受けているかどうかは本記事では確認できていないため、該当するかは判断を保留する。提出先は、いずれのトラックでも「本社所在地を管轄する総合通信局等」と定められている。同社の本社は大阪市北区にあるため、窓口は近畿総合通信局が該当することになる。個人データの漏えい等についても、電気通信事業者の場合は個人情報保護委員会の権限が総務省へ委任されているため、提出先は個人情報保護委員会ではなく同じく総合通信局等になる。

続報は2本のチャネルに分かれて出る

もうひとつ、第二報で新たに観測できるようになったことがある。さくらインターネットは東京証券取引所に上場している（コード番号3778）。8月19日には報道機関・顧客向けのニュースリリースとは別に、適時開示が行われた。

この適時開示には、顧客向けリリースには書かれていない一文がある——「なお、本件が2027年3月期連結業績に与える影響等については現在精査中であり、開示すべき事項が生じた場合は速やかにお知らせいたします」。業績影響という観点での続報が、別途予告されている形だ。

・顧客向けチャネル：ニュースリリース（sakura.ad.jp/corporate/information/newsreleases/）とFAQページ。影響範囲・対象者・利用者が取るべき対応が出る
・投資家向けチャネル：適時開示。業績への影響、対応費用、再発防止策の位置づけが出る
・両者は内容が一致しない：第二報の適時開示は販売管理システムを「契約者情報および請求先情報等を管理するシステム」と表記しており、顧客向けリリースの「契約情報等を管理するシステム」より具体的だった

事案の全体像を追うなら、顧客向けページだけを見ていると取りこぼす。片方にしか書かれていない語がある、というのが今回すでに1件確認できている。

続報で見るべき点と、精度が上がる便乗フィッシング

第二報は「新たに公表すべき事実が判明した場合には速やかにお知らせいたします」で締めくくられている。公式FAQも「現時点で追加公表の時期や頻度は決まっておりません」としており、続報は前提だがスケジュールは示されていない。次の発表で確認すべき点を整理しておく。

・1,360,563が動くか：現在は「対象となる可能性のある」総数であり、確定値ではない。絞り込まれる方向にも、広がる方向にも動きうる
・外部持出しの有無：現在は「確認されておりません」。フォレンジック調査の結果で変わりうる、最も重要な未確定項目
・販売管理システムとレンタルサーバの関連性：同一の侵入に由来するのか別々の事象なのかが未確定
・侵入経路と発生時期：完全に未公表。「8月9日以前」がどこまで遡るかが分かると、被害期間の見積もりが初めて可能になる
・583という数字が動くか：影響を受けた可能性のある環境について調査継続中と注記されている
・個別通知の進捗：対象者への個別連絡はメールと公式サイトのみと明言されている
・業績への影響：2027年3月期連結業績への影響は「現在精査中」。適時開示側で続報が出る

そして利用者側で今すぐ効くのは、便乗フィッシングへの警戒だ。第一報は「本件に便乗したフィッシングメールや不審な連絡にも十分ご注意ください」と明記し、続けて「当社から、パスワード、認証情報、クレジットカード情報等をメールや電話でお伺いすることはありません」と断言している。

ここで第二報が持つ意味は大きい。漏えいした可能性のある情報の粒度が上がったからだ。会員ID、会社名、部署名、住所、氏名、電話番号、メールアドレス、生年月日、性別、FAX番号、契約サービス、契約期間、請求金額——この組み合わせは、フィッシングの説得力を大きく引き上げる材料になる。「お客様の会員IDは◯◯、ご契約中の△△プランについて、今月のご請求額¥□□の決済に問題が生じています」という文面が成立してしまう。自分の契約内容を正確に言い当ててくるメールや電話を、それだけで正規のものと判断できない状態になった、と考えるべきだ。

最後に、この事案から持ち帰れる一般則を2つ挙げておく。ひとつは、共有ホスティングを使うということは自分の環境の安全性の一部を事業者の管理層に委ねるということだ。委ねた部分は利用者側の努力では固くできない。だからこそ、委ねなくて済むもの——サーバー上のファイルに平文で置いた外部サービスの鍵——を減らしておくことの価値が上がる。

もうひとつは、「影響なし」の一覧を読むときは、それが何の軸で書かれているかを確認することだ。今回、第一報の一覧は提供環境の軸で書かれていた。会員情報の軸は、第二報が出るまで誰も言及していなかった。事業者が嘘をついたわけではない。読み手が2つの軸を1つに潰しただけだ。他社のインシデント発表を読むときにも、同じ形の見落としは起こりうる。

参照ソース

・当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて（さくらインターネット公式・2026年8月17日／第一報）
・当社システムへの不正アクセスに関するお知らせ（第二報）（さくらインターネット公式・2026年8月19日）
・「当社システムへの不正アクセスに関するお知らせ」について（適時開示PDF・2026年8月19日）
・当社システムへの不正アクセスに関するよくあるご質問（さくらインターネット公式FAQ）
・会員認証における2要素認証必須化のお知らせ｜さくらのサポート情報
・サーバーコントロールパネルの2要素認証の設定・解除をしたい｜さくらのサポート情報
・基本仕様を知りたい（さくらのレンタルサーバ）｜さくらのサポート情報
・ログイン履歴を確認したい｜さくらのサポート情報
・アクセスログを設定し管理したい（Webalizer）｜さくらのサポート情報
・電気通信事業における通信の秘密の漏えい事案の報告（総務省）
・電気通信業における「通信の秘密の漏えい」・「特定利用者情報の漏えい」・「個人データの漏えい等」報告の手続（総務省 関東総合通信局）
・電気通信業における個人データの漏えい等事案の報告（総務省）
・漏えい等の対応とお役立ち資料（個人情報保護委員会）
・gzip(1) — FreeBSD Manual Pages（zcat がgzipのエイリアスである根拠）

</content> </invoke>