さくらのレンタルサーバ不正アクセスとは｜583アカウントの意味と、利用者が今すぐ確認すべきこと

さくらのレンタルサーバ不正アクセス——さくらインターネットが2026年8月17日に公表したこの事案は、報道の見出しだけを追うと「583アカウントが不正ログインされた」という数字の話に見える。だが公式発表を読むと、この事案の性質を決めているのは583という数ではなく、第三者が「当社管理環境を経由して」顧客環境に到達したという一文のほうだ。利用者が自分の側で鍵を固くしていても防げない層で起きている。本記事では公式発表と総務省・個人情報保護委員会の一次資料だけを使って、①この数字が何を数えたものなのか、②影響なしと書かれたサービスとの境界はどこか、③FreeBSDである「さくらのレンタルサーバ」で実際に通る確認コマンドは何か、④この1件に対して並走している2つの報告義務は何か、を整理する。

開発者を狙う供給網まわりの攻撃と防御の全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

さくらのレンタルサーバ不正アクセスの時系列——検知から公表まで8日

公式発表から日付を拾うと、確定しているのは2点しかない。2026年8月9日（日）に同社が管理するサーバー環境で異常を検知し調査を開始したこと、そして8月17日（月）に公表したことだ。この間隔は8日である。

その間に何が判明したかは発表に順序立てて書かれている。異常検知から始まった調査によって、第三者が同社管理環境を経由して「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスを行っていたことが確認された。さらに一部のサーバーにマルウェアが設置されていたこと、攻撃者が顧客情報および通信の秘密に該当する情報へアクセス可能な状態であったことが確認されている。同社は確認後直ちに認証情報の無効化とアクセス遮断、その他の封じ込め対応を実施したと記載している。

ここで注意しておきたいのは、8月9日は「異常を検知した日」であって、「不正アクセスが始まった日」ではないという点だ。発表は発生時期についても調査中としている。攻撃者がいつから同社管理環境にいたのかは、現時点で公表されていない。時系列を読むときにこの2つを混同すると、被害期間を実際より短く見積もることになる。

・確定している日付：8月9日（異常検知・調査開始）、8月17日（公表）
・確定していない日付：侵入の開始時期、マルウェアが設置された時期、顧客環境へ到達した時期
・判明済みの事実：管理環境経由の侵入、マルウェア設置、583アカウントへの不正ログイン、通信の秘密該当情報へのアクセス可能状態

「当社管理環境を経由して」——583アカウントはパスワードが弱かった話ではない

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

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

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

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

同時に、これは「利用者にできることは何もない」という意味でもない。攻撃者が到達したあとに何を置いていったか——マルウェア、追加された管理者アカウント、書き換えられた設定——は利用者側の領域に残る。設置されたマルウェアの除去は同社が実施しているが、公式発表が利用者に対して「身に覚えのないファイルや管理者アカウントが追加されていないか」「ウェブサイトやアプリケーションに不審な変更が行われていないか」の確認を求めているのは、この残留物のためだ。後述する確認コマンドは、まさにこの層を見るためのものになる。

影響が確認されていないサービスの境界線——VPS・クラウド・高火力PHYはなぜ分かれたか

発表は、影響が確認されていないサービスを名指しで4つ挙げている。さくらのVPS、さくらのクラウド、さくらの専用サーバ PHY、高火力 PHY だ。ここには同社のGPUクラウド／AI基盤事業である高火力 PHY も含まれている。

この境界には技術的な読み筋がある。挙げられた4サービスはいずれも、利用者が自分でOSを持つタイプのサービスだ。VPSとクラウドは仮想マシンを、専用サーバ PHY と高火力 PHY は物理サーバーを、それぞれ利用者が管理する。事業者の管理層が触るのは、その外側——ハイパーバイザー、電源、ネットワーク、コントロールパネル——であって、OSの内側に日常的に手を入れる仕組みは持たない。

対してレンタルサーバーは共有型で、OSは事業者のものだ。利用者は与えられたディレクトリとデータベースの中で作業する。プラン変更もデータベース作成も、事業者の自動化が利用者の領域に踏み込んで実行する。事業者の管理層と顧客データの距離が、構造的に近い。

ただし、ここで踏み込みすぎないでおきたい。この読み筋は「なぜレンタルサーバーだけが影響を受けたのか」の説明としてはもっともらしいが、同社は侵入経路を公表していない。管理層の性質の違いが今回の分岐の原因だと断定することはできないし、発表もそう書いていない。確実に言えるのは次の2点だ。

・発表時点で影響が確認されているのは「さくらのレンタルサーバ」のみである
・上記4サービスは「現時点において影響は確認されておりません」であり、これは調査完了の宣言ではない。同じ発表に「その他サービスについても必要に応じて影響有無の確認を進めております」と併記されている

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

ここからが、公式発表を読むだけでは埋まらない部分だ。発表の「お客さまへのお願い」は散文で書かれている——「身に覚えのないファイルや管理者アカウントが追加されていないか」「ウェブサイトやアプリケーションに不審な変更が行われていないか」「心当たりのないログインやメール送信等が発生していないか」。何を見るべきかは分かるが、どう見るかは書かれていない。

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

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

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

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 -30 -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行が、この事案でとくに重要になる。発表は漏えいの可能性がある情報として「顧客領域内に保存された情報」を挙げている。サーバー上のファイルに平文で書かれた認証情報は、まさにこの「顧客領域内に保存された情報」だ。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%を超えるとログの保存機能が停止すると明記している。設定していたつもりでも、容量逼迫で途中から記録が止まっているケースがありうる。ログが薄いこと自体を、今後に向けた設定の見直し対象として扱うのが妥当だ。

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

ここまでの確認手順は、利用形態によって重みが変わる。公式発表が挙げた確認項目（ファイル・管理者アカウント・不審な変更・心当たりのないログインやメール送信）を、実際の使われ方に対応させると次のようになる。影響を受ける可能性の欄は、発表時点で判明している情報に基づく整理であり、調査継続中である点は全行に共通する。

この表で一貫しているのは、サーバーのログインパスワードを変えても無効化されないもの——サーバー上のファイルに平文で置かれた外部サービスの鍵——が、どの行でも再発行対象に入る点だ。顧客領域内に保存された情報が閲覧された可能性がある、という発表の一文が効いてくるのはここになる。

制限された3機能の共通点——読み取れることと、読み取れないこと

発表の「現在実施している対応」に、ひとつ具体的な記載がある。「さくらのレンタルサーバ」のデータベースアップグレード機能、プラン変更、移行ツールなどの一部機能の制限だ。

この3つには機能上の共通点がある。いずれも利用者の権限では完結せず、事業者側の自動化が顧客データを読み書きしたり別の場所へ移したりする操作だ。データベースアップグレードはDBの中身を読んで新バージョンへ書き戻す。プラン変更は収容先を変える。移行ツールはデータを別環境へ複製する。通常の閲覧や更新と違い、顧客領域の境界をまたいで動く系統の機能が並んでいる。

封じ込めの一般論として、侵害の可能性がある経路や、調査中に状態を変えられると困る機能を止めるのは定石だ。上記3機能がその条件に当てはまることは、機能の性質から言える。

ただし、ここから侵入経路を逆算することはできない。 同社は侵入経路を調査中と明言しており、経路を特定した旨の発表はしていない。機能が制限された理由は、その機能が侵入に使われたからかもしれないし、フォレンジック調査中にデータが動くのを避けるためかもしれないし、単に安全側に倒した予防措置かもしれない。発表はどれとも書いていない。本記事はこの点について推定を置かない。

・事実：データベースアップグレード機能・プラン変更・移行ツールなどが制限された
・機能から言えること：いずれも事業者側の自動化が顧客データに触れる操作である
・言えないこと：これらが侵入経路だったかどうか。制限の理由。公式は経路を調査中としている

「通信の秘密」と「個人データ」は別レジーム——1つの事案に走る2つのクロック

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

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

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

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

つまり同じ1つの事案について、（両トラックの認知日が同じであれば）通信の秘密のトラックのほうが先に期限を迎える構造になっている。詳細な続報がどのタイミングで出るかを考えるうえで、この非対称性は実務的な意味を持つ。

なお3本目の「特定利用者情報の漏えい」は、利用者の利益に及ぼす影響が大きい電気通信役務を提供する者として指定された指定電気通信事業者のみが対象となる。さくらインターネットがこの指定を受けているかどうかは本記事では確認できていないため、該当するかは判断を保留する。

なお提出先は、いずれのトラックでも「本社所在地を管轄する総合通信局等」と定められている。さくらインターネットの本社は大阪市北区にあるため、窓口は近畿総合通信局が該当することになる。個人データの漏えい等についても、電気通信事業者の場合は個人情報保護委員会の権限が総務省へ委任されているため、提出先は個人情報保護委員会ではなく同じく総合通信局等になる。発表に「総務省、個人情報保護委員会等の関係機関への報告および情報共有」と両方が併記されているのは、この委任構造と整合する。

今後の見通しと備え——続報で見るべき点と、便乗フィッシング

発表は「本件については現在も調査を継続しており、新たに公表すべき事実が判明した場合には速やかにお知らせいたします」で締めくくられている。続報は前提とされている。次の発表で確認すべき点を整理しておく。

・583という数字が動くか：現在は「判明した」数であり、調査継続中と注記されている。増える可能性がある
・侵入経路と発生時期：現在は完全に未公表。ここが出ると、被害期間の見積もりが初めて可能になる
・漏えいした情報の具体的内容：現在は「顧客領域内に保存された情報」「利用者識別子」という抽象的な粒度にとどまる
・他サービスへの影響の確定：VPS・クラウド・専用サーバ PHY・高火力 PHY は「現時点で確認されず」の段階
・制限された機能の復旧：データベースアップグレード機能・プラン変更・移行ツールの制限がいつ解けるか
・一律のパスワード変更要請の有無：現時点では出ていないが、「必要な事項が判明した場合は個別案内とウェブサイトで告知」とされている

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

これは実務的に重要な条件だ。インシデント公表後は、その事業者を騙る「緊急のパスワード変更のお願い」型のメールが出回りやすい。本件では同社が対象者へ個別にメール通知を行っているため、正規の通知と偽の通知が同じ受信箱に並ぶ状況が生まれる。判別の基準は単純にできる。

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

参照ソース

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