さくらインターネットの不正アクセスと最大136万件｜管理基盤経由の侵害と利用者の点検手順

さくらインターネットが2026年8月から9月にかけて公表した不正アクセスは、「さくらのレンタルサーバ」の951アカウントへの不正アクセスと、契約情報を管理する販売管理システムの最大1,360,563アカウントという、性質の異なる二つの事象が並んでいます。9月10日の第三報で調査は完了し、販売管理システムへの不正アクセスは2023年4月から2026年3月までの約3年間に及んでいたと判明しました。預けている側が読み取るべきなのは件数ではなく「どの層が破られ、自分の環境に何が残っているか」です。公表された事実を時系列で整理し、最初の一週間で回す点検手順と、技術詳細が公表されない前提で設計へ反映できる打ち手を実装の解像度でまとめます（2026年10月2日時点）。

まとめ：さくらインターネットの不正アクセスで確定した事実と利用者の打ち手

第三報で確定したのは、レンタルサーバの一部サーバーへの不正アクセスとマルウェア設置（951アカウント）、販売管理システムのデータベースへの不正アクセス（最大1,360,563アカウント、うち30アカウントはハッシュ化された会員IDパスワードが閲覧された可能性）の二つです。両事象の関連を示す明確な根拠は見つからず、データの外部持ち出しを裏付ける明確な事実も、二次被害も確認されていません。攻撃コードや認証方式などの技術的な詳細は、模倣攻撃防止のため公表しないと明記されました。

預けた側の打ち手は順序で決まります。先にログを保全し、次にサーバー内の改ざんと不審ファイルの痕跡を確認し、それから認証情報を入れ替える。この順序を崩すと、調査に必要な証跡を自分の手で消してしまいます。個別案内を受けた人は、まず案内どおりにパスワードを変更してください。

公表で確定した経緯と影響範囲｜8月9日の検知から第三報までの時系列

第一報から第三報までの発表と、それぞれで変わった対象件数の推移

同社の発表は3本です。最新は9月10日の第三報で、ここで一連の調査が完了したとされています。

第一報は、当社管理環境を経由して顧客環境へ不正アクセスがあり、一部サーバーにマルウェアが置かれたと公表しました。第二報で販売管理システムへの不正アクセスの可能性が加わり、第三報で最終的な影響範囲、原因調査の結果、再発防止策が示されています。

レンタルサーバの対象が951アカウントへ増えた経緯と追加368件の扱い

第三報では、第一報の583アカウントに368アカウントが加わり、合計951アカウントになりました。追加分は、発生時期や経路を含めて583アカウントへの不正アクセスと関連する明確な根拠が確認されなかったものの、影響の可能性を否定できないとして同じ対応をとった、と説明されています。調査の過程では、2025年7月以降のものと考えられる不審な活動の痕跡も見つかりました。同社は継続的な侵害ではないと確認した一方、記録の制約で本件との同一性や侵入経路を客観的に確認するには至らなかったとしています。

利用者の立場では、ログを遡る起点は公表日でも検知日の8月9日でもありません。レンタルサーバ側は少なくとも2025年7月、販売管理システム側は2023年4月まで遡る必要があります。共用ホスティングのログがそこまで残っていることはまれなので、残っている範囲を確保すること自体が最初の作業になります。

販売管理システムの侵害期間が約3年に及んだことが示す検知の空白

第三報は、販売管理システムへの不正アクセスが2023年4月以降、2026年3月までの間に発生していたと特定しました。侵害は8月の検知より5か月前に終わっており、約3年間、気付かれないままだったことになります。販売管理システムはサービスの提供環境とは別のシステムで、レンタルサーバの調査を進める過程で見つかりました。

この期間の長さは、侵入を防ぐ対策より、侵入に気付く仕組みの不足を示しています。同社も今後の施策に「セキュリティに関するログの取得範囲、保管期間および分析体制の見直し」を挙げました。自社の基盤でも、ログの保管期間が侵害の発覚までの期間より短ければ、後から何も追えません。

データの外部持ち出しが確認されていないという公表表現の読み方と判断

第三報の表現は「データが外部へ持ち出されたことを裏付ける明確な事実は確認されておりません」です。持ち出しがなかったという意味ではありません。立証には通信ログや転送の痕跡が要り、保存期間を過ぎていたり正規の経路に紛れていたりすると、後から証明できません。同社はダークウェブ上の公開、アカウントの不正利用、金銭的被害、本件の情報を使ったフィッシングのいずれも確認されていないとし、監視を続けています。利用者側の判断は、持ち出しがあった前提へ寄せるのが安全側です。

951アカウントと136万アカウントで侵害の性質がまったく違う理由

レンタルサーバ側は顧客領域に置いたデータそのものが読まれた可能性

レンタルサーバの951アカウントでは、顧客領域内の利用者識別子、メールデータ、ウェブサイトのデータ、ログ情報などが対象に挙げられています。問題になるのは、ソースコードや設定ファイルがそのまま読まれた可能性です。WordPressのwp-config.phpや環境変数ファイルには、データベースの接続情報や外部APIのキーが平文で置かれていることが多く、読まれていれば影響は同社の外へ伸びます。該当した場合は、そこから参照する外部サービスの資格情報まで棚卸ししてください。

販売管理システム側の項目と、平文で保存されていた初期パスワード

販売管理システムの対象項目は、会員ID、会社名、部署名、住所、氏名、電話番号、メールアドレス、生年月日、性別、契約サービス、契約期間、請求金額などです。同社はクレジットカード情報を保持しておらず、入力画面の改ざんも確認されていないため、カード番号の漏えいの恐れはないとしています。

第三報で重いのは、販売管理システムに「さくらのレンタルサーバ」の一部の初期サーバーパスワードと、「さくらのVPS」の一部の管理者初期パスワードが保存されていたことです。これらは30アカウントのハッシュ化された会員IDパスワードとは異なり、ハッシュ化されていませんでした。同社は、初期パスワードが今も使われていたレンタルサーバの契約についてはサーバーパスワードを同社側で変更し、VPSの対象者には初期パスワードのままなら変更するよう個別に依頼しています。初期パスワードから既に変更していれば、現在のパスワードは保存されていた情報と異なるため、本件による不正ログインのリスクはないと説明されています。

件数の大きさよりも項目の組み合わせで被害の重さを判断する視点

漏えいの重さは件数で語られがちですが、実務では項目の組み合わせで測るほうが判断を誤りません。同社も、1,360,563アカウントは保存されていた項目を示すもので、第三者が実際に閲覧・取得したことを示すものではないと注記しています。

最後の行が、本件で最も危険な組み合わせです。初期パスワードを変えずに運用していたサーバーやVPSは、閲覧された情報だけでログインできた状態でした。

管理基盤を経由して顧客環境へ届いた構図がホスティング利用に突きつけるもの

共通の管理基盤を持つ事業者では権限の集約点が単一障害点になる

技術的に重いのは、第三者が同社の管理環境を経由して顧客環境へ不正アクセスしていたとされる点です（第一報）。ホスティングやSaaSの事業者は、多数の顧客環境へ横断的に手を入れられる管理基盤を必ず持つ構造です。運用の効率と引き換えに、その基盤は権限の集約点になり、破られた瞬間に顧客側の防御を飛び越えます。同社が実施済みの再発防止策の筆頭に「管理者権限およびアクセス権限の総点検と厳格化」と「重要システムへの接続経路の見直し」を置いたのも、この構図に対応したものと読めます。

この構図は、購入者情報が外部送信されたショップサーブの情報漏えいや、予約管理のデータベースが侵害されたPeakManagerの事案と同じ系統です。会員の運転免許証画像が退会者の分まで取得された型はタイムズカーの不正アクセスと約660万件の流出で、画像アップロードサーバーを起点に利用者DBまで届いた型はGyazoの不正アクセスと2,362万件の流出で扱っています。

テナント越えを前提に置いた分離設計と、踏み台経路を遮断する考え方

マルチテナントの基盤を設計する側から見ると、対策は分離の粒度と経路の遮断に集約されます。管理基盤の認証を利用者向けと分け、運用担当の操作は踏み台を経由させ、その踏み台からテナントへ届く経路を用途ごとに限定する。テナント横断の一括操作は常時使える状態に置かず、承認を挟んで一時的に権限を付与する形へ寄せると、破られたときの到達範囲が狭まります。もう一つの教訓は、販売管理システムに平文の初期パスワードを残さないことです。発行した初期値は、利用者へ渡した時点で消すか、初回ログインで変更を強制する設計にします。運用担当者のアカウントがVPN機器の脆弱性を突かれて使われた例として、デジタル庁GSSの不正アクセスと約24.6万件の漏えいの可能性も同じ構図をたどっています。

検知の面では、短時間に多数のテナントへ触れる操作を異常の候補として扱います。相関分析にはSIEMのような基盤が要るため、まず横断操作の記録が残っているかを確認してください。

利用者側が責任共有モデルのどこまでを自力で守れるのかという線引き

共用ホスティングでは、OSやミドルウェアの管理は事業者側にあり、利用者が触れるのはアプリケーションと自分のデータの範囲です。事業者の管理面が起点になった場合、利用者が自力で防げた範囲はほとんどありません。利用者に残るのは「破られた後に被害を広げない設計」だと割り切るのが実務的です。設定ファイルへ平文で置く資格情報を減らす、外部サービスの鍵に権限とIP制限を付ける、バックアップを同一事業者の同一環境だけに置かない。侵入自体は止まりませんが、読まれた後の被害範囲は縮みます。事業者の基盤がランサムウェアで止まり、データの復元を利用者のバックアップに頼る形になった事例はIDCFクラウドの不正アクセスとランサムウェア被害で、別の事業者へバックアップを逃がす手順とあわせて解説しています。

預けた側が最初の一週間で終わらせておきたい点検手順と痕跡の探し方

ログの保全を先に済ませてから調査へ入るという順序を崩さない理由

最初に手を付けるのはログの保全です。共用ホスティングのアクセスログは保存期間が短く、上書きで消えていきます。調査の前に、Webサーバーのアクセスログとエラーログ、FTPやSFTPの接続履歴、メールの送信ログを日付付きで手元へ退避してください。サーバー上でファイルを開いたり削除したりする前に退避を終える順序が肝心です。退避後の読み方は不正アクセスのログ確認・解析方法の手順が使えます。管理画面やFTPへの成功ログイン、深夜帯の接続、見慣れない国からの接続を抽出するところから当たりを付けます。

サーバー内に残った改ざんと不審なファイルの痕跡をコマンドで洗い出す

次にファイルの痕跡を見ます。公開ディレクトリ配下で更新日時が想定と合わないPHPファイル、拡張子が画像なのに中身がコードのファイル、難読化された関数呼び出しはWebシェルの典型です。SSHで接続できる環境なら、次のコマンドで候補を一覧にできます。いずれも読み取りだけで、ファイルを変更・削除しません。

# 前提: SSH接続できるレンタルサーバ（FreeBSD／Linuxいずれのfind・grepでも動く書式）
# 公開ディレクトリへ移動（さくらのレンタルサーバの既定は ~/www。環境に合わせて変える）
cd ~/www

# 1) 2025年7月以降に更新されたPHPファイルを一覧にする（日付は調査の起点に合わせる）
find . -type f -name "*.php" -newermt "2025-07-01" -ls > ~/audit_php_mtime.txt

# 2) 画像の拡張子なのにPHPの開始タグを含むファイル
grep -rla --include="*.jpg" --include="*.png" --include="*.gif" "<?php" . > ~/audit_fake_images.txt

# 3) 難読化の典型パターン（誤検知もあるので一覧を目で確かめる）
grep -rnE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(" --include="*.php" . > ~/audit_obfuscated.txt

# 4) 登録した覚えのないcronジョブとSSH公開鍵
crontab -l
cat ~/.ssh/authorized_keys

結果はホームディレクトリ直下のテキストに保存されるため、公開ディレクトリには出ません。更新日時は攻撃者が書き換えられるので、1の結果が空でも安全とは言い切れません。見つかったファイルはすぐ消さず、コピーを退避してから同社の案内と照合します。あわせて、.htaccessへ追記されたリダイレクトと、データベースに増えている管理権限アカウントも確認します。

個別案内の内容に沿って回すパスワードと認証情報のローテーション

保全と痕跡確認を終えたら、認証情報を入れ替えます。第三報で同社が個別に案内した対象は、影響を受けた可能性があるレンタルサーバの利用者（サーバーパスワードとメールパスワードの変更が必要と判断した人を含む）、初期パスワードの確認と変更が必要なVPSの利用者、販売管理システムの会員情報が影響を受けた可能性がある利用者の3種類です。レンタルサーバで同社がパスワードを変更した人は、会員メニューにログインして自分で決めたパスワードへ変更するよう求められています。手順は同社の本件FAQにまとまっています。

通知を待たずに回してよいのは、FTPやSFTPの資格情報、データベースの接続ユーザー、アプリケーションの管理者アカウント、設定ファイル内の外部APIキーです。いずれも利用者の手元で完結します。他サービスと同じ文字列を使っているなら、そちらの変更も並行して進めてください。遮断すべきは一点ではなく使い回しの連鎖です。

ハッシュ化されたパスワードが閲覧された場合のリスクの見積もり方

ハッシュ方式とソルトの有無で解読の可能性がどこまで変わるのか

ハッシュ化されているから安全、と単純化はできません。bcryptやArgon2のように計算コストを上げた方式で利用者ごとのソルトが付いていれば、総当たりの費用は現実的でない水準まで上がります。MD5やSHA-1でソルトが無ければ、既製の対応表と照合するだけで短い文字列は復元されえます。今回、方式は認証方式の詳細として公表されていません。対象の30アカウントに入っていた人のうち、短く辞書に載る語を使っていた人は、漏えいと同等に扱って変更するのが実務的です。

使い回しがある場合に他サービスへ波及する経路と、遮断する優先度

ハッシュが破られたときの実害は、同じ文字列を使った他サービスへの侵入として現れます。遮断の優先度は、決済や送金が絡むもの、パスワード再設定の受け口になるメールアカウント、クラウドの管理コンソール、SNSやドメイン管理の順で組みます。

パスワードの変更だけでは残ってしまうセッションとトークンへの対処

見落とされやすいのが、変更後も生きているセッションと発行済みトークンです。多くのアプリケーションはパスワードを変えても既存のセッションを自動では切りません。管理画面に「他の端末からログアウト」に相当する機能があれば実行し、無ければセッションの署名鍵を入れ替えて全件を無効化します。APIキーやアクセストークンも、発行済みの一覧を出し、用途が説明できないものから失効させてください。ここまで含めて初めてローテーションが完了します。

技術詳細が公表されない前提で自社の設計に反映できる打ち手の優先順位

侵入経路が公表されなくても自社で先に潰せる入口を洗い出す順序

第三報は、侵入経路とシステム構成の技術的な詳細を公表しないと明記しました。経路の公表を待つ意味は、もうありません。侵害の入口は、外部公開された管理面、資格情報の窃取、未修正の脆弱性、正規の運用経路の悪用という限られた類型に収まります。自社について、この四つのどれが開いているかを棚卸しすれば手を動かせます。順序は、外から見える面を減らす作業が先です。監視から入ると、開いたままの入口を見張り続けることになり、費用の割に効きません。

管理画面とAPIキーの露出を減らす設計変更で効果が出やすい箇所

効果が出やすいのは、管理画面へのアクセス元を制限すること、公開領域から設定ファイルを外へ出すこと、APIキーに権限の範囲と接続元の制限を付けることの三つです。いずれも実装量が小さく、破られた後の到達範囲を狭めます。共用ホスティングでも、.htaccessによるIP制限やBasic認証の併用は利用可能です。実装の穴を体系的に潰すなら、外部の脆弱性診断で入口を一度洗い出しておくと、思い込みで抜けた箇所が見つかります。診断は年次の行事ではなく、公開面を変えたタイミングで回すほうが費用に見合います。

全サーバー再構築の案内が来たときに利用者側で確かめておく設定の継承

同社は今後の施策として「さくらのレンタルサーバ」の全サーバーの再構築によるクリーンナップを挙げています。日程や利用者側の作業の有無は、2026年10月2日時点で第三報には書かれていません。案内が来たら、再構築後にcronの設定、.htaccess、PHPのバージョン指定、SSHの公開鍵が引き継がれているかを確かめてください。痕跡確認で退避したファイル一覧は、再構築前後の差分を取る基準にも使えます。

漏えい報告義務と、委託先が侵害されたときの責任分界を整理する視点

委託先が侵害された場合でも自社の側に残る報告義務のおおよその範囲

自社サイトの個人データをホスティング事業者へ置いている場合、事業者が個人データの取扱いの委託先にあたるかは契約と取扱いの実態で決まります。委託先にあたる場合、漏えいの報告義務は委託元と委託先の双方が負うのが原則で、委託先が委託元へ通知したときは委託先の報告義務が免除される整理です（個人情報保護法26条1項ただし書）。利用者側は、事業者が公表したから自社は無関係、とはなりません。判断の前提となる定義は個人情報保護法の解説を、2026年7月公布の改正は令和8年改正のポイントを参照してください。

速報と確報の期限を、実務の体制へ落とし込むときの現実的な設計

報告は二段階です。個人情報保護委員会の案内では、速報は事態を知った時点から速やかに（概ね3〜5日以内）、確報は30日以内、不正の目的をもって行われたおそれがある漏えいなら60日以内とされています。不正アクセス起因の事案は後者にあたります。体制側で決めておくのは、誰が「事態を知った時点」と判断するか、誰が委員会への提出を担うか、外部調査の見積もりと発注を誰が通すか、の三点です。報告の4類型と実務は個人情報保護委員会への報告義務の解説にまとめています。顧客への通知では、調査が終わらない段階で原因を断定したり被害がないと言い切ったりせず、便乗メール対策として本文にリンクを載せない書き方が安全です。

便乗フィッシングと二次被害を止めるための通知設計と監視の実装

事案に便乗した偽メールが届く前提で送信ドメイン認証を固めておく

大規模な事案の後は、事業者や取引先を装ったメールが増えます。同社も第三報で便乗したフィッシングメール、不審な電話、SMSへの注意を呼びかけ、電話でパスワードやクレジットカード情報を尋ねることはないと明記しました。自社が装われる側に回ったときの防御は、SPFとDKIMを正しく設定し、DMARCのポリシーを段階的に引き上げることです。アカウント侵害からなりすまし送信へ発展した例として、講談社の個人情報流出が参考になります。

問い合わせの返答を待つ間に社内で先に進めておく作業の切り分け

事業者側の窓口は、事案の直後は返答に時間がかかりがちです。切り分けの目安は、自社の環境内で完結する作業を先に回し、事業者の記録が要る確認だけを待ちに置く線です。ログの保全、痕跡の確認、資格情報の入れ替えは前者、侵害の有無の最終確認や事業者側のアクセス記録の開示は後者にあたります。自社だけで痕跡の判断が付かないときや、公開面の棚卸しを通したいときは、脆弱性診断・セキュリティ診断で外形からの入口を洗い出す方法があります。

よくある質問

さくらインターネットの不正アクセスについて、2026年10月2日時点の公表内容で答えます。

個別の案内が届いていなければ対応は不要でしょうか？

同社は対象者に電子メール等で個別に案内しており、登録情報の不備で連絡できない人には第三報の公表をもって代えるとしています。案内が無い場合でも、契約時の初期パスワードをそのまま使っているサーバーやVPSがあれば変更してください。ログの保全と痕跡の確認、使い回しているパスワードの変更は、自社の環境内で完結するので先に進めて損はありません。

クレジットカード情報が対象外なら被害は軽いと考えてよいですか？

同社はカード情報を保持しておらず、カード番号の漏えいの恐れはないとしています。ただし氏名や会社名、契約サービス、請求金額が揃えば、請求書や更新案内を装ったメールの材料となる情報です。金銭被害の経路がカードから詐取へ移ったと考えるほうが実態に合います。

ハッシュ化されていれば、パスワードは変えなくても大丈夫ですか？

ハッシュ化された会員IDパスワードが閲覧された可能性があるのは30アカウントで、方式やソルトの有無は公表されていません。該当する人は、短い文字列や辞書に載る語なら変更してください。別に、販売管理システムには平文の初期サーバーパスワードとVPSの初期rootパスワードが保存されていました。初期値のまま使っているなら、ハッシュの有無に関係なく直ちに変更が必要です。

侵入経路は今後公表されますか？

第三報は、具体的な攻撃コード、IPアドレス、システムとネットワークの構成、認証方式などの技術的な詳細は、セキュリティ保護と模倣攻撃防止の観点から公表しないとしています。経路の公表を待たず、外部公開された管理面、資格情報、未修正の脆弱性、正規経路の悪用という類型で自社を棚卸しし、入口を絞る作業を進めてください。

自社の顧客データが含まれる場合、報告は誰が出すのですか？

ホスティング事業者が個人データの取扱いの委託先にあたる場合、報告義務は委託元と委託先の双方にあり、委託先が委託元へ通知すれば委託先側は免除される整理です。自社の顧客データが含まれるなら、個人情報保護委員会への報告と本人への通知は自社の責任で進めます。

関連記事

• ショップサーブの情報漏えい最大885万件｜サーバー侵害とデータ外部送信の技術解説
• 講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説
• PeakManagerの個人情報漏えい約3300万件｜DB侵害とデータ削除の技術解説
• 不正アクセスのログ確認・解析方法｜痕跡の調べ方を実践解説
• SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説
• 個人情報保護法改正とは？2026年7月公布の令和8年改正で企業対応はこう変わる