Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Dashboard ↗ JA
Home / Critical Brief / No. 168
No. 168 Critical Brief · Verifiable Origin

Good Smile Company: A rogue program on the payment page, and card numbers and security codes may have been exposed

2,800
People whose cardholder name, full 16-digit number, expiry date and security code may have been exposed
About 41hours
How long the rogue program sat on the payment page (13:55 on 21 Oct to 07:00 on 23 Oct)
402,466cards
Cards whose last four digits and expiry date may have been exposed (excluding duplicates)
CountryJapan
Incident date2026-10-21
Published2026-11-02
AuthorsLemma Critical Team
Contents
  1. 01Summary
  2. 02What got through
  3. 03Pre-execution check
  4. 04What Lemma does
  5. 05Facts and timeline
  6. 06Sources

Summary

The company did not store card numbers, but a program placed on its payment page may have read them the moment they were typed. It closed the site an hour after the intrusion came to light, but the program itself came to light only five days later. If a payment page is rewritten, card numbers can be read the moment they are typed, even when they are not stored.

Exhibit 1Detection vs pre-execution check

A pre-execution check means matching, each time the payment page opens, whether the code running matches the approved version, and keeping a record. Detection means noticing unauthorised access after it happens.

Pre-execution check · not known from the disclosuresMatch the payment page's code to the approved version before entry
In betweenCustomers typed into the usual
screen from the genuine site
Detection · workedThe contractor reports the access; the site is closed
10-21
Program placed on the payment page
10-21 to 10-23
About 41 hours of possible interception
10-23
Site closed
10-28
Program found

What got through

What got through
A rogue program running on the payment page. It sat there from 13:55 on 21 October to 07:00 on 23 October, and the company believes information entered on the payment page during that time was intercepted.
What reached the receiving side
Customers’ browsers received the usual payment screen from the genuine site. In general, neither the appearance nor the connection to the site shows that the code inside the page has been changed.
Not disclosed
The type of vulnerability used to get in, whether the program ran in the browser or was a server-side change, where intercepted data was sent, and any fraudulent card use.

Pre-execution check

Whatever the route, the condition for telling them apart is that whoever serves the payment page matches the code running on it against the approved version before card details are entered.

The core of this case
What needs protecting is not the stored card number but the code of the page that receives the input.
Who approves
The owner of the payment page (the online store). At release, it approves the scripts the payment page loads, and hashes of their content, with a key separate from site administrator rights.
Where it is checked
The server that serves the payment page, and the customer’s browser (CSP and Subresource Integrity). Code that does not match the approved version is not loaded.
What is recorded
Which version of the payment page each payment action (starting entry, completing, changing the card) ran on. The customers affected can be narrowed down afterwards.

Closing the site also stopped the program, but what was noticed was the unauthorised access, not the change to the payment page. Code that reaches the screen being rewritten is an issue shared with Polymarket (JavaScript injected into the interface through a third party) and Stripe’s repurposed API (a trusted API used to deliver card-skimming code).

What Lemma does

Lemma builds the pre-execution check into the system that serves the payment page. It does not look for intrusions; it confirms that the page code being served now is the approved version.

Industries and operations to watch

IndustryServices & retail
Online stores with card fields on their own pages. Tampering with the page becomes interception of the input.
OperationOutsourced site development and maintenance
When changes to the payment page and admin rights are left to a contractor.

Current controls vs Lemma

It has not been disclosed whether the route in this incident was a script swap or a server-side rewrite of the page. The third column (a flaw in the approved version itself) is not the route here; it is a comparison for a different situation.

ControlScripts swapped or addedPage rewritten on the serverA flaw in the approved version itself
Not storing full card numbersNot relevantNot relevantNot relevant
Detecting access and closing the sitePartialPartialNot relevant
Patching the vulnerabilityPartialPartialNot relevant
Leaving the payment screen to an external processorPartial (embedded) / Effective (redirect, where the page has no card field)PartialNot relevant
Lemma (pre-execution check)Effective (if the approval key is held separately)Effective (if the approval key is held separately)Not effective

Not storing full card numbers protects stored data, and detection and closure work after the fact. Lemma checks the code running on the page itself, before card details are entered. PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 have also required authorisation of payment-page scripts and tamper detection since March 2025.

Note: Lemma’s check works only when it is built into the system that serves the payment page and the approval key is held separately from site administrator rights. It passes if the approval rights themselves are taken or the checking system itself is rewritten. The company believes administrator privileges were taken; in a server-side rewrite, the list or hashes the check relies on could be rewritten with the same privileges, so the check does not work unless the approval key is held elsewhere. The table compares what each control checks; it does not show whether this incident would have been stopped. Lemma does not detect or prevent intrusions.

CheckChecklist

Three points for your organisation to check about payment-page tampering on your online store

  • Are changes to the payment page kept from going live on site-admin rights alone?
  • If the payment page changes from the approved version, are you alerted the same day?
  • Can your records tell customers who tried to pay from those who only added items to the cart?

Facts and timeline

Site
Good Smile Company’s official online shop. Its Rakuten store is not included. The company says no exposure has been confirmed for payments made through Amazon Pay or PayPal; order information, however, is in scope whatever the payment method.
Cause
The company believes a vulnerability in part of its system was exploited and administrator privileges were taken. It says this was not the recently reported PHP vulnerability.
Why data that was not stored still leaked
Card-industry rules (per the PCI SSC FAQ) say security codes, which are authentication data, must not be stored after authorisation, and the company did not store them or full card numbers. It believes the exposure came from information entered on the payment page being intercepted. Attacks of this type are commonly called e-skimming.
Full card data possibly exposed
2,800 people — 384 who ordered by card, 185 who changed the card for a pre-order, those who tried to pay but did not complete, and those who only added items to the cart. With no record of operations, the last two cannot be told apart, so cart-only customers, who likely had no card data exposed, were contacted too. Customers who tried to change their card after ordering but did not complete it may also have had data exposed; the company says it likewise has no record and cannot identify them (fourth notice).
Partial card data
The last four digits and expiry of 402,466 cards (excluding duplicates) registered by customers.
Order information
Up to 202 viewed orders out of 7,774 orders from 5,356 people.

Timeline

  • Around 15:00, unauthorised access begins (until just before 23:00 on the 22nd).
  • At 13:55, the program is placed on the payment page.
  • Shortly after 06:00, the contractor’s report reveals the unauthorised access; the site is closed at 07:00. First notice (only the last four digits and expiry).
  • Second notice (addendum to the first).
  • Shortly after 18:30, the program on the payment page is found.
  • Third notice discloses possible exposure of full card data and security codes (order-information scope corrected in the fourth notice on the 30th).

Facts rest on the company’s official notices (first to fourth) and Q&As; “may have been exposed” is its wording. What has not been disclosed does not mean no measure was in place. As of 2 November, no fifth notice has been published.

After disclosure

  • Fix: Patched the suspected vulnerability and revoked and renewed all connection credentials between the system’s components. No reopening date.
  • Notices and reporting: Emailed affected customers individually and reported to the Personal Information Protection Commission. Says it is asking card companies not to charge customers reissue fees.

Sources

  1. Primary, company noticeGood Smile Company “Notice of Possible Exposure of Customer Information Due to Unauthorized Access (Fourth Update)”2026-10-30; partial correction of the third notice of 10-29 · support.goodsmile.com/hc/en-us/articles/63718007508761
  2. Primary, company noticeGood Smile Company “Notice of Possible Exposure of Customer Information Due to Unauthorized Access (Updated October 26, 2026)” (first notice 2026-10-23, second notice 10-26)support.goodsmile.com/hc/en-us/articles/63547468806297
  3. Primary, Q&AGood Smile Company “Group B: Customers Whose Full Credit Card Information May Have Been Exposed” (published 2026-10-29; content checked 11-02)support.goodsmile.com/hc/en-us/articles/63751588397849
  4. Primary, Q&AGood Smile Company “Frequently Asked Questions About Unauthorized Access and Information Exposure (All Customers)” (published 2026-10-29; content checked 11-02)support.goodsmile.com/hc/en-us/articles/63753982590105
  5. Primary, standards bodyPCI Security Standards Council “Coffee with the Council Podcast: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025”2025-03-26 · Requirements 6.4.3 and 11.6.1 take effect · blog.pcisecuritystandards.org/coffee-with-the-council-pod…
  6. Primary, standards bodyPCI Security Standards Council FAQ 1533, “For PCI DSS, why is storage of sensitive authentication data (SAD) after authorization not permitted even when there are no primary account numbers (PANs) in an environment?”security codes must not be stored after authorisation · pcisecuritystandards.org/faqs/1533
  7. Primary, company notice, JapaneseGood Smile Company「不正アクセスによるお客様情報流出の可能性について（第4報）」2026-10-30 · support.goodsmile.com/hc/ja/articles/63718007508761

References: The last layer left in AI-era cyber defense

The same method elsewhereSee all 9 "Privilege abuse" cases

This Brief sets out, from disclosed facts, what organisations in a similar position can check. It is not guidance on individual losses or procedures.

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"Good Smile Company: A rogue program on the payment page, and card numbers and security codes may have been exposed".
Lemma Critical Brief No.168. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/168-goodsmile-payment-page-tampering/
Read nextNext
Same control LiteLLM: v1.107.0, built from an attacker's fork, was distributed with a genuine signature Code Provenance Same control City of Baltimore: A fake contact posing as a supplier's employee was added to the supplier's account, and its bank account was switched (city Inspector General report) Attribute Proof Bypass Latest Binance: Unauthorised withdrawal transactions went through, and crypto was taken Agent Infrastructure
All Briefs →
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma is a pre-execution check: logins, payments, records and publishing that look genuine are checked before they run, with cryptographic proofs the receiving side verifies without asking the issuer. Detection stays; the check sits in front of it.

Talk to enterprise See the verification center