ワサビ開発環境端末への不正アクセス（MySQL・Redisからの情報窃取とランサムメッセージ残置、顧客データはダミー）
公表日
EC一元管理システム「WASABI SWITCH」を提供する株式会社ワサビの開発環境の端末に外部から不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。があり、APIキーや管理者アカウント情報などが盗まれた。流出した注文・顧客データはテスト用のダミーで、実在顧客の個人情報の漏えいは確認されていないという。
対象者は？
WASABI SWITCHを利用している企業のうち、Luxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、WalmartのいずれかとAPI連携している場合は、アプリケーションIDの再発行に伴う再認証が必要になる。流出した注文・顧客データはダミーで、実在する顧客の個人情報は含まれていないとされている。
再認証の方法や日程は、決まり次第ワサビが案内するとしている。ワサビからのお知らせを確認し、利用中のモール連携が対象かどうかを確かめる。
いますぐできること
- ワサビからの案内を確認し、対象のモール連携を使っている場合は、案内に従って各モールの設定画面で再認証を行う。
- ワサビは別件で、同社スタッフと共有していたパスワードや他サービスと同じパスワードを使っている場合は変更するよう求めている。該当する場合は変更する。
- 不審なサイトでOAuth認証の許可を求められたら、許可しない。
何が起きたのか
2026年7月4日の朝、ワサビの開発用の端末で動いていたデータベース（MySQL）とキャッシュサーバ（Redis）に、外部から不正なアクセスがあった。データは外部へ送られた後に削除され、身代金を求めるようなメッセージが残されていた。同社は同日中に、管理者アカウントの停止、APIキーの再発行、ソースコードの修正などを行った。7月6日に最初の発表、7月7日に調査結果を公表した。盗まれたのは、一部のAPIキー、アプリケーションID、テストデータ、管理者アカウント情報で、管理者のパスワードはハッシュ化されており、そのままの文字では保存されていなかった。
なぜ起きたのか・なぜ広がったのか
同社によると、開発用のDockerコンテナのデータベース用の窓口が、自分の端末からだけでなく外からも入れる設定になっていた。さらに、端末をつないでいた自宅ルーターの設定とファームウェアの不具合で、その窓口がインターネットに公開される状態だった。この二つが重なり、ネット上を探し回る自動プログラム（ボット）に見つかって侵入されたとされる。盗まれた情報には本番でも使うAPIキーなどが含まれていたため、7つのサービスとの連携が対象になった。
いまの状況2026-07-07 時点続報待ち
2026年7月7日時点の公表では、APIキーは再発行して古いキーを無効にし、不正利用は確認されていない。アプリケーションIDは再発行の手続き中で、終わると利用企業の再認証が必要になる。再認証の方法や日程は、まだ発表されていません。再発防止策として、公開ポートを自分の端末だけに限る、認証情報を定期的に変える、開発用データをダミーにする、ルーターのUPnPを無効にする、開発担当者の端末で侵入テストを行う、外部の専門企業の監査を受ける予定、などが挙げられている。
企業として考えたいこと
自社の開発用の環境や担当者の自宅ネットワークに、本番と同じ鍵やパスワードが置かれていないか、また、外から見える入口が開いていないかを、誰がどのくらいの頻度で確認しているだろうか。
技術的な要約
株式会社ワサビは2026年7月6日にEC一元管理システムWASABI SWITCHの開発環境端末への不正アクセスを公表し、7月7日に調査結果を公表した。不正アクセスは7月4日8時56分に発生し、開発環境端末上のMySQLとRedisが対象となり、データは外部送信後に削除されランサムメッセージが残された。窃取されたのは一部のAPIキー、アプリケーションID、テストデータ、ワサビ管理者アカウント情報で、流出した注文・顧客データはダミーであり実在顧客の個人情報や機密情報の漏えいは確認されていないとしている。原因はDockerコンテナのDBポートが0.0.0.0で公開されていたことと、自宅ルーターの設定・ファームウェアの不具合でポートが外部公開されていたことの重なりで、探索botに発見されたとされる。APIキーは再発行済みでアプリケーションIDは再発行中であり、利用企業は再認証が必要になる。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 公開サーバの脆弱性報道・研究者開発環境のDockerコンテナのDBポートが127.0.0.1ではなく0.0.0.0の設定で、さらに接続していた自宅ルーターの設定とファームウェアの不具合により該当ポートが外部へ転送される状態だった。インターネットを巡回する探索botが公開ポートを発見して侵入に至ったとされる（報道ベース）。
- 脆弱性
- CVE 非公表報道・研究者Dockerコンテナ（MySQL・Redis）／自宅ルーターCVEは公表されていない。DBポートが0.0.0.0で公開され、ルーターの設定・ファームウェア不具合でポートが外部公開されていた。製品名・型番は非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 全WASABI SWITCHのワサビ管理者アカウントを停止しセッションを強制削除した。7月6日11時にパスワード変更のうえ稼働を再開した。期間：2026-07-04T14:52から2026-07-06T11:00まで（管理者アカウントの停止）
- データ
- 確定上限 —確定 —業務データその他窃取されたのは一部のAPIキー、アプリケーションID、テストデータ、ワサビ管理者アカウント情報。管理者パスワードはソルト付きSHA-256でハッシュ化され平文ではなかった。注文・顧客データはテスト用ダミーで、実在顧客の個人情報や機密情報の漏えい・不正利用は確認されていないとしている。件数は非公表。
- 波及先
- 7 API連携
- Luxclusif
- ヤフーショッピング
- 併売ヤフオク
- 競りナビ
- UPS
- Shopify
- Walmart
- 金銭影響
- —
- サプライチェーン
- 窃取情報に本番環境でも使われていたAPIキーとアプリケーションIDの一部が含まれ、7つのAPI連携が対象となった。アプリケーションID再発行後は利用企業が各モールの設定画面で再認証する必要がある。アプリケーションIDだけでは注文・商品情報にアクセスできないと同社は説明している。
時系列
- 2026-03-30ワサビが、カスタマーサポート窓口で利用していたChatwork上の管理スタッフアカウントへの第三者による不正アクセスを公表した（本件とは別の事案）。3
- 2026-07-04 08:56
- 2026-07-04 10:48データの窃取・削除とランサムメッセージの残置を確認した。2
- 2026-07-04 14:52二次被害防止のため全WASABI SWITCHのワサビ管理者アカウントを停止し、セッションを強制削除した。2
- 2026-07-04 17:13根本原因が確定した。同日18時28分に担当社員から社内へ報告された。2
- 2026-07-04 20:35
- 2026-07-05 10:00アプリケーションIDの再発行手続きを開始した。2
- 2026-07-06 11:00全ワサビ管理者アカウントのパスワードを変更したうえで稼働を再開した。2
- 2026-07-06ワサビが開発環境端末への不正アクセスによるインシデントの発生を公表した。2
- 2026-07-07
技術解説
公表された経過と対応の流れ 事実
ワサビは2026年7月6日に開発環境端末への不正アクセスを公表し、7月7日に調査結果を公表した。不正アクセスは7月4日(土)8時56分に発生し、対象は開発環境端末上で稼働していたMySQLとRedisだった。10時48分の時点で、データの窃取・削除とランサムメッセージの残置が確認された。攻撃者はデータを外部へ送信した後に削除したとされる。14時52分に全WASABI SWITCHのワサビ管理者アカウントを停止してセッションを強制削除し、17時13分に根本原因が確定した。20時35分に緊急性の高いクレデンシャルを再発行し、22時42分にソースコードを修正した。7月5日10時にアプリケーションIDの再発行手続きを開始し、7月6日11時に全管理者アカウントのパスワードを変更して稼働を再開した。
原因とされる二つの設定不備 事実
同社の説明では、原因は複数の設定不備の重なりである。一つ目は、開発環境のDockerコンテナのデータベースポートが、ローカルのみから接続できる127.0.0.1ではなく、外部からも接続できる0.0.0.0の設定だったこと。二つ目は、開発端末を接続していた自宅ルーターで、設定とファームウェアの不具合によって該当ポートが外部へ転送される状態だったことである。インターネット上を巡回する探索ボットが公開されたポートを発見し、侵入に至ったとされる。攻撃者はデータ窃取後、Redisの設定を書き換えて暗号資産マイニングを試みた。しかし対象環境はコンテナ内で隔離され、実行ファイルも存在しなかったため、マイニングは実行されなかったと説明されている。
窃取された情報と影響の範囲 事実
窃取された情報には、一部のAPIキー、アプリケーションID、テストデータ、ワサビ管理者アカウント情報が含まれていた。管理者パスワードはソルト付きSHA-256でハッシュ化されており、平文ではなかった。流出した注文情報や顧客情報はテスト用のダミーデータで、実在する顧客の個人情報は含まれていなかったとしている。窃取情報には本番環境でも使っていたAPIキーとアプリケーションIDの一部が含まれ、対象はLuxclusif、ヤフーショッピング、併売ヤフオク、競りナビ、UPS、Shopify、Walmartの7つのAPI連携だった。APIキーは再発行して旧キーを無効化し、不正利用は確認されていない。アプリケーションIDは再発行手続き中で、完了後は利用者が各モールの設定画面で再認証する必要がある。流出の件数は示されていない。
被害が限定的にとどまった要因と残る論点（解釈） 解釈
公表内容からは、開発環境に置かれていた注文・顧客データがダミーだったことが、実在顧客の情報漏えいを避ける方向に働いたと読める。コンテナが隔離され実行ファイルがなかったことも、マイニングが実行されなかった一因と考えられる。一方で、開発環境に本番でも使うAPIキーやアプリケーションIDの一部が含まれていたことで、影響が7つの外部連携に及び、利用企業の再認証という作業が生じた。つまり本件の影響の大きさは、顧客データの有無よりも、開発環境と本番環境の認証情報の関係に左右されたと考えられる。また、起きた日のうちに原因の確定と主要な認証情報の再発行まで進んだ点は、被害の拡大を抑える対応として評価できる。ただし、再認証の日程など未決定の事項は多く、最終的な評価は続報を待つ必要がある。
対応
- 封じ込め
- 全ワサビ管理者アカウントの停止とセッション強制削除、管理者パスワード変更、APIキーの再発行と旧キー無効化、ソースコード修正を実施した。アプリケーションIDは再発行手続き中。再発防止策として、Docker公開ポートの127.0.0.1限定、MySQL・Redis認証情報の定期更新、開発用データのダミー化、対象ルーターのUPnP無効化とポート転送設定の削除、開発担当者全員の端末への侵入テスト、外部セキュリティ専門企業による監査（予定）を挙げている。
- 公表の仕方
- 2026年7月6日に第1報、7月7日に調査結果を公表した。アプリケーションID再発行後の再認証の方法や日程は決まり次第案内するとしている。
- 当局対応
- —
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 開発用コンテナのDBポートは、意図しない限り外部に公開しない | docker-composeのportsは「127.0.0.1:3306:3306」のようにループバックを明示する。0.0.0.0指定や、ホスト側の公開ポートが無指定のものを検出するlintをCIに入れる。ホスト側ではss -tlnpなどで待ち受けアドレスを定期的に確認する。 |
| 自宅や拠点のルーターの設定が、端末内の設定不備を外に露出させることがある | リモート勤務・開発に使うルーターはUPnPを無効にし、既存のポート転送設定を棚卸しして不要なものを削除する。ファームウェアの更新手順を定め、外部のスキャンサービスなどで自宅・拠点のグローバルIPに開いているポートがないか定期的に確認する。 |
| 開発環境に本番と共通の認証情報やデータを置かない | APIキーやアプリケーションIDを環境ごとに分離し、開発環境では専用の発行物だけを使う。開発用DBのデータとパスワードハッシュはダミー値に置き換える。シークレットはシークレット管理基盤から都度取得させ、端末上のファイルに本番用を残さない。 |
| DBやキャッシュは、公開されても被害が広がらない構えにしておく | MySQLとRedisには強いパスワードと認証を必須にし、Redisはprotected-modeとrequirepassを有効にする。CONFIGコマンドなど設定書き換えに使われるコマンドをrename-commandやACLで制限する。認証情報は定期的に更新する。 |
| 認証情報が漏れたときに、短時間で再発行・無効化できる手順を用意しておく | APIキー、OAuthのアプリケーションID、管理者アカウントなどの失効・再発行手順を、連携先ごとにランブックにまとめる。管理者セッションを一括で強制失効できる機能を実装し、演習で所要時間を測っておく。利用企業が行う再認証の案内文の雛形も準備する。 |
自組織などでの確認項目
- 自組織の開発用コンテナやDB・キャッシュサーバは、どのアドレスで待ち受けているか。0.0.0.0で待ち受けているものはないか。
- リモート勤務や自宅で開発する担当者のルーターで、UPnPやポート転送が有効になっていないか。確認する仕組みはあるか。
- 開発環境や検証環境に、本番と同じAPIキー・アプリケーションID・パスワードが残っていないか。漏れた場合に何時間で再発行できるか。
未解明点
- 対象となった自宅ルーターの製品名・型番とファームウェアの状況は公表されていない。
- 窃取されたAPIキー・アプリケーションIDの件数や、管理者アカウントの数は公表されていない。
- 本番環境でも使うAPIキーとアプリケーションIDの一部が、開発環境にあった経緯は説明されていない。
- アプリケーションID再発行後の再認証の方法と日程は、決まり次第案内するとされており、まだ示されていない。
- 攻撃者の名称や、ランサムメッセージの内容、要求の有無は公表されていない。
出典
- 1＠IT（ITmedia）2026-07-17報道本文確認済
- 2セキュリティ対策Lab（合同会社ロケットボーイズ）2026-07-09報道本文確認済
- 3セキュリティ対策Lab（合同会社ロケットボーイズ）2026-04-02報道本文確認済
- 4ScanNetSecurity2026-07-24報道本文確認済
- 5エキサイトニュース（ScanNetSecurity）2026-07-24報道本文確認済