---
title: "PhotoGoodsの不正アクセスとカード情報漏えい｜決済画面の改ざんとアップロード機能の締め方"
url: "https://www.issoh.co.jp/tech/details/18205/"
published: 2026-10-09
updated: 2026-10-09
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# PhotoGoodsの不正アクセスとカード情報漏えい｜決済画面の改ざんとアップロード機能の締め方

写真からオリジナルグッズを作れるECサービス「PhotoGoods」を運営する大興印刷は2026年9月16日、第三者の不正アクセスにより、決済画面に入力されたクレジットカード情報などが漏えいした可能性があると公表しました。決済画面には、入力内容を盗み取るプログラムが2026年8月6日から9月11日まで置かれていたとされます。カルビーの「プロ野球チップス」をモチーフにしたオリジナルカードの注文にも使われていたサービスです。本記事では公表文をもとに経過と対象範囲を整理し、利用者が今日やる点検をまとめます。後半では、公表された原因であるファイルアップロード機能の悪用と決済画面の改ざんを、EC事業者が自社で防ぎ、早く気付くための設定例を示します。

## まとめ：PhotoGoodsの不正アクセスで確定した事実と利用者・EC事業者が今やること

確定しているのは、決済画面などに入力されたカード情報を不正に取得するプログラムが設置されていたこと、その原因としてシステム上の脆弱性とファイルアップロード機能の悪用による不正アクセスが確認されたことです。期間中に決済画面へカード情報を入力した人は、購入を完了していなくても対象になる可能性があります。一方、対象人数と実際の漏えい状況は調査中で、2026年10月9日時点で続報は出ていません。

利用者がまず行うのは、カードの利用明細の確認と、PhotoGoodsや大興印刷を装う連絡への備えです。EC事業者の側で見るべき論点は別にあります。アップロード機能から入られ、決済画面を書き換えられ、外部からの連絡を受けるまで約5週間気付けなかったという流れのどこで止められたかです。

| 項目           | 公表されている内容         |
| ------------ | ----------------- |
| 不正プログラムの設置期間 | 2026年8月6日〜9月11日   |
| 発覚のきっかけ      | 外部からの連絡（9月11日）    |
| 原因           | 脆弱性とアップロード機能の悪用   |
| カード情報        | 番号・有効期限・セキュリティコード |
| 対象人数         | 調査中               |
| サービス         | 停止中・再開時期未定        |

## 公表内容を時系列で確認する｜9月11日の連絡から9月16日の公表とサービス停止まで

### 9月11日の外部からの連絡と9月12日の緊急メンテナンスによる停止

大興印刷の[お詫びとお知らせ（2026年9月16日）](https://www.daiko-printing.co.jp/information/2037/)によると、発端は2026年9月11日、PhotoGoods内で不審な外部プログラムが読み込まれているという連絡を受けたことでした。システム管理会社が調査した結果、決済画面などに入力されたカード情報を不正に取得する機能を持つプログラムの設置を確認しています。

翌9月12日には[緊急メンテナンスのお知らせ](https://www.daiko-printing.co.jp/information/2008/)で、システム確認のためサービスを一時停止したと案内しました。この時点では理由の詳細に触れていません。4日後の9月16日に、不正アクセスと漏えいの可能性を正式に公表しています。2026年10月9日時点でも、[PhotoGoodsの公式サイト](https://photo-goods.com/)はサービス停止中の表示です。

### 公表された原因と実施済みの対応から読み取れるサイトへの侵入の範囲

公表文は原因を、システム上の脆弱性とファイルアップロード機能の悪用による第三者からの不正アクセスと説明しています。実施済みの対応として並ぶのは、サービス停止、不正プログラムの停止と削除、不正アクセスに使われた仕組みの隔離、不正な管理者アカウントの無効化、外部からのアクセス制限、システムとログの調査・保全です。

不正な管理者アカウントの無効化が含まれていることから、侵入者がサイトの管理権限を持つアカウントに届いていたことがうかがえます。ただし、どの脆弱性が使われたか、アップロード機能のどこが悪用されたか、プログラムがどこに埋め込まれたかは公表されていません。本記事では特定の製品や脆弱性に結び付けた推測はせず、後半では同じ構図を一般論として扱います。

### カルビーの位置付けと業務提携先のサービスで起きた事案の受け止め方

PhotoGoodsは、カルビーの「プロ野球チップス」をモチーフにしたオリジナルカードを注文できるサービスでもありました。カルビーも9月17日に、業務提携先での個人情報等の漏えいの可能性を公表しました（同社の告知PDFは2026年10月9日時点で取得できず、[ScanNetSecurityの報道](https://scan.netsecurity.ne.jp/article/2026/09/25/56305.html)で確認）。報道では、対象は店頭でプロ野球チップスを買った人ではなくPhotoGoodsの利用者で、利用者の個人情報は大興印刷が取得・保有していると説明されています。大興印刷の公表文でも、対象はPhotoGoodsの決済画面でカード情報を入力した人です。

## 漏えいした可能性のある情報を仕分ける｜カード情報・連絡先・パスワードの重さ

### セキュリティコードまで含まれるカード情報が意味する不正利用の起こりやすさ

公表文が挙げる情報は三つに分かれます。カード情報はカード番号、有効期限、セキュリティコードです。個人情報は氏名、住所、電話番号、メールアドレスで、ほかに会員パスワードに関する情報があります。

最も重いのはカード情報です。カード会社のサーバーではなく入力画面で盗まれるため、通常は保存しないセキュリティコードまでそろいます。番号・期限・コードがあれば、本人確認の弱いネットショップでは決済が通ってしまう状態です。氏名と住所も同時に漏れているため、請求先の一致を確かめる仕組みも突破されやすくなります。

### 変換して保存されていたパスワード関連情報と連絡先の悪用リスク

パスワードについては、元のパスワードを直接読み取れない形式に変換して保存した情報とされています。ハッシュ化で保管していたと読めますが、方式は明かされていません。短い文字列や辞書に載る語は方式によらず解読されやすいため、心当たりがある人は漏えいと同じ扱いにしてください。

連絡先は、PhotoGoodsや大興印刷、カード会社を装う連絡に使われる材料になります。注文履歴の確認や返金を口実にした連絡は、こうした事案の直後に増える典型です。

| 漏えいの可能性がある情報 | 想定される悪用       | 利用者の対処      |
| ------------ | ------------- | ----------- |
| カード番号・期限・コード | ネットでの不正決済     | 明細確認・再発行の相談 |
| 氏名・住所        | 請求先確認の突破・郵送詐欺 | 不審な郵便物に注意   |
| 電話番号・メール     | なりすましの連絡      | 公式サイトで確認    |
| パスワード関連情報    | 解読後の使い回し攻撃    | 使い回し先を変更    |

## 利用者が今日やる点検手順｜カード明細の確認と不審な連絡への対応を決めておく

### 2026年8月6日から9月11日に入力したカードの明細確認と再発行の相談

対象になりうるのは、2026年8月6日から9月11日にPhotoGoodsの決済画面でカード情報を入力した人です。購入を最後まで完了しなかった場合も含まれる点に注意してください。大興印刷は利用明細を確認し、身に覚えのない利用があればカード会社へ問い合わせるよう呼びかけています。

明細の確認は一度で終わらせず、数か月は続けてください。盗まれたカード情報は、まず少額の決済で使えるかを試され、その後に大きく使われることがあります。セキュリティコードまで漏れた可能性があるため、明細に異常がなくても、カード会社に事情を伝えて再発行を相談するのが確実です。

### PhotoGoodsや大興印刷を装う連絡とパスワードの使い回しへの対処

公表文は、PhotoGoodsや同社を装った不審なメール・SMS・電話に注意し、リンクや添付ファイルを開かず、情報を入力しないよう求めています。対象者への案内は対象範囲の確定後にメール等で順次送るとしているため、案内が届いても、中身の確認は同社の公式サイトのお知らせで行ってください。問い合わせ窓口の電話は078-303-7383（平日10時〜18時）です。

PhotoGoodsと同じパスワードを他サービスで使っている場合は、使い回し先から先に変更します。サービス停止中のためPhotoGoods側のパスワード変更手順は確認中とされており、変更できるのは他サービス側だけです。

## 決済画面に不正プログラムが置かれる仕組み｜アップロード機能から改ざんまでの経路

### アップロードした不正ファイルが実行されてサイトを書き換えられる流れ

ここからは今回の事案を離れ、同じ型の攻撃の一般的な流れを説明します。画像などを受け付けるアップロード機能で、拡張子や中身の検証が甘く、保存先でプログラムが実行できる設定になっていると、攻撃者はサーバー上で命令を実行するファイルを置けます。いわゆるWebシェルです。

Webシェルからは、サイトのテンプレートやJavaScriptファイル、データベースに入った画面部品を書き換えられます。管理者アカウントを追加して、正規の管理画面から改ざんを続けることも可能です。こうして決済画面に、入力欄の値を読み取って外部のサーバーへ送るスクリプトが加わります。購入者の画面は普段どおりに動くため、利用者も事業者も気付きにくいのが特徴です。

### カード情報を保持しない決済方式でも加盟店の入力画面で盗まれる理由

日本クレジット協会の[クレジットカード・セキュリティガイドライン6.0版（2025年3月）](https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines%5F6.0%5Fpublished.pdf)は、カード情報を加盟店で保持しない非保持化を実現したEC加盟店でも、Webサイトの脆弱性を原因とした窃取が起きていると指摘しています。非保持化の方式には、決済代行会社の画面へ遷移させるリダイレクト型と、加盟店の決済画面に決済代行会社のJavaScriptを組み込むJavaScript型（トークン型）があります。

JavaScript型では、カード番号を入力する画面そのものは加盟店のサイトが配信しています。サーバーにカード情報が届かなくても、画面を書き換えられれば入力の瞬間に読み取られます。リダイレクト型は入力画面が決済代行会社側にあるため、この経路の影響を受けにくい方式です。ただし、遷移前のページを書き換えて偽の決済画面へ誘導される余地は残ります。外部送信型の攻撃は[ショップサーブの情報漏えい](https://www.issoh.co.jp/tech/details/16098/)でも扱っています。

## アップロード機能を入口にしない実装｜保存先・ファイル名・実行権限の三点を締める

### OWASPの推奨に沿ったアップロード画像の検証と安全な保存先の決め方

[OWASPのFile Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File%5FUpload%5FCheat%5FSheet.html)は、許可する拡張子を業務上必要なものに限ること、Content-Typeはユーザーが偽装できるため信頼しないこと、保存名はアプリが生成したランダムな文字列にすることを推奨しています。保存先の優先順位は、別ホスト、Webroot（公開ディレクトリ）の外、Webrootの中の順です。単一の対策では足りず、複数を組み合わせるよう強調しています。

次はPythonとPillowで、画像を実際に読み込んで形式を確かめ、再エンコードしてランダムな名前で公開ディレクトリの外へ保存する例です。再エンコードで画像の後ろに付け足された不正なコードを落とせますが、OWASPはこれですべての悪意ある内容が除けるとは限らないとしています。

```
# アップロード画像を検証し、ランダム名で公開ディレクトリの外へ保存する
import uuid
from pathlib import Path
from PIL import Image

ALLOWED = {"JPEG": ".jpg", "PNG": ".png"}
STORE = Path("/srv/upload-store")  # Webサーバーが配信しない場所

def save_upload(fileobj):
    with Image.open(fileobj) as img:
        fmt = img.format
        if fmt not in ALLOWED:
            raise ValueError("許可していない形式です")
        img.load()
        clean = img.copy()
    name = uuid.uuid4().hex + ALLOWED[fmt]
    clean.save(STORE / name, format=fmt)
    return name
```

利用者が付けたファイル名は保存に使わず、表示が必要なら別の列に持ちます。ガイドライン6.0版も、公開ディレクトリに重要なファイルを置かないことと、Webサーバーやアプリでアップロード可能な拡張子やファイルを制限することを求めています。

### nginxでアップロード先のスクリプト実行を止める設定と確認方法

公開ディレクトリに保存せざるを得ない構成では、Webサーバー側でその場所のスクリプト実行を止めます。nginxでは[locationディレクティブ](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fcore%5Fmodule.html#location)の`^~`を使うと、そのプレフィックスに一致したときに外側の正規表現locationを評価しません。PHPを処理する`location ~ \.php$`がserver直下にあっても、アップロード先には適用されなくなります。

```
# アップロード先ではスクリプトを実行させない
location ^~ /uploads/ {
    location ~* \.(php|phtml|phar|cgi|pl)$ {
        return 403;
    }
    add_header X-Content-Type-Options nosniff;
}
```

設定後は`nginx -t`で構文を確かめてから再読み込みし、アップロード先に置いたテスト用の.phpファイルへのアクセスが403になることを確認してください。Apacheなら、アップロード先でディレクトリ単位の設定上書きを無効にする`AllowOverride None`をOWASPが挙げています。アップロード機能の侵害が別の形で表れた事例として[Gyazoの不正アクセス](https://www.issoh.co.jp/tech/details/17839/)も参考になります。

## 決済画面のスクリプトを固定して改ざんを検知する｜CSP・SRI・差分監視の設定例

### CSPをReport-Onlyで入れて決済画面が読み込む外部スクリプトを洗い出す

[CSP（Content Security Policy）](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)は、ページが読み込めるスクリプトや通信先をブラウザに伝えるレスポンスヘッダーです。決済画面では、スクリプトの読み込み元と、入力値を送れる通信先・フォームの送信先を絞ります。いきなり強制すると正規の機能が止まるため、[Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy-Report-Only)で違反を報告させるところから始めます。

```
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://js.psp.example; connect-src 'self' https://api.psp.example; form-action 'self'; report-to csp
Reporting-Endpoints: csp="https://shop.example.com/csp-reports"
```

数週間の報告で正規の読み込み元がそろったら、ヘッダー名を`Content-Security-Policy`に替えて強制します。決済代行会社のドメインは、自社が契約している会社の導入資料で確かめてください。nonce方式の詳しい書き方は[コンテンツセキュリティポリシー（CSP）とは](https://www.issoh.co.jp/tech/details/16358/)、外部スクリプトの許可の考え方は[3rd-party JavaScriptとCSPの安全な扱い方](https://www.issoh.co.jp/tech/details/1465/)で解説しています。

### SRIで自社配信のJavaScriptの改ざんを読み込み時点で止める

[SRI（Subresource Integrity）](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource%5FIntegrity)は、script要素のintegrity属性にファイルのハッシュを書き、中身が一致しないときに実行させない仕組みです。指定できるのはsha256・sha384・sha512で、別オリジンから読む場合はCORSの許可とcrossorigin属性が要ります。ハッシュはMDNに載っている次のコマンドで作れます。

```
openssl dgst -sha384 -binary checkout.js | openssl base64 -A

<script src="/assets/checkout.3f9a.js"
        integrity="sha384-（上のコマンドの出力）"
        crossorigin="anonymous"></script>
```

決済代行会社が提供するスクリプトは、予告なく中身が更新される場合があり、ハッシュを固定すると決済が止まります。SRIは版番号付きで自社が配信するファイルに使い、外部のものはCSPで読み込み元を絞る、という分担が現実的です。

### 決済画面のスクリプト構成を基準と比べて変化を通知する差分監視

CSPとSRIは、サーバーを乗っ取られてヘッダーやHTMLまで書き換えられると外されます。そこで、外部から決済画面を定期的に取得し、読み込むスクリプトの一覧が基準と変わったら通知する監視を別系統で置きます。

```
#!/bin/bash
# 決済画面が読み込むスクリプトの一覧を基準と比べ、変化があればログに警告を出す
curl -s "https://shop.example.com/checkout" -o page.html
grep -oE 'src="[^"]+"' page.html | sort -u > scripts_now.txt
if ! diff -u scripts_baseline.txt scripts_now.txt; then
  logger -t checkout-watch "決済画面のスクリプト構成が変わりました"
fi
```

この方法は、特定の利用者にだけ不正なスクリプトを返す改ざんや、ページ表示後にJavaScriptで差し込まれる改ざんを見落とします。実ブラウザで画面を描画して読み込まれた通信を記録する方式や、商用の改ざん検知サービスと組み合わせてください。今回の事案は外部からの連絡で発覚しており、自社の監視で気付ける体制があれば、約5週間という設置期間は短くできた可能性があります。

## EC事業者に求められる対策の基準｜ガイドライン6.0版の5項目とPCI DSSの要件

### クレジットカード・セキュリティガイドライン6.0版がEC加盟店に求める脆弱性対策

ガイドライン6.0版は、2025年4月以降、既に契約している加盟店も含めたすべてのEC加盟店に、次の5項目の脆弱性対策をすべて講じるよう求めています。カード情報の保持・非保持を問わない対策と位置付けられています。

| 項目         | 主な内容                 |
| ---------- | -------------------- |
| ①管理画面の制限   | IP制限・多要素認証・10回以下でロック |
| ②設定不備への対策  | 公開ディレクトリの整理・拡張子の制限   |
| ③Webアプリの対策 | 定期診断・更新・コードレビュー      |
| ④マルウェア対策   | ウイルス対策ソフトの導入と運用      |
| ⑤有効性確認への対策 | 附属文書20の対策を1つ以上       |

今回公表された原因は、①の管理者アカウント、②のアップロード制限、③の脆弱性のいずれにも関わります。ECシステムの構築・運用を外部に委託している場合、ガイドラインは委託先にも同じ脆弱性対策を理解したうえでの構築・運用を求めるよう定めています。

### PCI DSS要件6.4.3と11.6.1が決済画面のスクリプト管理に求めること

国際基準のPCI DSSでは、v4.0で加わった要件6.4.3と11.6.1が2025年3月31日から全面適用されています。PCI SSCは2025年3月10日のブログで、両要件の手引きとなる補足文書[Payment Page Security and Preventing E-Skimming](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming)を公開しました。決済画面のスクリプトが承認され、完全性を確かめられ、改ざんを監視されている状態を求める内容で、前の章のCSP・SRI・差分監視はこの考え方に沿っています。要件全体の構成は[PCI DSSとは](https://www.issoh.co.jp/column/details/13185/)で整理しています。

### 決済画面の保護を自社で抱える条件と決済方式の変更で範囲を絞る判断

JavaScript型で自社の決済画面を持ち、画像やファイルのアップロード機能も備えたECサイトなら、アップロードの締め付け、CSPと差分監視の三つをすべて入れるべきです。入口と改ざんの両方が自社の画面にあり、どちらか一つでは今回のような経路を止めきれないからです。[WAF](https://www.issoh.co.jp/tech/details/13275/)は既知の攻撃パターンを止める層として加えます。

一方、注文数が少なく画面のカスタマイズもしていないなら、リダイレクト型へ切り替えて決済画面そのものを自社から外すほうが、監視を自前で回すより確実です。その場合も、管理画面の多要素認証とアップロード制限はガイドラインの必須項目として残ります。パッケージを使っている場合は、[EC-CUBE 4系のMFAバイパス脆弱性](https://www.issoh.co.jp/tech/details/11295/)のように管理画面側の更新情報も追ってください。

漏えいが起きた場合、カード情報は財産的被害のおそれがある個人データにあたり、不正アクセスによるものは不正目的の類型にも入ります。報告の段取りを解説した記事は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)です。アップロード機能から決済画面までの経路を第三者の目で確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、管理画面とアップロード処理を含めて点検できます。診断の種類と費用感は[脆弱性診断とは](https://www.issoh.co.jp/column/details/13101/)で比較できます。

## よくある質問

PhotoGoodsの不正アクセスについて、利用者とEC事業者から出やすい質問をまとめました。

### プロ野球チップスを買っただけでも対象になりますか？

大興印刷の公表文で対象になりうるとされているのは、2026年8月6日から9月11日にPhotoGoodsの決済画面でカード情報を入力した人です。購入を完了しなかった場合も含まれます。報道によると、カルビーも対象は店頭でプロ野球チップスを買った人ではなくPhotoGoodsの利用者だと説明しています。

### カードを止めたり再発行したりする必要はありますか？

大興印刷は利用明細の確認と、身に覚えのない利用があった場合のカード会社への連絡を案内しています。ただし今回はセキュリティコードまで漏えいした可能性があるため、該当期間に入力した人は、明細に異常がなくてもカード会社に事情を伝えて再発行を相談するのが安全です。

### 何件のカード情報が漏えいしたのですか？

2026年10月9日時点で件数は公表されていません。対象範囲と実際の漏えい状況は調査中とされ、確定後に対象者へメール等で順次案内するとしています。新しい事実や再開時期が分かった時点で、同社のホームページで知らせる予定です。

### PhotoGoodsはいつ再開しますか？

再開時期は未定です。大興印刷は安全な環境へのシステム再構築、認証情報の変更、脆弱性対策を進めており、安全性が確認できるまで再開しないとしています。過去の注文履歴の表示や再注文の方法も確認中です。

### 自社のECサイトで同じ被害を防ぐには何から始めればよいですか？

最初に、アップロードを受け付ける機能をすべて洗い出し、保存先でスクリプトが実行できないかを確認してください。次に管理画面のIP制限と多要素認証を入れ、決済画面にCSPをReport-Onlyで入れて読み込み元を把握します。最後に、決済画面のスクリプト構成を外から定期的に比べる監視を置きます。

## 関連記事

- [ショップサーブの情報漏えい最大885万件｜対象の確かめ方とサーバー侵害・外部送信の技術解説](https://www.issoh.co.jp/tech/details/16098/)：EC基盤の侵害と外部送信を扱った事例
- [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：アップロード基盤が起点になった同時期の事例
- [タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)：同時期の会員情報流出と保管設計
- [コンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説](https://www.issoh.co.jp/tech/details/16358/)：決済画面に入れるCSPの書き方
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時の報告の段取り

---

出典: [PhotoGoodsの不正アクセスとカード情報漏えい｜決済画面の改ざんとアップロード機能の締め方](<https://www.issoh.co.jp/tech/details/18205/>)（株式会社一創）