株式会社ワサビ、開発環境への不正アクセスでランサムメッセージ残置-Dockerと自宅ルーターの二重の設定不備が原因|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月09日更新日時: 2026年07月09日

EC一元管理システムWASABI SWITCH(旧WORLD SWITCH)を提供する株式会社ワサビは2026年7月6日、開発環境の端末に対する外部からの不正アクセスによるセキュリティインシデントが発生したと公表しました。データベース内の情報が外部へ送信されたうえで削除され、ランサムメッセージが残されていたことも確認されています。詳細な調査の結果、実在する顧客の個人情報の漏えいは確認されていないとしていますが、本番環境でも使用されていたAPIキーやアプリケーションIDが窃取対象に含まれていたため、複数のモールで再認証が必要になる見込みです。

サマリー

株式会社ワサビは2026年7月4日、開発環境端末上のMySQLデータベースおよびRedisキャッシュサーバへ外部から不正アクセスを受けた
データベース内の情報が外部へ送信された後に削除され、ランサムメッセージが残されていたことを確認。7月6日にインシデントを公表し、7月7日に内容を更新した
流出した注文・顧客データはすべてテスト用のダミーデータで、実在する顧客の個人情報は含まれていなかった
一部のAPIキー、アプリケーションID、テストデータ、およびワサビ管理者アカウントの情報が窃取された。管理者アカウントのパスワードはソルト付きSHA-256でハッシュ化されていたが、念のため全アカウントを停止しパスワードを変更した
窃取された情報の中に本番環境でも使用されているAPIキーとアプリケーションIDが含まれており、対象はLuxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、Walmartの各API。APIキーは速やかに再発行・無効化済みで不正利用は確認されていないが、アプリケーションIDについては再発行手続き中で、完了後は各モールでの再認証が必要になる
Redisキャッシュサーバでは暗号資産マイニングを目的とした不正な設定の書き込みが確認されたが、コンテナ内に隔離されており実行プログラムが存在しなかったためシステムへの被害はなかった
原因は、開発環境のDockerコンテナのデータベースポートが外部から接続可能な設定(0.0.0.0)になっていたことと、接続していた自宅ルーターの設定・ファームウェアの不具合により該当ポートが外部へ公開される状態になっていたことの2つが重なったこと

項目	内容
公表日	2026年7月6日(7月7日更新)
発生日	2026年7月4日(土)
侵害対象	開発環境端末上のMySQLデータベース、Redisキャッシュサーバ
被害の内容	データ窃取後の削除、ランサムメッセージの残置
顧客個人情報への影響	なし(流出データはすべてテスト用ダミーデータ)
窃取された情報	一部APIキー、アプリケーションID、テストデータ、ワサビ管理者アカウント情報
本番環境への影響	一部APIキー・アプリケーションIDが本番環境と共用されており対応が必要に
対象API	Luxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、Walmart
Redisへの追加被害	暗号資産マイニング目的の不正設定を確認、コンテナ隔離により実害なし
原因	Dockerのデータベースポートが外部公開設定(0.0.0.0)、自宅ルーターの不具合によるポート転送の重複

1 何が起きたか
2 発生から対応までの経緯
3 原因はDockerの公開設定と自宅ルーターの二重の不備
4 Redisで確認された暗号資産マイニングの痕跡
5 再発防止策
6 情報システム部門への示唆
7 出典

何が起きたか

株式会社ワサビによると、2026年7月4日、開発環境端末上のMySQLデータベースおよびRedisキャッシュサーバに対して外部から不正アクセスが発生しました。データベース内の情報は外部へ送信された後に削除され、攻撃者によるランサムメッセージが残されていたことが確認されています。同社は詳細な調査の結果、この開発環境に保存されていた注文・顧客データはすべてテスト用に作成された架空のダミーデータであり、実在する顧客の個人情報は一切含まれていなかったとしています。

一方で、窃取された情報の中には、一部のAPIキー、アプリケーションID、テストデータに加えて、WASABI SWITCHの管理者アカウントの情報が含まれていました。管理者アカウントのパスワードはソルト付きSHA-256による強固なハッシュ化が施されており平文ではなかったとされていますが、同社は二次被害を防ぐため速やかに全アカウントを停止し、パスワードを変更する対応を取っています。

もっとも重要なのは、窃取された情報の一部に本番環境でも使用されているAPIキーとアプリケーションIDが含まれていた点です。APIキーについては速やかに再発行・旧キーの無効化を完了しており、本稿執筆時点で不正利用は確認されていないとしています。アプリケーションIDについては、OAuth認証を必要とする仕様であるため機密情報が直接漏えいすることはないとしつつも、念のため再発行の手続きが進められています。対象となるのはLuxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、Walmartの各API連携で、再発行完了後は利用企業各社が各モールの設定画面で再認証を行う必要があるとされています。同社は、不審なサイト等でこのOAuth認証(連携許可)を行わない限り、注文情報や商品情報、その他の個人情報が流出することはないと説明しています。

発生から対応までの経緯

同社が公表したタイムラインによると、2026年7月4日(土)8時56分に開発環境端末への不正アクセスが発生し、10時48分の時点でデータの窃取・削除とランサムメッセージの残置が確認されています。その後11時52分から攻撃元の特定と被害状況の確認が始まり、14時52分には二次被害防止のため全WASABI SWITCHのワサビ管理者アカウントを停止し、セッションを強制的に削除する措置が取られました。17時13分に根本原因が確定し、18時28分に担当社員から社内への報告が行われています。19時47分には情報の流出状況が改めて詳細に確認され、20時35分には緊急性の高いAPIキー等のクレデンシャル情報が再発行され、流出した情報が無効化されました。22時42分には恒久対策としてソースコードの修正も行われています。

翌7月5日(日)10時からはアプリケーションIDの再発行手続きが開始され、7月6日(月)11時には全WASABI SWITCHのワサビ管理者アカウントのパスワードを変更したうえでアカウントの稼働が再開されています。発生から本格的な復旧まで、休日を挟みながらも実質2日程度という比較的短い期間で一連の対応が完了している点は、インシデント対応の実務例として参考になる部分です。

原因はDockerの公開設定と自宅ルーターの二重の不備

同社の説明によれば、今回の侵害を許した原因は2つの要因が重なったことにあります。1つ目は、開発環境のDockerコンテナのデータベースポートが、ローカル環境のみからアクセス可能な127.0.0.1ではなく、外部からも接続可能な0.0.0.0という設定になっていたことです。2つ目は、この端末を接続していた自宅ルーターの設定およびファームウェアの不具合により、該当のポートが外部へ転送される、いわゆるパブリックに公開された状態になっていたことです。この2つの不備が重なった結果、インターネット上を巡回する探索ボットが公開されたポートを発見し、侵入に至ったとされています。

サーバサイドエンジニアとして開発環境の構築に携わってきた経験から言うと、開発時の利便性を優先してDockerのポート公開設定を緩めてしまうことは決して珍しいミスではありません。本来であればコンテナ側の設定だけでも外部からの直接接続は防げるはずですが、今回はさらに自宅ルーター側のポート転送(UPnPなど)という、開発者本人が意識しにくいもう1つの経路が偶然重なってしまったことで、内外二重の防御がいずれも機能しない状態になっていたことになります。在宅勤務やリモート開発が広がる中、開発者の自宅ネットワーク環境が組織のセキュリティ境界の外側にありながら、実質的に内部ネットワークと同等の役割を果たしてしまっているという構図は、同種の企業にとっても他人事ではありません。

Redisで確認された暗号資産マイニングの痕跡

今回の侵害では、Redisキャッシュサーバに対して暗号資産マイニングを目的とした不正な設定の書き込みも確認されています。ただし、この設定はコンテナ内に隔離された環境にとどまっており、実際にマイニングを実行するプログラム自体は存在しなかったため、システムへの実害は発生しなかったとされています。攻撃者が金銭目的でランサム的な恐喝と暗号資産マイニングの両方を同時に試みる手口は、当サイトでも過去に取り上げてきた侵入型攻撃の典型的なパターンと重なるものです。今回はコンテナによる隔離が功を奏した形ですが、コンテナの権限設定や特権モードの有無によっては、こうした二次的な悪用がより深刻な被害に発展していた可能性もあります。

再発防止策

株式会社ワサビは今回の事態を受け、複数の再発防止策を打ち出しています。具体的には、Dockerのすべての公開ポート(MySQL・Redis等)を127.0.0.1に限定し外部からの直接接続を遮断すること、MySQL・Redis等すべてのシステムにおける認証情報の定期的なローテーションを実施すること、開発環境で使用するデータに含まれるパスワードハッシュや認証情報をダミー値へ置き換え本番データとの紐付きを完全に排除すること、影響を受けた全スタッフのパスワードを再設定すること、対象ルーターのUPnP機能を無効化しポート転送設定を削除すること、開発担当者全員の端末・環境に対するペネトレーションテストを実施すること、そして外部のセキュリティ専門企業へ総合的なセキュリティ監査を依頼することが挙げられています。

情報システム部門への示唆

今回の事案は、本番環境そのものは直接侵害されていないにもかかわらず、開発環境の設定不備を起点に本番環境で使う認証情報にまで影響が及んだという点で、開発環境と本番環境の境界管理がいかに重要かを改めて示す事例です。当サイトで以前紹介したDocker Hubのコンテナイメージから1万件超の認証情報が漏えいしていた調査でも指摘されている通り、開発現場でのちょっとした設定の緩みが、そのまま本番システムへの入口になりうるという構図は、業種やサービス規模を問わず共通する課題です。

実務的な対策としては、まず自社の開発環境で使用しているDockerやデータベース、キャッシュサーバのポート公開設定を棚卸しし、意図せず0.0.0.0のような外部公開設定になっていないかを確認することをお勧めします。あわせて、リモートワークや在宅開発を行う環境では、開発者の自宅ルーターにおけるUPnPの有効化状況やポート転送設定についても、会社として一定のガイドラインを示しておくことが望まれます。さらに根本的な対策として、開発環境で使用する認証情報やAPIキーを本番環境のものと共用しない設計にしておくことが、今回のような設定不備が発生した場合の被害範囲を最小限に抑えるうえで有効です。開発環境のデータについても、可能な限りダミーデータへ置き換え、万が一漏えいしても実害につながらない状態を維持しておくことをお勧めします。