futureshop不正アクセス：4サーバー停止と1店舗漏えい、店舗が今やる点検

SaaS型ECの「futureshop」を提供するフューチャーショップは、2026年10月21日から25日にかけて、不正アクセスと情報漏えい、長時間メンテナンスに関する発表を続けて出しました。4台のサーバーの緊急停止、1店舗の会員情報3,147,469件の漏えい、PHPの脆弱性「PHP2Shell」対策のメンテナンス、フォームメーラーの提供終了は、それぞれ別の事象です。本記事は公式発表をもとに、自店に関係するのはどれかを切り分け、利用店舗が今週中に済ませる対応を整理します。後半では、CMSサーバオプションで動かしているPHPのページを店舗や制作会社が自分で点検するPythonスクリプトと、委託元として負う責任を示します。

まとめ：futureshopで10月に起きた5つの事象と利用店舗が先に片付けること

10月にfutureshopの周辺で公表された事象は5つあります。個人情報の漏えいが確認されているのは、リンツの1店舗だけです。4台のサーバーへの不正アクセスは、10月28日時点で漏えいが確認されていません。それ以外はサービスの停止と終了です。

利用店舗が先に片付けるのは4つです。管理画面と同じパスワードを他のサービスで使っていれば変える。受注管理や在庫連携に渡したAPIの認証情報を確かめる。止まったフォームへの導線を外す。自店の会員に何を伝えるかを決める。CMSサーバオプションでWordPressなどを動かしている店舗は、PHPのページの点検も加えます。

futureshopが10月に公表した5つの事象を発表ごとに切り分ける時系列

10月21日の不正アクセス：c02・c05・c12・g06の4台停止と第二報の内容

10月21日の第一報によると、フューチャーショップは同日10時14分頃に一部サーバーへの不正アクセスを確認し、11時30分から4台をメンテナンス状態にしました。対象はc02、c05、c12、g06で、c02はトライアル用の環境です。対象サーバーの店舗では、ECサイト、管理画面、FTP・APIが使えなくなりました。

翌日の第二報では、対象店舗の契約ドメインのメール送受信も安全のため止めたと追記されています。停止中に届いたメールはサーバーに保存されています。調査の時点では「個人情報の参照および外部への持ち出しの痕跡がない」とされました。10月25日の説明で、原因は関連サービスの脆弱性と示され、その関連サービスは停止済みです。4台はサーバー環境を再構築したうえで10月22日23時35分に再開しました。

10月17日の侵入で1店舗314万件が漏えいした件とリンツの発表の関係

10月23日の個人情報漏えいの第一報は、店舗名を伏せたまま、1店舗の会員情報3,147,469件が取得されたと公表しました。侵入は10月17日23時02分、取得は18日0時16分、判明は19日15時30分頃です。原因はサーバーで使っていたソフトウェアの脆弱性で、全ての管理画面サーバーに対策を施し、他店舗のデータへの同様の手法での不正アクセスの痕跡は確認されていないとしています。

件数と日時が一致するリンツ＆シュプルングリージャパンの発表から、この1店舗はリンツと分かります。会員側の対処とパスワードの保存方式は、リンツ不正アクセスの対象確認とパスワード強制リセット後の対処で解説しています。

PHP2Shell対策の約26時間メンテナンスとCMSサーバオプションの店舗

10月21日に公開されたPHPの重大な脆弱性への対策として、futureshopは21日21時36分から22日23時35分まで、全店舗を対象に緊急メンテナンスを行いました。10月25日の説明によると、futureshop本体はPHPを使っていません。対象は、PHPの環境を提供するCMSサーバオプションです。

多くの店舗がこのオプションでWordPressなどを動かし、トップページや特集ページを作っています。切り離すとECサイトとして成り立たない店舗が多く、店舗ごとにPHPのバージョンが違うため個別の対応が要り、終了時刻が何度も延びました。22日15時以降はfutureshop単体の店舗から再開しています。脆弱性の中身はPHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版で扱っています。

フォームメーラーFreePlus終了とIDCF経由のメール配信停止は別の話

10月23日18時には、「フォームメーラーFreePlus」と「新フォームメーラー」の提供が終了しました。提供元のフューチャースピリッツは、長期間の提供でセキュリティ水準の維持が難しくなったことを理由に挙げ、10月23日時点で不正アクセスや漏えいは確認されていないとしています。発表上、不正アクセスの事案とは結び付けられていません。

月の初めには、IDCフロンティアのクラウドへの攻撃で、販促メールの「future Scenario Cast」とカゴ落ちメールの「futureCartRecovery」が10月7日13時45分から止まりました。9日12時30分に別のデータセンターで再開し、10月15日の第三報で個人情報の漏えいは確認されていないと報告されています。IDCF側の経緯はIDCFクラウドのランサムウェア被害にまとめています。

10月28日時点で非公表の脆弱性名・関連サービス名・4台の店舗数

まだ分かっていないことも並べておきます。リンツの件で悪用されたソフトウェアと脆弱性の種類、4台への侵入に使われた関連サービスの名前、4台を使っていた店舗数は、いずれも公表されていません。PHP2Shellがどちらかの侵入経路だったという発表もない状況です。外部の専門機関による調査結果は利用店舗に案内するとされており、本記事はそれまで推測で補いません。

利用店舗が今週中に済ませる対応：管理画面・API連携・フォーム・顧客案内

管理画面パスワードの使い回し解消と、スタッフアカウントの棚卸し手順

10月21日の第一報で店舗に求められたのは、管理画面のパスワードを他のサービスでも使っている場合の変更です。運営会社がメールや電話でパスワードを尋ねることはないとも明記されています。4台の店舗に限らず、モール、決済代行、受注管理、メールで同じパスワードを使っていないかを洗い出します。

あわせて、退職者や外部の制作会社に発行したままのスタッフアカウントを止めます。誰がいつ管理画面に入ったかを後から説明できる状態にしておくと、外部調査の結果が届いたときに自店の記録と突き合わせられます。

受注管理・在庫連携に渡したAPIの認証情報を再発行する条件と順番

停止した4台では、管理画面に加えてFTP・APIも止まりました。受注管理システムや在庫連携、物流の倉庫システムにAPIの認証情報を渡している店舗は、自店がこの4台の対象だったかを先に確かめます。対象だった店舗は、外部調査の結果を待たずに再発行するのが安全側の判断です。

順番は、連携先の一覧を作る、新しい認証情報を発行する、連携先を切り替える、古い認証情報を無効にする、の4段階です。古いものを先に止めると受注の取り込みも停止するため、切り替え後の無効化が必要です。再開直後は、注文番号で二重取り込みがないかを確かめてから出荷指示を出します。認証情報の失効とレート制限の考え方はAPI不正アクセス対策の実装手順で解説しています。

止まったフォームの撤去と保存データ請求の期限2027年1月29日

フォームメーラーの終了で、作成済みのフォームは表示も送信もメール通知も正常に動きません。問い合わせが送れたように見えて届かないのが一番困る状態です。フォームへのリンクを外し、メールや電話の窓口を代わりに案内します。

過去の問い合わせなどの保存データが要る場合は、2027年1月29日までに、利用登録したメールアドレスからフューチャースピリッツの窓口へ連絡します。期限を過ぎると保存データは削除の対象です。代わりのフォーム作成サービスは10月26日以降、順次案内するとされています。

自店の会員に対象外と伝える文面で、言ってよい範囲と言えない範囲

報道でfutureshopの名前を見た会員から、自分の情報は大丈夫かと問い合わせが来ます。言ってよいのは、公表されている事実です。漏えいが確認されたのは1店舗で、他店舗への同様の不正アクセスの痕跡は確認されていないと運営会社が発表している、という書き方になります。

言えないのは「当店のお客様の情報は漏えいしていません」という断定です。4台への不正アクセスは調査中で、自店が対象だった場合は特にそうです。調査結果が出たら改めて知らせると添え、便乗した偽のメールやSMSへの注意も同じ案内に入れます。

CMSサーバオプションのPHPページを自分で点検するPythonスクリプト

PHP公式の修正版8.5.12〜8.2.35と更新できない場合の緩和設定

PHPの2026年のニュースによると、10月21日に8.5.12、8.4.27、8.3.36、8.2.35が公開され、認証なしでリモートからコードを実行されうる2件（CVE-2026-109618・109619、CVSS v4.0で9.2）が修正されました。修正前の版で動くWebのPHPが対象で、mod_phpは攻撃の実証があるとして最も危険とされています。詳細はGitHubのセキュリティ勧告GHSA-w8hw-w9fx-j79wにあります。

8.1以前に公式の更新はなく、ディストリビューションの修正版かサポート中の版への移行が必要です。8.2も2026年12月31日にサポートが終わります。session.upload_progress.enabled=0などの緩和設定は公式に「完全な対策ではない」とされ、更新の代わりになりません。CMSサーバオプションの版の更新はフューチャーショップの作業なので、店舗側でできるのは、外から見える状態の確認と問い合わせです。

版数の露出と外部送信フォームを洗い出すスクリプトと実行結果の読み方

次のスクリプトは、指定したページを1つずつ取得し、応答ヘッダのX-Powered-Byに出るPHPの版を修正版と比べます。同時に、ページ内のフォームのうち自店とは別のドメインへ送るものを一覧にします。後者は、終了したフォームメーラーのような外部サービスへの導線を見つけるためです。点検してよいのは自店のページだけです。

# 自店のページを巡回し、PHPの版数の露出と、外部ドメインへ送るフォームを洗い出す（Python 3.9以上・標準ライブラリのみ）
import sys
import urllib.request
from html.parser import HTMLParser
from urllib.parse import urljoin, urlparse

# PHP公式が2026年10月21日に公開した修正版（PHP2Shell対応）
FIXED = {(8, 5): 12, (8, 4): 27, (8, 3): 36, (8, 2): 35}


class FormFinder(HTMLParser):
    def __init__(self):
        super().__init__()
        self.actions = []

    def handle_starttag(self, tag, attrs):
        if tag == "form":
            self.actions.append(dict(attrs).get("action") or "")


def php_status(powered_by):
    if not powered_by.startswith("PHP/"):
        return "版数の表示なし"
    parts = powered_by[4:].split("-")[0].split(".")
    major, minor, patch = int(parts[0]), int(parts[1]), int(parts[2])
    need = FIXED.get((major, minor))
    if need is None:
        return f"{major}.{minor}系は公式の修正版なし（要確認）"
    return "修正版以上" if patch >= need else f"未修正（{major}.{minor}.{need}以上が必要）"


def check(url):
    req = urllib.request.Request(url, headers={"User-Agent": "shop-self-check"})
    with urllib.request.urlopen(req, timeout=15) as res:
        powered_by = res.headers.get("X-Powered-By", "")
        html = res.read().decode("utf-8", "replace")
    print(url)
    print("  X-Powered-By:", powered_by or "なし", "→", php_status(powered_by))
    finder = FormFinder()
    finder.feed(html)
    host = urlparse(url).hostname
    for action in finder.actions:
        target = urlparse(urljoin(url, action)).hostname
        if target != host:
            print("  外部へ送るフォーム:", urljoin(url, action))


for u in sys.argv[1:]:
    check(u)

Python 3.14.7（Windows）で、ヘッダとフォームを模擬したローカルのサーバーに4ページ分を実行した結果が次のとおりです。

http://127.0.0.1:8765/
  X-Powered-By: PHP/8.3.30 → 未修正（8.3.36以上が必要）
http://127.0.0.1:8765/feature/
  X-Powered-By: PHP/8.4.27 → 修正版以上
  外部へ送るフォーム: https://form.example.net/fm/abc123/
http://127.0.0.1:8765/contact/
  X-Powered-By: なし → 版数の表示なし
  外部へ送るフォーム: https://form.example.net/fm/xyz789/
http://127.0.0.1:8765/old/
  X-Powered-By: PHP/7.4.33 → 7.4系は公式の修正版なし（要確認）

実際の店舗では、トップページ、特集ページ、問い合わせページのURLを引数に並べます。「外部へ送るフォーム」に出たURLが終了したサービスのものなら、そのページが撤去の対象です。決済や会員登録のように意図して外部へ送るフォームも同じく一覧に出るので、1件ずつ送り先を確かめます。

版数が見えないときと7.4系が出たときにフューチャーショップへ聞く項目

このスクリプトで分かるのは、ヘッダに出ている版数までです。版数を隠す設定は珍しくなく、「表示なし」は安全という意味ではありません。逆に、ディストリビューションが修正だけを取り込んだ場合は、古い版数のまま修正済みのこともあります。7.4系のように公式の修正版が無い版が出たら、判断を自分で下さずに問い合わせます。

聞く項目は、自店のCMSサーバオプションが動かしているPHPの版とPHP2Shellの修正状況、WordPress本体とプラグインの更新を誰が担うか、再構築でファイルが入れ替わったかの3つです。WordPress側の点検はWordPressセキュリティ対策：WP-CLIでの確認手順の手順がそのまま使えます。

SaaS型ECを預ける委託元の責任：個人情報保護法の報告と委託先の監督

自店のデータが漏れた場合に委託元として負う報告と、連名報告の実際

サーバーを運用しているのがフューチャーショップでも、会員の個人データを取り扱う事業者は店舗です。個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある行為による漏えい等は、件数にかかわらず報告の対象です。速報は発覚から概ね3〜5日以内、確報は不正の目的によるものは60日以内とされています。

今回のリンツの件は、委託先と店舗の連名で報告されました。4台の調査で自店のデータへのアクセスが分かった場合も、報告と本人への通知を判断するのは店舗です。報告の4類型と速報の書き方は個人情報保護委員会への報告義務と速報・確報の実務で解説しています。

契約と平時の確認で押さえる5項目：脆弱性の対応期限から調査結果の共有まで

個人情報保護法25条は、委託先に対する必要かつ適切な監督を委託元に求めています。SaaS型ECでは店舗が中を見られないため、確認は契約と問い合わせで行います。今回の事象から逆算すると、押さえる項目は次の5つです。

1. 重大な脆弱性の公表から対策までの期限と、停止を伴う場合の事前連絡
2. 侵害が疑われたときに店舗へ知らせるまでの時間と、その連絡経路
3. パスワードなどの保存方式と、アクセス記録の保存期間
4. 外部調査の結果のうち、店舗に共有される範囲
5. オプションや提携サービスの提供元と、終了時のデータ返却

5つ目は今回のフォームメーラーで表に出ました。提供元が別会社で、終了が当日に決まり、データの請求先も別でした。監督義務の範囲と契約条項の例は委託先管理とは：25条の監督義務とチェックリストにまとめています。管理サイト経由で他社の顧客に広がった同型の事案はスカラコミュニケーションズの不正アクセスが参考になります。

futureshopを続けるか移るか：最終報を待つ店舗と点検を急ぐ店舗の条件

移行を今決めないほうがよい理由と、それでも移行を検討する2つの場面

今の時点でカートの移行を決めるのは早すぎます。侵入経路も4台の影響範囲も未公表で、比べる材料がそろっていません。移行先でもSaaSである限り、委託先の脆弱性という構造は変わりません。EC基盤側で起きた別の大規模な先例として、ショップサーブ情報漏えいの最終報も比べる材料になります。

それでも移行を検討するのは2つの場面です。外部調査の結果で自店のデータへのアクセスが確認され、再発防止策に納得できない場合。もう1つは、CMSサーバオプションの古いPHPに依存したページが多く、今回のような停止で売上が止まる構造をこのまま抱えられない場合です。後者は、カートを替えるより先に、PHPのページを減らす改修で解消できることもあります。

自社で作ったPHPページや外部連携を持つ店舗が診断を入れるべき条件

外部の診断を入れるべきなのは、CMSサーバオプションに自社で作ったPHPのページやプラグインを置いている店舗、APIで受注管理や基幹システムとつないでいる店舗、そして4台の対象だった店舗です。運営会社の対策はサーバーまでで、店舗が置いたコードや連携先の設定は対象外だからです。

futureshopの標準機能だけで運営し、外部連携もない店舗なら、管理画面のパスワードと運営会社の続報の確認で足ります。過剰な診断に費用をかける必要はありません。PHPのページと連携先の設定をまとめて確かめたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

futureshopの不正アクセスについて、利用店舗と制作担当者から出やすい質問をまとめました。

自分の店舗が4台のサーバーの対象かどうかはどう確かめますか？

第一報では、対象店舗には個別に連絡するとされています。まず担当者と登録メールアドレスに運営会社からの連絡が届いていないかを確かめます。届いていない場合は、サポートセンターの問い合わせフォームから自店の利用サーバーを尋ねてください。メールのリンクからではなく、ブックマークなどから公式サイトを開いて確認します。

会員情報が漏えいした1店舗以外の店舗に、顧客への連絡義務はありますか？

自店のデータの漏えいやそのおそれが確認されていなければ、個人情報保護法上の報告や本人への通知の対象には当たりません。ただし、4台への不正アクセスは調査中です。対象だった店舗は調査結果を受けて判断し直す必要があります。問い合わせへの答え方は、公表事実だけを示し、断定を避ける形にしておくと後で訂正せずに済みます。

PHP2Shellがリンツの漏えいの原因ですか？

公式発表では、そうはされていません。リンツの件の侵入は10月17日で、PHPの修正版が公開された10月21日より前ですが、日付だけで関係を否定することもできません。フューチャーショップは、PHP2Shell対策のメンテナンス、4台への不正アクセス、1店舗の会員情報漏えいを別々の事象として説明しています。リンツの件で悪用されたソフトウェアの名前は公表されていません。

フォームメーラーが使えなくなった問い合わせはどう受けますか？

代わりのフォーム作成サービスの案内が届くまでは、フォームへのリンクを外し、メールアドレスや電話番号をページに載せて受け付けます。過去の保存データが必要なら、2027年1月29日までにフューチャースピリッツの窓口への連絡が必要です。新しいフォームを外部サービスで作る場合は、送り先のドメインと提供元を契約前に確かめておきます。

futureshopのAPIキーは再発行が必要ですか？

運営会社から全店舗に再発行の依頼は出ていません（10月28日時点）。4台の対象だった店舗は、APIも停止したサーバーで動いていたため、再発行を前倒しするのが安全側です。対象外の店舗は、連携先の一覧を作り、使っていない認証情報を止めるところまで済ませておけば、続報で再発行が必要になったときに半日で切り替えられます。

関連記事

• リンツ不正アクセス：314万件の対象確認とパスワード強制リセット後の対処：漏えいした1店舗の会員側の対処とパスワード保存方式
• PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、更新後も残す設定：今回のメンテナンスの原因になった脆弱性の詳細
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：連携の認証情報を回すときに
• 委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務：SaaS型ECとの契約で確かめる項目
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：自店のデータが対象になったときの報告手順