Treasure Factory Breach: 746,277 Customer Emails From a Case System

Treasure Factory, the Japanese reuse retailer behind the Torefac brand, says an attacker abused a database access vulnerability in its home pickup and moving case system on 20 October 2026 and took 746,277 customer records, mostly email addresses. Customers should expect targeted phishing. Teams running public order systems should review database access paths now.

Below is what Treasure Factory said in its two notices of 23 October, what the press added, and what defenders can and cannot take from it. Public technical detail is thin: no product, code path, CVE, attacker or indicators of compromise have been published, and we do not guess at them.

One point the company made on its own initiative is worth stating up front. Treasure Factory says the intrusion did not exploit the recently published PHP vulnerability and has no connection to it. We take the company at its word: this post does not treat the incident as linked to that PHP flaw in any way.

What happened

Treasure Factory Co., Ltd. (株式会社トレジャー・ファクトリー) is listed on the Tokyo Stock Exchange Prime market under code 3093. It runs second hand stores under the Torefac (トレファク) name, a home visit buyback service called Shutchō Kaitori (出張買取), and a moving service called Torefac Hikkoshi (トレファク引越). Customers book pickups and moves through web application forms, and those bookings are handled in what the company calls a case management system (案件管理システム).

According to the company's timely disclosure to the Tokyo Stock Exchange and its matching customer notice, both dated 23 October, a review of the case system's access logs on 20 October showed that a third party had exploited a vulnerability between the small hours and the morning of that day and taken customer and other data. The company stopped external access to the system at 10:30 and the application forms at 11:05, changed passwords on related accounts, and began fixing the vulnerability, hardening login and increasing monitoring. It is reporting to the Personal Information Protection Commission (PPC), consulting the police, working with an outside security specialist, and plans to restart around 28 October after safety checks.

Timeline

The PDF metadata time is the time the document was produced, not necessarily the time it was released. We list it because it is the only minute level timestamp the company itself has attached to 23 October.

What was taken

The disclosure lists three categories of data. They are different kinds of record, so adding them together does not give a count of people.

The company also states what was not taken:

• The customer records obtained contain no credit card numbers, security codes or other payment information. The company says it has confirmed this.
• Customer information held at stores and customer information managed in the Treasure Factory app sit in separate systems from the case management system and are not part of this incident.
• As of 23 October, no misuse of the personal information or other specific secondary harm had been confirmed.

Media reporting rounded the headline number in different ways. Nikkei's headline said about 700,000 records while its body said about 740,000 email addresses; Daily Sports and Niigata Nippo said about 750,000. The company's own figure is 746,277, and that is the number to use.

Who is affected

The cause, as stated

The company's wording on cause is short. Its current view is that a vulnerability related to access to the database (データベースへのアクセスに関する脆弱性) was exploited by a third party. The detailed cause and scope are still under investigation.

The disclosure then addresses the PHP vulnerability published earlier this month. It says the access did not exploit the recently published PHP vulnerability and, in its words, it has "confirmed there is no connection to that vulnerability" (当該脆弱性との関連はないことを確認しております). A Japanese security news report reads that sentence as a reference to the PHP flaw widely called PHP2Shell. The company's statement stands on its own: whatever the vulnerability was, it is not that one.

The disclosure also separates this incident from the August incident at its subsidiary. It says the earlier case started with a staff account's credentials being stolen through phishing, while this case involved a vulnerability in database access, so the two have different causes and different points of entry.

What the company has not said:

• the name or vendor of the case management system, or whether it is built in house, packaged or hosted
• whether the vulnerability is in application code, a framework, a library, a database driver, an exposed database interface or an access control check
• any CVE identifier or advisory
• how the data left (one large query, many small requests, an export function or something else)
• how many requests were made, from where, or with what client
• any IP addresses, domains, hashes or user agents
• who the attacker is, and whether there has been any ransom demand or data sale

That same report notes that there is no basis yet to conclude the attack was SQL injection or any other specific vulnerability type. We agree, and the rest of this post treats the possibilities as possibilities.

Technical details

This section collects every concrete, defender useful value the primary sources contain. It is short because the sources are. No CVE, version number, hash, IP address, domain or user agent has been published for this incident. If you see indicators circulated as belonging to it, check where they came from before acting on them.

Values published by the company

What the 35 minute gap tells you

External access to the case management system stopped at 10:30. The application forms stopped at 11:05. That ordering suggests the forms and the case system are separate components: customers submit through a public form, and the form hands records to a back office system that staff and suppliers use. The company has not described its architecture, so treat this as a reading of the timeline, not a fact. It does match the shape of many pickup and moving businesses, where a public form feeds a case queue, and field staff and partner companies use devices to view and update cases.

That reading matters because it means two internet facing surfaces: the public form, and the external access path to the back office system. The company cut the second one first.

What the data mix tells you

The three data categories are a useful clue about what was reachable, without telling us how.

• 746,277 records with only an email address is a shape you get from a lightweight inquiry or booking record, where most people never got as far as a confirmed appointment with an address on file. Only 11 records carry name and address.
• 750 supplier and staff records with name and email look like a user or contact table.
• 1,000 device records with name and identifier look like a device registration table.

Data from three different tables suggests the attacker could read more than one table through the vulnerable path. That is consistent with database credentials that had read access across the schema, or an interface that let the caller pick what to read. It is not proof of either. The same report also points out that 1,000 device identifiers being read does not mean 1,000 devices were compromised.

Possible vulnerability classes, as possibilities only

The phrase "a vulnerability related to database access" covers several common classes. The table below lists them so defenders can check their own systems. None of these is a finding about Treasure Factory.

How a case system ends up holding 746,277 email addresses

Nothing here is specific to Treasure Factory; it is the common pattern. Each form submission becomes a case, and many cases never go ahead because the customer only wanted a quote or chose someone else. Those rows keep an email address and little else, and over years the table grows to hundreds of thousands of entries, while only the small share of jobs that proceed collect a name and address. The result is a large table of low sensitivity rows in a system that has to be reachable from outside, because field staff and partners use it.

Two incidents, two different doors

The group has now disclosed two incidents in two months. The company is clear that they have different causes, and so are we. They are worth reading side by side because together they cover the two most common ways into a retailer's customer data.

According to Netshop Impress, the Kindoru data included contact details, date of birth and purchase and point history, but no card data or EC site passwords. A security news report says the third report states that passkey based two factor authentication was rolled out to all staff accounts. The two counts should not be added together; the Kindoru figure counts people, and the October figure counts records.

After August, the company says, it reviewed two factor authentication, access rights, export permissions and monitoring across the group. The October disclosure adds controls for internet facing systems: vulnerability management and assessments, WAF style defences, and application and database security. Identity controls close one door and exposure management closes the other; you need both.

What to do now

If you are a customer

1. Do not click links in emails or text messages about a pickup, appraisal, payment or move unless you were expecting them. The company's own notice gives the same advice.
2. Do not open unexpected attachments, and do not enter passwords or card numbers on a page reached from a message link. Type the official address yourself.
3. If someone calls about a booking, hang up and call back on the official number from the company's website.
4. Watch the company's website for the dedicated inquiry desk. As of 23 October it was being set up and no phone number had been published for it.

If you run a similar public order or case system

The steps below are generic checks any team can run this week. They assume a typical web application with a relational database behind it. Adapt paths and names to your stack.

1. List every way the database can be reached from outside.

# Ports listening on the application and database hosts
sudo ss -tlnp

# From an outside network you control, check your own public IPs for database ports
nmap -Pn -p 1433,1521,3306,5432,6379,9200,27017 your.public.ip.address

# Check whether common database admin paths answer on your own sites
for p in /phpmyadmin/ /pma/ /adminer.php /pgadmin/ /dbadmin/; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://your-site.example$p"
done

Anything other than a 404 or a deliberate block on those admin paths deserves a closer look. Run these only against systems you own or are authorised to test.

2. Check what the application's database account can read.

-- MySQL or MariaDB
SHOW GRANTS FOR 'app_user'@'%';

-- PostgreSQL: table level privileges for the application role
SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_user'
ORDER BY table_schema, table_name;

-- SQL Server
EXEC sp_helprotect @username = 'app_user';

If the account that serves the public form can also read staff, partner and device tables, split it. The OWASP SQL Injection Prevention Cheat Sheet recommends a separate database user per application, read only accounts limited to the tables they need, and views that expose only the required columns.

3. Find string built SQL in your code.

# Rough searches; expect false positives, review each hit
grep -rnE "(query|execute|exec)\(\s*[\"'].*(SELECT|INSERT|UPDATE|DELETE).*[\"']\s*(\+|\.|%)" src/
grep -rnE "f[\"'](SELECT|INSERT|UPDATE|DELETE) " src/
grep -rnE "\\\$wpdb->query\(|mysqli_query\(|->query\(\s*\"" src/

Replace any match that concatenates request data into SQL with a parameterised query or a prepared statement. That is the first primary defence in the OWASP cheat sheet.

4. Look for bulk reads in your web logs.

# Requests per client IP to API or case endpoints, busiest first
awk '$7 ~ /\/(api|case|admin)\// {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Responses larger than 1 MB on those endpoints
awk '$7 ~ /\/(api|case|admin)\// && $10 > 1000000 {print $4, $1, $7, $10}' /var/log/nginx/access.log | head -50

# Sequential ID walking: many distinct IDs from one client in one hour
awk '$7 ~ /\/case\/[0-9]+/ {split($4,t,":"); print $1, t[2]}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Field positions assume the default combined log format. Look especially at the hours when your own staff are not working, since the Treasure Factory intrusion happened between the small hours and the morning.

5. Look for bulk reads in the database itself.

-- PostgreSQL with pg_stat_statements enabled
SELECT calls, rows, mean_exec_time, left(query, 120) AS query
FROM pg_stat_statements
ORDER BY rows DESC
LIMIT 20;

-- MySQL 8: statements that returned the most rows
SELECT DIGEST_TEXT, COUNT_STAR, SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_ROWS_SENT DESC
LIMIT 20;

A statement that returns hundreds of thousands of rows to the web application account, when no feature needs that, is a finding whether or not it was malicious.

6. Turn on the logs you would need. If the queries above returned nothing because logging was off, fix that first.

# PostgreSQL: log slow statements and connections (postgresql.conf)
# log_min_duration_statement = 500
# log_connections = on
# log_disconnections = on
# shared_preload_libraries = 'pg_stat_statements'

# Confirm your web server keeps enough history
ls -lh /var/log/nginx/ && grep -E "rotate|daily|weekly" /etc/logrotate.d/nginx

Treasure Factory found its intrusion in access logs on the same day. That only works if the logs exist, record enough, and are kept long enough to compare against.

7. Add volume limits to read paths. Cap how many records a single session or API key can read per minute and per day, and alert when the cap is hit. This does not fix a vulnerability, but it turns a full table copy into a partial one and creates a signal.

8. Review retention. Delete or archive email addresses for cases that never went ahead after a period you can justify. Rows that do not exist cannot be taken.

9. Rotate what may have been seen. If a similar system may have been read, rotate the application's database credentials, API keys stored in the database and any device enrolment secrets.

10. Check your third party and dependency inventory. If your case system is a packaged product or built on a framework, find out which version you run and whether the vendor has issued advisories. A software bill of materials makes this question fast to answer; see our post on using SBOMs to find affected products fast.

If you are in Japan: the reporting clock

The PPC's guidance says a leak must be reported when it involves sensitive data, data that could cause financial harm, an act with a wrongful purpose such as unauthorised access, or more than 1,000 people. An incident like this meets at least two of those tests. The PPC asks for a preliminary report within about three to five days of discovery, and a confirmed report within 30 days, extended to 60 days where the leak came from a wrongful act. Treasure Factory says its PPC report is in progress.

What changed since the first reports

• Early press copy rounded the customer count to about 700,000, 740,000 or 750,000. The company's figure is 746,277 email address records, 11 with name and address.
• Some early copy mentioned only email addresses. The disclosure also lists 750 partner and staff records and 1,000 device records.
• The dedicated inquiry desk was still being prepared on 23 October, and a separate notice that day said some services were suspended for emergency maintenance without listing which ones.

Open questions

• Which product or code contained the vulnerability, and is it a packaged product other companies also use? If it is, a vendor advisory may follow.
• Was the flaw in authentication, authorisation, query construction or exposure of a database interface?
• How did the data leave, and over what period within the small hours to morning window?
• What kind of identifier is the device identification information, and is it used for authentication anywhere?
• Will the customer count change as the investigation continues?
• Will there be any financial impact? The company says the effect on consolidated results is under review.
• Has the data appeared anywhere for sale? No public source says so.

What would have helped

Lessons below are for any team that runs a similar system. They are not a judgement of what Treasure Factory did or did not do, and the company's own early detection deserves credit: it found the access in its logs within hours and cut external access the same morning.

Practices any team can use

Inventory every public entry to customer data. Most teams know their marketing site and their store. Fewer have a current list of the form handlers, partner portals, field staff apps and back office tools that are reachable from the internet and touch the same database. Build that list, assign an owner to each item and review it every quarter.

Give each function its own database identity. A public form needs to insert rows. A field staff view needs to read assigned cases. Neither needs to read the partner contact table or the device table. Separate accounts with narrow grants turn a single bug into a partial leak instead of a full one.

Parameterise every query, and test that you did. Prepared statements are the first defence in the OWASP guidance and the first item in IPA's Secure Website guide. Add a static check in CI that fails on string built SQL, so the rule survives staff changes.

Check authorisation on every object read. Broken object level authorisation is first in the OWASP API Security Top 10 for a reason. If an endpoint takes a case ID, it must check that the caller is allowed to see that case. Write a test that asks for someone else's case and expects a refusal.

Keep and watch access logs. Treasure Factory's detection came from access logs. Keep web and database logs long enough to investigate, ship them somewhere an attacker on the application host cannot erase them, and alert on volume outliers outside working hours.

Patch and rebuild public systems on a schedule. The company's own fix list starts with vulnerability management and assessments for externally exposed systems. Know which framework, library and runtime versions each public system runs, rebuild when fixes land, and run an authenticated assessment at least once a year and after major changes.

Treat identity and exposure as one programme. The August incident came through a phished account without two factor authentication. The October incident came through a vulnerable public system. Group wide controls need to cover both: phishing resistant two factor authentication and export limits for staff accounts, and exposure management for public applications.

Where Safeguard fits

Safeguard works on the software you build and ship: source repositories, container images and SBOM files. Where the vulnerable code in a case like this is your own application or an open source dependency inside it, Safeguard can help in the following ways.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image, and safeguard scan --sbom <file> reads an existing SBOM. Results are written as JSON under ./output. The platform shows which projects contain a given component and version, so when an advisory lands for a framework or database driver, you can see every public system that carries it.
• Match against known vulnerabilities and rank them. Safeguard matches components against vulnerability databases, and reachability analysis ranks the vulnerable code paths your application actually calls first.
• Gate releases. Policies and gates evaluated in the platform can stop a build that carries a known vulnerable version of a component from shipping to a public system.
• Fix with approval. The Safeguard CLI's assistant can read code, edit files and run commands with your approval, using /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You can ask it to replace string built queries with parameterised ones in a module, add an authorisation check and a test for it, or bump a framework version, and approve each change. safeguard exec runs the same work in CI. Where Safeguard does not help: it does not scan your production database grants, read your web server logs, act as a WAF, or detect an intrusion in progress. If the vulnerable component turns out to be a hosted service or a vendor product you do not build yourself, the fix has to come from that vendor. Safeguard would not have prevented this incident, and we do not claim it would have.

Zero-Day Discovery and Gold

Two Safeguard capabilities are aimed at the gap between a flaw existing and a fix being in your build.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Custom application logic in a company's own case system, and a vendor's hosted product, are outside what it covers. Its vulnerable component has not been named.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It provides hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages. An artifact loses its badge if it regresses.

There is no CVE for this incident, so there is nothing to look up in Gold for it today. The habit these tools support is the general one: pull patched, signed components from a curated source and rebuild quickly when a fix lands for anything your public systems run.

Common mistakes and troubleshooting

Adding the three counts together. 746,277 plus 750 plus 1,000 is not a number of people. The categories are different record types, and one person could appear in more than one.

Assuming SQL injection. It is one possibility among several. Nobody with first hand knowledge has said so.

Linking the incident to the PHP vulnerability. The company says it has confirmed there is no connection.

Treating email only exposure as harmless. An email address tied to a known booking for a pickup or a move is a strong phishing hook. Messages about appraisals, payment for collected goods or moving dates are all plausible lures.

Restricting the database port but leaving an admin tool exposed. A database admin web tool on a public path gives the same access as an open port. Check both.

FAQ

What did Treasure Factory disclose?

On 23 October 2026 it said a third party exploited a vulnerability in database access in the case management system for its home pickup buyback and Torefac moving services on 20 October, and took 746,277 customer records, 750 partner and staff records and 1,000 device records.

Was my credit card exposed?

The company says the customer data taken contains no credit card numbers, security codes or other payment information.

What exactly was taken about customers?

Email addresses. For 11 customers, name and address were also included.

I shop in Treasure Factory stores or use the app. Am I affected?

The company says store customer information and app customer information are kept in separate systems and were not part of this incident.

Was this caused by the PHP vulnerability in the news this month?

No. The company says the access did not exploit the recently published PHP vulnerability and that it has confirmed there is no connection.

What was the vulnerability?

The company describes it only as a vulnerability related to database access. It has not named the product, the code, the vulnerability type or a CVE. Investigation with an outside specialist is continuing.

Is this related to the August Kindoru incident?

The company says the two incidents had different causes and entry points: phishing of a staff account in August, a database access vulnerability in October. It treats the closeness in time seriously and is strengthening controls across the group.

When will pickup and moving bookings reopen?

The company plans to restart the case system and the application forms around 28 October, after safety measures and checks are done.

Fix it without waiting for upstream

In this incident the vulnerable component has not been named, and it may be custom code rather than open source. Many case and order systems, though, are built on open source frameworks, drivers and container images, and that is where the two gaps below usually sit.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Treasure Factory or its systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a team that runs a public booking form and a case system behind it.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a case management service, you would run /scan . in its repository, then ask the assistant to replace string built queries in the case lookup module with parameterised ones and add a test that a field staff session cannot read another partner's case, approving each edit and command as it runs.

Click through it at your own pace, or open it full screen.

This session sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. A team that cannot send code off site could register a runner on a build host inside its network and scan the case system's repository and container image there, so the inventory of frameworks and drivers stays current without moving source code out.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder holding its booking form service, ask for each database call to be checked for parameterisation and for a per session read limit to be added, and approve or deny each proposed change itself.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For other breaches disclosed in Japan this month, see the Japan breach wave involving Yamato, Nikkei and FANCL, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• Treasure Factory: Notice of personal information leak due to unauthorized access to our system (TDnet timely disclosure, 23 Oct 2026, Japanese PDF)
• Treasure Factory: Apology and notice regarding personal information leak due to unauthorized access (23 Oct 2026, Japanese)
• Treasure Factory: Notice of partial service suspension for security measures (23 Oct 2026, Japanese)
• Treasure Factory: Notices list (Japanese)
• Nikkei: Torefac personal information leaked through unauthorized access, about 700,000 records (23 Oct 2026, Japanese)
• Security news report: Treasure Factory, 746,277 records, database access vulnerability (23 Oct 2026, Japanese)
• Daily Sports: Unauthorized access at Torefac (23 Oct 2026, Japanese)
• Niigata Nippo: Unauthorized access at Torefac (23 Oct 2026, Japanese)
• Media IR: Five listed companies disclose unauthorized access on 23 Oct (Japanese)
• Netshop Impress: Kindoru EC site breach (1 Sep 2026, Japanese)
• ScanNetSecurity: Bulk export of customer data at the EC platform used by Kindoru (18 Sep 2026, Japanese)
• ScanNetSecurity: Phishing at subsidiary Kindoru, group wide recurrence prevention (24 Sep 2026, Japanese)
• Personal Information Protection Commission: Reporting leaks of personal data (Japanese)
• IPA: How to Secure Your Website, revision 7 (Japanese)
• OWASP SQL Injection Prevention Cheat Sheet
• OWASP API Security Top 10, 2023 edition

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.