Surfshark、内部テストサーバーに不正アクセス 設定ミスでインターネット公開、ユーザーデータとVPNサービスへの影響なし

セキュリティニュース

投稿日時: 更新日時:

Surfshark、内部テストサーバーに不正アクセス 設定ミスでインターネット公開、ユーザーデータとVPNサービスへの影響なし

VPNサービスを提供するSurfsharkは2026年9月9日、内部テストサーバーへの不正アクセスに関するインシデント報告を公表しました。

Surfsharkによると、エンジニアリング部門が利用していた内部テストサーバーが人的ミスによる設定不備でインターネットから到達可能な状態となり、第三者が不正にアクセスしました。侵害された環境からは、一部のシステムバイナリや特定サービスの内部設定など、限定的なエンジニアリング資料へアクセスされたことを確認しています。

また、隔離された「content accessibility optimisation server」と呼ばれるVPSにもアクセスされました。このVPSはプロキシとして動作していましたが、SurfsharkはユーザーID、IPアドレス、暗号鍵、閲覧トラフィックにはアクセスできない構成だったと説明しています。

同社は、顧客の個人情報やVPNトラフィックを保存・処理する本番環境とは分離されており、ユーザーデータ、VPNサービス、アプリ、ブラウザ拡張機能への影響は確認されていないとしています。利用者側でパスワード変更などの対応は不要と案内しています。

一方、内部コード履歴には過去にビルド関連の認証情報が含まれていたことも判明しました。これらの認証情報からユーザーデータや本番システムへアクセスすることはできなかったとしていますが、Surfsharkは予防措置として特定したすべての関連シークレットをローテーションまたは廃止しました。

今回の事案では、本番環境ではなくテスト環境の設定ミスが侵入口となりました。Surfsharkは、初動時に「ユーザー情報や機微情報を保持しない隔離テスト環境」と判断したため、当初は高緊急度のインシデントとして扱わなかったことも明らかにしています。この判断を教訓として、今後はテスト・実験環境にも本番環境と同等のセキュリティ基準を適用するとしています。

Surfshark不正アクセスのサマリー

確認できている内容:

  • Surfsharkは2026年9月9日、内部テスト環境への不正アクセスについて公式インシデント報告を公表しました。
  • 最初の不審な兆候は8月31日にセキュリティ監視システムで検知しました。
  • 9月2日に事象をセキュリティインシデントと判断し、不正アクセスを受けたサーバーを封じ込めました。
  • 原因は、人的ミスによる内部テストサーバーの設定不備です。
  • 設定不備により、本来内部向けだったテストサーバーがインターネットから到達可能な状態になっていました。
  • 第三者は、テストサーバーを経由して限定的な内部エンジニアリング資料へアクセスしました。
  • 対象には、一部のシステムバイナリや特定サービスの内部設定が含まれます。
  • コード履歴には、過去に一部の内部ビルド関連認証情報がコミットされていました。
  • Surfsharkは特定した関連シークレットをすべてローテーションまたは廃止しました。
  • 隔離されたcontent accessibility optimisation用VPSにも第三者がアクセスしました。
  • 当該VPSはプロキシとして動作していました。
  • Surfsharkは、VPSからユーザーID、IPアドレス、暗号鍵、閲覧トラフィックへアクセスすることはできなかったと説明しています。
  • 顧客データやVPNサービスへの影響は確認されていません。
  • VPNトラフィックや閲覧履歴は保持していないと説明しています。
  • Surfsharkアプリやブラウザ拡張機能の改変も確認されていません。
  • 不正アクセスが他のシステムへ拡大した事実は確認されていません。
  • 9月5日までに追加の修復作業を実施しました。
  • 利用者側で必要な対応はないとSurfsharkは案内しています。
  • 今後、テスト・実験環境にも本番環境と同等のセキュリティ基準を適用するとしています。
  • 追加の独立したセキュリティ監査も実施する予定です。

現時点で公表されていない内容:

  • 不正アクセスを行った攻撃者
  • 攻撃グループや国家との関係
  • 不正アクセスが最初に行われた正確な日時
  • インターネットへ公開されていた期間
  • アクセスされた具体的なシステムバイナリ名
  • アクセスされた具体的な設定ファイル名
  • コード履歴に含まれていたビルド関連認証情報の種類
  • 実際に第三者が認証情報を取得したか
  • 認証情報を使った追加侵入が行われた事実
  • アクセスされた内部資料が外部へ持ち出されたか
  • 攻撃に利用されたIPアドレスやIOC
項目 内容
公表日 2026年9月9日
対象 Surfsharkの内部エンジニアリング環境
最初の検知 2026年8月31日
インシデント確定 2026年9月2日
封じ込め 2026年9月2日
修復 2026年9月5日までに追加対応
原因 人的ミスによるテストサーバーの設定不備
状態 内部テストサーバーがインターネットから到達可能になっていた
不正アクセス 確認済み
アクセスされた情報 一部システムバイナリ、特定サービスの内部設定など
認証情報 コード履歴に内部ビルド関連認証情報が含まれていた。すべてローテーションまたは廃止
プロキシVPS 不正アクセスを確認
ユーザーデータ 影響なしとSurfsharkが確認
VPNトラフィック 影響なし。Surfsharkはログ・保持していないと説明
暗号鍵 プロキシVPSからアクセス不可
本番環境 侵害の拡大を確認せず
アプリ・拡張機能 改変なし
利用者対応 不要と案内
今後 テスト環境の本番同等化、監視強化、認証情報管理改善、独立監査

8月31日に不審な活動を検知、9月2日にインシデントと判断

Surfsharkのタイムラインによると、最初の兆候は2026年8月31日に検知されました。

セキュリティ監視システムが、隔離されたテスト環境で不審なイベントを検出しています。

ただし、この環境はユーザーデータや機微情報を保持しない設計だったため、当初は個人情報を保存・処理するシステムに適用する緊急対応プロトコルではなく、より低いリスクとして処理されました。

その後、9月2日に初期評価を完了し、事象をセキュリティインシデントと判断しました。

不正アクセスを受けたサーバーについてバックアップとスナップショットを取得したうえで、外部接続を切断しています。

同日、同じサブネット内のサーバーやアクセス可能だったその他の資産について、バックドアなどの痕跡を確認しました。

潜在的に影響を受けたシークレットについても失効またはローテーションを実施しています。

9月5日までに追加のセキュリティ評価、シークレットのローテーション、インフラのハードニングなどを進めました。

原因は「人的ミスによる設定不備」

Surfsharkは今回の直接原因を明確にしています。

エンジニアリングチームが利用する内部テストサーバーが、人的ミスによって誤設定され、インターネットから到達可能な状態になっていました。

本来、社内や限定された環境だけから利用するテストサーバーを外部からアクセス可能な状態にしたことが、今回の不正アクセスにつながりました。

Surfsharkは、悪用されたソフトウェア脆弱性やCVEを公表していません。

そのため、本件を「ゼロデイ攻撃」「VPN製品の脆弱性を悪用した侵入」「認証情報窃取による初期侵入」と表現する根拠はありません。

公式説明では、インターネットへ露出したテストサーバーの設定ミスが原因です。

一部のシステムバイナリと内部設定へアクセス

第三者はインターネットへ公開されていたテストサーバーを通じ、内部エンジニアリング環境に保存されていた限定的な資料へアクセスしました。

Surfsharkが具体的に挙げているのは、

  • 一部のシステムバイナリ
  • 特定サービスの内部設定

です。

ただし、どのサービスのバイナリ・設定だったのかは公表されていません。

また、公式発表は「accessed」としており、これらすべてが外部へコピー・持ち出されたことまで確認したとは説明していません。

したがって、「Surfsharkのソースコードが流出した」「VPNサーバーの設定ファイルが漏えいした」といった表現には置き換えられません。

コード履歴にビルド関連の認証情報が含まれていた

Surfsharkの調査では、一部の内部ビルド関連認証情報が過去にコード履歴へコミットされていたことも確認されました。

ソースコード管理では、APIキー、トークン、パスワードなどを誤ってリポジトリへコミットした後、現在のファイルから削除しても、Gitなどの履歴に値が残る場合があります。

Surfsharkは今回、コード履歴に含まれていた認証情報をすべて確認し、特定したシークレットをローテーションまたは廃止しました。

一方、同社はこれらの認証情報について、ユーザーデータや本番システムへアクセスできないものだったと説明しています。

利用可能なアクセスログも確認しましたが、追加の悪意ある活動は検知されなかったとしています。

ただし、具体的な認証情報の種類や、第三者が実際に値を取得したかどうかは公表されていません。

そのため「ビルド用認証情報が窃取・悪用された」とは断定できません。

隔離されたプロキシ用途のVPSにもアクセス

今回のインシデントでは、内部テストサーバーだけでなく、隔離された「content accessibility optimisation server」と呼ばれるVPSにも第三者がアクセスしました。

Surfsharkによると、このサーバーはプロキシとして動作していました。

一方、当該VPSからはユーザーのID情報、IPアドレス、暗号鍵、閲覧トラフィックへアクセスできない設計だったとしています。

そのため、SurfsharkはこのVPSへの不正アクセスによるユーザーのプライバシー・セキュリティへの影響はなかったと説明しています。

BleepingComputerはこの点を「proxy server」として報じていますが、Surfsharkの公式説明では一般ユーザーのVPN通信を処理する本番VPNサーバーではなく、隔離されたcontent accessibility optimisation用VPSです。

「SurfsharkのVPNプロキシサーバーが侵害され、ユーザー通信を盗聴された」と解釈するのは公式情報と異なります。

顧客の個人情報とVPN通信には影響なし

Surfsharkは、今回侵害されたシステムは内部エンジニアリング環境であり、顧客データを保存・処理していなかったと説明しています。

本番サービスを提供するシステムからも分離されていました。

同社が影響なしと説明している対象は、個人情報、ユーザーデータ、VPNサービス、VPNトラフィック、閲覧アクティビティ、ユーザーIPアドレス、暗号鍵、Surfsharkアプリ、ブラウザ拡張機能です。

また、VPNトラフィックや閲覧アクティビティについては、そもそもログとして記録・保持していないとしています。

機微情報を含むシステムを保護する認証情報も別のvaultに保存されており、今回の侵害環境からは影響を受けていません。

「ユーザーデータ漏えい」とする根拠はない

今回の事案はSurfshark自身が不正アクセスを確認しているため、「セキュリティインシデント」は確定しています。

一方、「顧客情報漏えい」は確認されていません。

整理すると、テストサーバーへの不正アクセス、内部エンジニアリング資料へのアクセス、隔離されたプロキシVPSへのアクセス、コード履歴にビルド関連認証情報が存在していたことは確認されています。

一方、顧客個人情報、VPN通信、暗号鍵、本番環境への侵入拡大は確認されていません。

VPN事業者への不正アクセスという性質から、ユーザーの閲覧履歴やIPアドレスへの影響が懸念されますが、Surfsharkの調査結果はそれらへのアクセスを否定しています。

利用者によるパスワード変更などは不要

Surfsharkは今回のインシデントについて、利用者への影響はなく、ユーザー側で必要な対応はないと説明しています。

Surfsharkアカウントのパスワード変更、VPNアプリの再インストール、ブラウザ拡張機能の削除などを求めていません。

今後Surfsharkを装った「今回の侵害を受けてパスワードを変更してください」といった便乗連絡が届く可能性は一般的に考えられますが、現時点で本件に関連するフィッシング被害が公表されているわけではありません。

初動が低優先度だったことをSurfshark自身が課題として認識

今回の公式報告で実務上参考になるのは、Surfsharkが初動時の判断についても説明している点です。

8月31日に最初のアラートを検知した際、対象がユーザーデータや機微情報を持たない隔離テスト環境だったため、個人情報を保存・処理するシステム向けの緊急プロトコルではなく、より低いリスクのケースとして扱いました。

9月2日に調査範囲を確定し、侵害を封じ込めています。

Surfsharkはこの時間差を「key lesson」と位置付け、今後はテスト環境や実験環境を本番環境と同じセキュリティ基準へ引き上げるとしています。

本番データが存在しない環境でも、コード、システムバイナリ、内部設定、ビルド情報、CI/CD関連の認証情報、他システムへの接続情報などが存在すれば、攻撃者にとって価値のある偵察情報になり得るためです。

テスト環境にも本番環境と同じセキュリティ基準を適用へ

Surfsharkは再発防止として、次の施策を公表しています。

  • ビルドプロセス全体のアクセス制御と認証情報管理を改善
  • テストインフラがインターネットへ露出していないことを検知する監視を強化
  • IT・セキュリティイベントへの対応速度を改善
  • テストインフラにも本番環境と同等のセキュリティツールを導入
  • テスト環境のOS・サービスを本番相当でハードニング
  • 広範なインフラ環境を対象とする追加の独立セキュリティ監査を実施

単に今回の設定を修正するだけでなく、開発・テスト環境全体の統制を変更する方針です。

国内でもテスト環境の管理不備による情報漏えい事例

テスト環境の管理はVPN事業者だけの問題ではありません。

セキュリティ対策Labでは2026年、阿波銀行のOAテスト環境への不正アクセス事案を取り上げています。

阿波銀行の事案では、目的完了後もテスト環境が残され、顧客データも消去されず、不正アクセス防止の仕組みが十分機能していなかったことが調査で判明しました。結果として、のべ27,745件の顧客・株主情報が漏えいしました。

Surfsharkの今回のインシデントでは顧客データは存在せず、利用者への影響も確認されていません。

両事案の被害規模は異なりますが、「テスト環境のセキュリティ基準が本番より低い」「一時的な環境が管理の死角になる」という点は共通する運用課題です。

情報システム部門・開発部門が確認したいポイント

今回のSurfsharkの事案を企業の管理へ置き換えると、確認対象はテストサーバー1台だけではありません。

  • 開発・テスト環境の外部公開資産を一覧化できているか
  • 一時的なFirewall・Security Group変更が元に戻っているか
  • クラウド上の検証用VMへ不要なパブリックIPを付与していないか
  • インターネット公開資産を継続的に検出できるか
  • ソースコードやGit履歴にシークレットを保存していないか
  • 削除済みシークレットがコミット履歴へ残っていないか
  • CI/CDのシークレットをvaultなどで管理しているか
  • 漏えいした可能性がある認証情報を即時ローテーションできるか
  • テスト用資格情報から本番環境へアクセスできない設計になっているか
  • テスト環境もSIEMやSOCの監視対象になっているか
  • EDRを本番だけに限定していないか
  • 不審アクセスの優先度を「顧客データの有無」だけで判断していないか
  • 本番と開発・テストのネットワークを分離しているか
  • 検証終了後のサーバーを自動停止・削除できるか
  • 一時的な外部公開に有効期限を付けているか

「顧客データがない」だけでは低優先度と判断できない

今回のSurfsharkの振り返りから読み取れるのは、テスト環境のリスク評価を「個人情報を保存しているか」だけで決めることの限界です。

テスト環境に顧客データがなくても、ソースコード、バイナリ、内部アーキテクチャ、サービス設定、CI/CD設定、APIキー、ビルド用シークレット、内部ホスト名、開発者アカウントなどが存在する可能性があります。

こうした情報は、それ単体では直接的な個人情報漏えいを起こさなくても、後続攻撃で本番環境を狙うための情報として利用される可能性があります。

Surfsharkが「テスト・実験環境を本番と同じセキュリティ基準へ引き上げる」としたのは、この点を踏まえた対応です。

Surfshark利用者への影響は現時点で確認されず

9月9日の公式報告時点で、Surfsharkは顧客への影響を否定しています。

利用者の個人情報、IPアドレス、閲覧トラフィック、暗号鍵へのアクセスは確認されず、VPNサービス、アプリ、ブラウザ拡張機能も影響を受けていません。

ユーザー側で必要な作業もないとしています。

今後の確認点は、独立セキュリティ監査の結果、新たな侵害範囲が判明するか、アクセスされた内部資料の詳細、コード履歴に含まれていたシークレットの範囲、テスト環境への本番同等セキュリティ適用の完了状況です。

Surfsharkは追加の関連情報が判明した場合、公式ブログを更新するとしています。

出典