フィギュアメーカーのグッドスマイルカンパニーが運営する「グッドスマイルカンパニー公式ショップ」が第三者の不正アクセスを受け、決済ページに不正なプログラムが置かれていたことが分かりました。2026年10月30日の第4報では、2,800名のカード番号全16桁とセキュリティコードが漏えいした可能性があるとしています。前半では公表文とFAQをもとに、自分がどのグループに入るか、届くメールの件名、カードの再発行、問い合わせ先を整理しました。後半では、決済ページに載るスクリプトの変化をPythonで検知する方法と、読み込み自体を止めるCSPの設定を示します。
まとめ：グッドスマイルカンパニー公式ショップの漏えい範囲と利用者の対処
グッドスマイルカンパニーの第4報によると、システム開発・保守の委託先から10月23日午前6時過ぎに連絡があり、不正アクセスが判明しました。同日午前7時にサイトを閉鎖しています。原因は、システムの一部にあった脆弱性を悪用されて管理者権限を取られたことだと同社は説明しています。
被害は3つのグループに分かれます。最も深刻なのは、10月21日13時55分から23日7時までに決済ページでカード情報を入力した可能性がある2,800名です。この人たちはカードの利用明細を確かめ、再発行も考えてください。全員に共通する注意として、同社は自社や公的機関、金融機関を名乗る不審なメール・電話・SMSに応じず、リンクも開かないよう求めています。
| 区分 | 条件 | 漏えいした可能性のある情報 | 規模 |
|---|---|---|---|
| グループA | 過去にカードを登録した会員 | カード番号下4桁・有効期限 | 402,466枚（人数は確認中） |
| グループB | 10/21 13:55〜10/23 7:00に入力 | 名義人名・全16桁・期限・セキュリティコード | 2,800名 |
| グループC | 10/22 23時前までの出荷前の注文 | 氏名・住所・電話・メール・注文内容・金額・決済方法 | 5,356名の一部（202名以下） |
利用者が確かめること：グループA・B・Cの条件とメール件名、カードの再発行
カード登録会員のA、決済ページで入力したB、出荷前注文のCの見分け方
グループAは、公式ショップに一度でもカードを登録したことのある人です。グループA向けのFAQによると、漏れた可能性があるのはカード番号の下4桁と有効期限だけで、名義人名やセキュリティコードはデータベースに持っていなかったとしています。人数を確認中のため、Aの人には個別のメールを送っていません。メールが来ていなくても、登録したことがあれば対象です。
グループBは、10月21日13時55分から23日7時までの間に決済ページを開いてカード情報を入力した可能性がある人です。2,800名には、注文を完了した384名、予約商品の決済カードを変更した185名、決済を試みて完了しなかった人、ログインしてカートに入れただけの人が含まれます。グループCは、10月22日23時前までに注文して、まだ出荷されていなかった人です。楽天市場店での購入と、ねんどろいどフェイスメーカーは別のシステムで動いており、対象外とされています。
2,800名のグループBが今すぐ行うカード明細の確認と再発行手数料の扱い
グループBで漏れた可能性があるのは、名義人名・カード番号全16桁・有効期限・セキュリティコードの4つです。ネット通販の決済に必要な情報がそろっています。まずカードの利用明細やWeb明細を開き、身に覚えのない請求がないかを見てください。見つかったら、カード裏面に書かれたカード会社へすぐ電話します。
請求がなくても、再発行をおすすめします。グループB向けのFAQは再発行の検討を求め、再発行手数料が利用者の負担にならないよう、同社から各カード会社へ申し入れていると書いています。再発行の手続きは本人しかできないため、同社が代わりに申し込むことはできません。グループAについて同社は、下4桁と有効期限だけで決済するのは通常難しく、不正利用の可能性は極めて低いと説明しています。Aだけに当てはまる人も、明細は一度見ておいてください。
個別メールの件名2種と、名前や住所を知っている偽の連絡の見分け方
グループBの人には、次の件名のメールが届いています。「【重要】弊社ECサイトへの不正アクセスによるクレジットカード情報漏えいの可能性およびご対応のお願い」と「【重要】弊社ECサイトへの不正アクセスによるクレジットカード情報漏えいの可能性に関するお詫び」です。グループCの人には「【重要】弊社ECサイトへの不正アクセスによる注文情報漏えいの可能性に関するお詫び」が届きます。
本物のメールも、カードの再登録や本人確認のリンクを開かせる内容ではありません。グループCでは名前・住所・電話番号・注文内容が漏れた可能性があるため、偽の連絡は「ご注文の商品について」と実際の商品名を出してくることがありえます。相手が注文内容を知っていても、本物の証拠にはなりません。偽の連絡が成り立つ仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しています。
問い合わせはフォームのみ、PayPal・Amazon Pay利用者とサイト再開の時期
本件の窓口は「グッドスマイルカンパニー カスタマーサポート」のお問い合わせフォームで、公表文は電話番号を挙げていません。フォームは公式ショップとは別のシステムで動いていると同社は説明しています。閉鎖中も、10月発送予定の注文と予約商品は順次出荷されています。予約商品の決済エラーの通知が届いても、注文が自動でキャンセルされることはありません。
PayPalやAmazon Payで払った人は、支払いの情報が漏れたことは確認されていません。ただし出荷前の注文であれば、決済方法にかかわらずグループCに入る可能性があります。サイトの再開は、安全が確認でき次第あらためて案内するとしており、10月31日時点で日付は示されていません。
公表文から読む事案の構造：管理者権限の奪取と決済ページ改ざん、件数の訂正
10月19日の侵入から28日の改ざん判明まで、4回の公表で見る時系列
同社は10月23日の第1報から30日の第4報まで、4回にわたって公表を更新しています。第1報の時点では、カード情報は下4桁と有効期限だけとされていました。決済ページへの不正なプログラムが分かったのは10月28日18時30分過ぎで、判明までに閉鎖から5日かかっています。
| 日時 | 出来事 |
|---|---|
| 10月19日15時過ぎ | 不正アクセスが始まる（〜22日23時前） |
| 10月21日〜22日 | PHPの脆弱性に対応するメンテナンス |
| 10月21日13時55分 | 決済ページに不正なプログラムが置かれる |
| 10月23日6時過ぎ | 委託先の連絡で判明、7時にサイト閉鎖 |
| 10月23日 | 第1報、個人情報保護委員会へ報告 |
| 10月28日18時30分過ぎ | 決済ページの不正プログラムが判明 |
| 10月29日・30日 | 第3報（2,800名を公表）、第4報（件数を訂正） |
原因について同社は、第1報の追記と共通FAQで、最近報告されたPHPの脆弱性ではないと述べています。悪用された脆弱性の名称と侵入経路は公表されていません。
カード番号を保存していないのに全16桁が漏れた、決済ページ上の傍受
グループBのFAQで同社は、カード番号の全16桁・名義人名・セキュリティコードは保存していなかったと説明しています。それでも漏れたのは、決済ページに置かれた不正なプログラムが、利用者が入力した値をその場で読み取ったためです。データベースから盗まれたのではなく、入力画面の上で横取りされた形で、Webスキミングと呼ばれる手口にあたります。
カード情報を自社で持たない仕組みにしていても、入力欄が自社のページにある限り、そのページを書き換えられると防げません。カード番号を決済代行のトークンに置き換える方式は決済トークンの仕組みと実装方式で解説しましたが、トークンに変わる前の入力の瞬間は守れない点が今回の教訓です。公式ショップは2023年12月からEMV 3-Dセキュアを必須にしていました。3-Dセキュアは決済のときの本人認証なので、画面で読み取られた番号そのものの漏えいは止められません。同じ型の事案はPhotoGoodsの決済画面改ざんでも起きています。
第3報から第4報への訂正、操作の記録がないと対象を絞れない理由
グループCの件数は、第3報の「10月22日22時20分前ころから23時前ころまでに注文した7,673名」から、第4報で「出荷前の注文を持つ5,356名の一部（202名以下）」へ直されました。閲覧された注文は最大202件と分かったものの、どの202件かを特定できず、候補の7,774件を持つ5,356名全員にメールを送っています。
グループBでも同じことが起きました。決済を試みて途中でやめた人と、カートに入れただけの人を、システムが区別して記録していなかったためです。カートに入れただけの人にはカード情報の漏えいはないと同社は認めつつ、区別できないので2,800名に含めています。閲覧や操作のログを細かく残していれば、通知の対象はもっと絞れていたはずです。漏えいが起きた後の対応の重さは、平時のログ設計で決まります。
財産的被害のおそれと不正目的の2つで、件数を問わず報告が要る規定
個人情報保護法施行規則の第7条は、不正に使われると財産的被害が生じるおそれがある個人データの漏えい（第2号）と、不正の目的によるおそれがある漏えい（第3号）を、件数にかかわらず委員会への報告の対象にしています。カード番号の漏えいは前者に、第三者の不正アクセスは後者に該当する類型です。第8条により、速やかな速報の後、第3号の類型では60日以内に確報を出します。
同社は10月23日の時点で委員会に報告しており、カード会社と決済代行会社への報告はこれから進めるとしています。手続きの全体は個人情報保護委員会への報告義務の実務にまとめました。
開発側の対策：決済ページのスクリプトを台帳化し、変更をPythonで検知する手順
PCI DSS 4.0.1の要件6.4.3と11.6.1が決済ページに求める2つの管理
ここから先は、グッドスマイルカンパニーの仕組みを推測するものではありません。決済ページの改ざんに対しては、カード業界の基準であるPCI DSSの4.0系に、2つの要件があります。PCI SSCが2025年3月10日に公開した情報補足の案内は、決済ページのスクリプトが認可され、完全性を確かめられ、改ざんを監視されることを両要件の狙いとしています。
要件6.4.3は、決済ページに載るスクリプトを一覧にし、1本ずつ載せる理由を記録して、中身が変わっていないことを確かめる管理です。要件11.6.1は、利用者のブラウザに届くページとセキュリティに関わるHTTPヘッダーを見張り、無断の変更に気づく仕組みです。基準全体の構成はPCI DSSの12要件と準拠レベルで整理しました。
scriptタグの増減とSRI属性を台帳と突き合わせるPythonの変更検知
次のコードの実行に必要なのは、Pythonの標準ライブラリだけです。決済ページのHTMLを取り、外部JSはURLとintegrity属性の値、インラインJSは中身のSHA-256を台帳に登録する仕組みです。2回目以降は台帳と比べ、増えた・消えた・変わったスクリプトがあれば一覧を出して終了コード1を返します。cronで決済ページのURLに対して定期的に回し、1が返ったら担当者に通知する使い方を想定しています。
# 決済ページに載るスクリプトを台帳（baseline.json）と突き合わせ、増減と中身の変化を検知する
# （Python 3.9以上・標準ライブラリのみ。PCI DSS 11.6.1 の変更検知を最小構成で試すための例）
# 使い方: python checkout_watch.py init <URLまたはHTMLファイル> … 現状を台帳に登録
# python checkout_watch.py check <URLまたはHTMLファイル> … 台帳と比べ、差分があれば exit 1
import hashlib, json, re, sys, urllib.request
from pathlib import Path
BASE = Path("baseline.json")
def load(src):
if src.startswith("http"):
req = urllib.request.Request(src, headers={"User-Agent": "checkout-watch"})
with urllib.request.urlopen(req, timeout=20) as r:
return r.read().decode("utf-8", "replace"), r.headers.get("Content-Security-Policy", "")
return Path(src).read_text(encoding="utf-8"), ""
def inventory(html):
inv = {}
for attrs, body in re.findall(r"<script\b([^>]*)>(.*?)</script>", html, re.S | re.I):
m = re.search(r'src="([^"]+)"', attrs)
if m: # 外部JS: URLと integrity 属性の有無を記録
sri = re.search(r'integrity="([^"]+)"', attrs)
inv["src:" + m.group(1)] = sri.group(1) if sri else "no-sri"
else: # インラインJS: 中身のSHA-256で記録
inv["inline:" + hashlib.sha256(body.strip().encode()).hexdigest()[:16]] = "inline"
return inv
mode, src = sys.argv[1], sys.argv[2]
html, csp = load(src)
now = inventory(html)
if mode == "init":
BASE.write_text(json.dumps(now, indent=1), encoding="utf-8")
print(f"registered {len(now)} scripts")
sys.exit(0)
old = json.loads(BASE.read_text(encoding="utf-8"))
added = sorted(set(now) - set(old))
removed = sorted(set(old) - set(now))
changed = sorted(k for k in set(now) & set(old) if now[k] != old[k])
for k in added: print("ADDED ", k, now[k])
for k in removed: print("REMOVED", k)
for k in changed: print("CHANGED", k, old[k], "->", now[k])
if src.startswith("http") and "script-src" not in csp:
print("WARN Content-Security-Policy has no script-src")
print("result:", "ALERT" if added or removed or changed else "OK", f"({len(now)} scripts)")
sys.exit(1 if added or removed or changed else 0)動きを確かめるため、架空の決済ページを2つ用意しました。改ざん前は、決済代行のJS・自社のcheckout.js・計測用のインラインJSの3本です。改ざん後は、フォームの送信時に入力値を外部の画像URLへ送るインラインJSを1本足しています。Python 3.14.7（Windows）で実行した結果です。
$ python checkout_watch.py init checkout_before.html
registered 3 scripts
$ python checkout_watch.py check checkout_before.html
result: OK (3 scripts)
$ python checkout_watch.py check checkout_after.html
ADDED inline:ec5cdcea1e3c2e71 inline
result: ALERT (4 scripts)
$ echo $?
1実行結果の読み方と、サーバーから取得するだけでは見えない改ざん
改ざん前のページでは3本とも台帳と一致し、終了コードは0でした。不正なインラインJSを足したページでは、未登録のスクリプトが1本増えたことを示す「ADDED」が出て、終了コードは1です。足された1行は数十文字で、ページの見た目は何も変わりません。目で見る確認では気づけない改ざんでも、台帳との差分なら確実に出ます。
限界もあります。このコードはサーバーから返るHTMLを見るので、正規のJSファイルの中身を書き換える型や、特定の地域や端末にだけ不正なコードを返す型は捉えきれません。外部JSにSRIのintegrity属性を付けておくと、ファイルの中身が変わった時点でブラウザが読み込みを止めます。自社のJSファイルは、デプロイ時のハッシュと本番のハッシュを毎日比べる仕組みを別に用意してください。SRIの付け方はMDNのサブリソース完全性と外部スクリプトをSRI・CSPで安全に使う方法にあります。
CSPのscript-srcとimg-srcで、不正なJSの読み込みと送信先を止める設定
検知は事後の対策です。読み込み自体を止めるには、決済ページだけにContent-Security-Policyヘッダーを付けます。次はnginxの例で、決済代行のドメインと自社以外からのJSを禁じ、インラインJSはnonceを付けたものだけ動かします。
# 決済ページだけに掛けるCSP。決済代行のJSと自社のJS以外は読み込ませず、送信先も絞る
# （nginx の server ブロック内。js.psp.example 等は利用している決済代行のドメインに置き換える）
location /checkout/ {
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-$request_id' https://js.psp.example; connect-src 'self' https://api.psp.example; img-src 'self'; form-action 'self' https://api.psp.example; report-to csp-endpoint" always;
add_header Reporting-Endpoints 'csp-endpoint="https://shop.example.com/csp-reports"' always;
}先ほどの改ざん後のページにこのヘッダーが付いていれば、nonceのない不正なインラインJSは実行されません。仮に動いても、img-srcとconnect-srcで外部の送信先を絞っているので、入力値は外へ出ません。違反はReporting-Endpointsで指定した宛先に報告されるため、検知の役も兼ねます。nonceについては、サーバー側でscriptタグに同じ値を埋め込む処理が別に必要です。指定できる項目はMDNのコンテンツセキュリティポリシー、nonce方式の判断はCSPのnonce方式の設定とXSS防御で解説しています。
ただし、管理者権限を取られた後は、攻撃者がnginxの設定やCSPそのものを書き換えられます。CSPと変更検知は、権限を取られる前の守りと組み合わせて初めて効きます。
管理者権限を守る条件：クレジットカード・セキュリティガイドラインの5つの対策
ガイドライン6.1版がEC加盟店に求める脆弱性対策5項目と優先順位
日本のEC加盟店には、クレジットカード・セキュリティガイドライン6.1版（2026年3月11日改訂）が実務上の指針になります。ガイドラインは、カード情報を持たない非保持化の加盟店でも、管理者権限の管理などの不備から漏えいが起きているとして、次の5つを全て講じるよう求めています。
| 順 | ガイドラインの対策 | 具体的な中身 |
|---|---|---|
| 1 | 管理画面のアクセス制限とID管理 | 接続元IP制限・2段階認証・失敗10回以下でロック |
| 2 | Webアプリケーションの脆弱性対策 | 定期脆弱性診断・ソフト更新・コードレビュー |
| 3 | データディレクトリの設定不備対策 | 重要ファイルの非公開配置・アップロード拡張子制限 |
| 4 | マルウェア対策 | ウイルス対策ソフトの導入と定期的なフルスキャン |
| 5 | 有効性確認・クレジットマスター対策 | 附属文書20の対策を1つ以上 |
今回の事案は「脆弱性を悪用され管理者権限を取られた」と説明されているので、1番目と2番目が直接の論点です。管理画面への入口がAPIと共通の場合の固め方はAPI不正アクセス対策の実装手順にあります。
外部診断と決済方式の見直しを急ぐECサイトと、定期診断で足りるECサイト
次のどれかに当てはまるECサイトは、外部の脆弱性診断を急いでください。管理画面がインターネットからIDとパスワードだけで開けること。カードの入力欄が自社のページにあり、決済ページのスクリプトを一覧にしていないこと。開発や保守を委託していて、委託先がいつ何を更新したかを自社で追えないことです。入力欄を自社に置く必要がないなら、決済代行の画面に遷移させるリダイレクト型への切り替えも検討に値します。改ざんされうる自社のページから、カードの入力をなくせるからです。
管理画面を社内網か多要素認証に絞り、決済ページのスクリプトを台帳で監視しているなら、年1回の定期診断で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準にまとめました。自社のECサイトの管理画面や決済ページに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
グッドスマイルカンパニー公式ショップの不正アクセスについて、利用者から出やすい質問をまとめました。
自分がグッドスマイルカンパニーの情報漏えいの対象か、どうすれば分かりますか？
カードを入力した可能性があるグループBと、出荷前の注文があったグループCの人には、件名に「【重要】弊社ECサイトへの不正アクセスによる」で始まる個別メールが届いています。グループAは人数を確認中で個別メールは送られていないため、過去に公式ショップへカードを登録したことがあれば、メールが無くても対象です。迷う場合は、公表文にある問い合わせフォームから確かめてください。
クレジットカードは止めて再発行したほうがいいですか？
グループBに当てはまるなら、再発行をおすすめします。カード番号全16桁とセキュリティコードがそろって漏れた可能性があるからです。手続きはカード裏面のカード会社へ本人が申し込みます。同社は再発行手数料が利用者の負担にならないよう、カード会社に申し入れているとしています。グループAだけに当てはまる場合、同社は下4桁と有効期限だけによる不正利用の可能性は極めて低いと説明しており、まず明細の確認から始めれば十分です。
カートに入れただけなのに漏えいの可能性があるというメールが届いたのはなぜですか？
システムが「決済を試みて完了しなかった人」と「カートに入れただけの人」を区別して記録していなかったためです。同社は、期間中に決済ページでカード情報を入力していなければカード情報の漏えいはないとしています。入力した覚えがなければカードの再発行までは不要ですが、不安があれば明細だけは確かめておくと安心です。
楽天市場店やPayPal・Amazon Payで買った分も対象になりますか？
楽天市場店は別のシステムで運用されており、対象外です。PayPalとAmazon Payは支払いの情報の漏えいは確認されていません。ただし、公式ショップで注文して10月22日23時前の時点で出荷前だった場合は、決済方法にかかわらず、名前・住所・電話番号・注文内容が漏れた可能性があるグループCに入ることがあります。
公式ショップはいつ再開しますか？原因の脆弱性は何でしたか？
再開時期は、安全が確認でき次第あらためて案内するとされ、10月31日時点で日付は出ていません。原因は、システムの一部の脆弱性を悪用されて管理者権限を取られたことで、最近報告されたPHPの脆弱性ではないと同社は説明しています。脆弱性の名称と侵入経路は公表されていないので、続報は同社のサポートサイトで確認してください。
関連記事
- PhotoGoodsの不正アクセスとカード情報漏えい｜決済画面の改ざんとアップロード機能の締め方：同じく決済画面を改ざんされた事案
- 3Dセキュアとは？EMV 3-Dセキュア2.0の仕組みとCAVV・ECIの意味、Stripeでの実装を開発視点で解説：本人認証で防げることと防げないこと
- コンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説：決済ページに掛けるCSPの設計
- PCI DSSとは？12要件と準拠レベル・v4.0.1移行を発注視点で整理【2026年時点】：要件6.4.3と11.6.1を含む基準の全体像
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：カード情報の漏えいで求められる報告と本人通知
