BOOKOFF Breach: 6.38M Members, Password Hashes and Ex-Members

BOOKOFF GROUP HOLDINGS says a third party broke into the domestic BOOKOFF member management system and sent out 6,427,735 member records, covering 6,383,279 people, including 212,371 who had already cancelled. Names, contact details, birth dates and password hashes left. Members should change reused passwords now; teams should check hash schemes and retention.

BOOKOFF GROUP HOLDINGS (ブックオフグループホールディングス, TSE Prime, securities code 9278) runs Japan's best known chain of second hand book, media and goods shops. The affected system belongs to its consolidated subsidiary BOOKOFF Corporation and holds the profiles behind the BOOKOFF app, the official online store and web membership. This post works from the company's TDnet filings, customer FAQ and notices, translated from Japanese, and quotes every figure exactly as filed. The company has not said how the attacker got in, and we do not guess. Where this post mentions the wider run of Japanese breaches this autumn, the link is timing only.

What happened

On Tuesday 6 October 2026 BOOKOFF Corporation confirmed unauthorized third party access to its member management system. System records showed member information was obtained from outside between 4 and 6 October. The company cut the attacker's communications and access route, and says every acquisition route identified so far is contained.

A first notice followed on 9 October, a second report with confirmed counts on 13 October, and a correction adding two omitted fields on 16 October. Emails to affected members ran from 15 to 22 October. A dedicated free phone line opened on 22 October and a self service lookup on 23 October.

Timeline

All times are Japan Standard Time. Where a filing gives only a date, the table gives only a date.

The 22 October maintenance notice says only that some sites and services may be unavailable. It does not mention the breach, and we are not connecting the two.

What is still unknown

• How the attacker got in. The first notice says the company blocked the attacker's traffic, "corrected the vulnerability" and blocked external access to the target system. The second report declines to publish the system configuration, the vulnerability or the attack method, on the grounds that doing so could invite further unauthorized access. No CVE, product name or vendor has been named.
• The password hashing scheme. Neither filing names an algorithm, a salt or a work factor.
• Whether the data has been misused. As of 13 October the company had confirmed no publication of the data, no point fraud and no tampering with real members' records.
• The cost. Under review and not in the forecast for the fiscal year ending May 2027.

The numbers, exactly as filed

The second report, filed on TDnet on 13 October, replaced the first notice's estimate with confirmed counts. Here they are, translated as closely as possible.

The first notice, on 9 October, had said "up to about 6.43 million" records (最大 約643万件) and noted that this was a count of member numbers, not of people.

Records versus people

The company defines the two figures carefully. The record count is the number of member numbers for which the system's own records show the member information was sent outside. The people count treats several member records registered with the same email address as one person. That difference in method is why the two numbers differ, by 44,456 on our arithmetic.

The record count is the better measure of what an attacker now holds; the people count is the better measure for notification, which is why BOOKOFF emailed by address. Someone who registered twice with different addresses counts twice even in the people figure, which is why the FAQ asks people with several accounts to check each one.

Active and cancelled members

The split is the most useful single fact in the filing. Of the 6,383,279 people, 212,371 had already cancelled their membership. Their data was still in the live member management system on 4 October, and it left with everyone else's. Nikkei's headline singled out exactly that point.

The filing does not say why the records were kept, and there can be ordinary reasons, such as fraud review or legal record keeping. What it shows is that people who had left were exposed on the same terms as people who had stayed.

Technical details

Everything in this section comes from the company's own filings unless another source is named. The filings are in Japanese; the translations are ours.

System and services in scope

The breach is limited to one system, the BOOKOFF member management system (ブックオフ会員管理システム). The second report lists the services whose members it holds:

Within those services, the members in scope are app members, online store members and web members. Customers who only use a physical member card and never registered in the app or on the web are not included. The FAQ adds a caveat: people who carried their card membership over to the app or web may be in scope.

Services outside the scope

The second report lists hugall, aidect, the Rehello by BOOKOFF e-commerce site, Japan TCG Center, Booklog (ブクログ), Aoyama Book Center (青山ブックセンター) and the BOOKOFF tidy up service as managed in separate systems and outside the incident. The Q1 supplementary deck adds that overseas stores and services are not affected.

Data fields

The leaked field list changed once. The table shows the final position after the 16 October correction.

The FAQ adds a qualifier that matters for anyone estimating risk: not every member had every one of these fields leaked. The data each person registered differs.

How the filings describe the password data

The two filings use different words for the same field, and the difference is worth noting.

• The first notice, 9 October, footnotes the field as an "encrypted password" (暗号化されたパスワード) that cannot be read as it is.
• The second report, 13 October, calls it a "password hash value" (パスワードのハッシュ値) and footnotes it as information produced by converting the password with a fixed method, from which the original password cannot be read directly.

The later wording is more precise and is the one the correction and FAQ keep. No document names the algorithm, salting or work factor, the three facts that decide how expensive the hashes are to crack. We will not guess.

Containment, as described

The second report states that the group's systems are operating normally and that the incident does not affect business continuity. Stores, the official online store and the app remained usable.

Official contacts and how to recognise the real email

Phishing that imitates breach notices is a predictable follow on. These are BOOKOFF's official markers:

The notice emails contain no password change link. BOOKOFF says it will never ask for passwords, card or bank details by email, SMS or phone; the first notice adds authentication codes. Go to the official app or site directly.

Wave context: the JPCERT/CC indicators

JPCERT/CC's alert JPCERT-AT-2026-0030 (published 8 October, updated 23 October) covers a run of intrusions at Japanese organisations since around September 2026 that led to large personal data leaks. It describes five patterns, Case A to Case E, with indicators. It does not name BOOKOFF, and BOOKOFF has not tied its incident to any case. We include the indicators because any operator of a consumer app or member system in Japan should check for them, not because they explain this breach. JPCERT/CC itself says the cases do not mean one method was used everywhere.

Indicators as JPCERT/CC published them, defanged. It notes some addresses may have been in legitimate use when checked, and that attackers also used Tor exit nodes and residential proxies.

JPCERT/CC's 15 October blog on the attack infrastructure lists 118.26.36[.]16 as an additional indicator alongside two of the Case B addresses above.

User agents and TLS fingerprints JPCERT/CC lists for Case B:

JPCERT/CC warns that this JA4 value matches a common Python HTTP client and cannot identify an attacker on its own. For Case C it lists the user agents python-requests/2.33.1 and Metabase-GHSA-vwf4/2.0.

Case C in detail: CVE-2026-72898

Case C names an open source product and CVE, so here are its versions. Nothing public says BOOKOFF ran Metabase or that this CVE played any part in its breach.

Metabase's advisory GHSA-vwf4-m7j8-wcjf (6 August 2026) describes an unauthenticated SQL injection into the Metabase application database that can yield administrator access, rated CVSS 10.0. Exploitation is reported: Metabase states it has confirmed active exploitation, and JPCERT/CC's alert JPCERT-AT-2026-0023 says it was exploited as a zero day.

A discrepancy: the GitHub advisory's "Affected versions" ranges end slightly earlier (below x.58.23, below x.63.3) than its "Patched versions". JPCERT/CC treats everything before the patched version as affected; upgrading to the patched version covers both readings. Metabase Cloud was already fixed. The workaround is to block /api/session/reset_password. Metabase says a POST to that endpoint returning 400 followed by GET /api/user/current returning 200 strongly suggests compromise, and that exposed instances should, after upgrading, delete all rows in core_session, review API keys and admin accounts, and rotate connected database credentials.

Why the password hashes matter

Most leaked fields are raw material for phishing. The password hash is the one field that can turn a breach at one retailer into account takeover elsewhere. Its risk depends on three facts BOOKOFF has not published:

1. The algorithm. Argon2id, scrypt or bcrypt make each guess expensive; a fast general purpose hash makes guessing cheap.
2. Salting. A unique salt per account forces separate work per hash. Without salts, one guess is checked against millions at once.
3. The work factor. Even a good algorithm can be configured too cheaply.

For reference, the OWASP Password Storage Cheat Sheet currently recommends Argon2id with at least 19 MiB of memory, two iterations and one degree of parallelism (or one of several equivalent settings), scrypt with a cost of 2^17 and block size 8 where Argon2id is not available, bcrypt with a work factor of 10 or more for legacy systems, and PBKDF2 with HMAC SHA 256 at 600,000 iterations or more where FIPS 140 compliance is required.

Whatever the scheme, weak passwords tend to be recoverable, and the risk then moves to every service where the same email and password were reused. That is why BOOKOFF asks members to change matching passwords elsewhere too. For other operators, the common pattern after large hash leaks is credential stuffing against other logins; that is a general expectation, not a reported fact about this data, which BOOKOFF says has not been seen published.

Why cancelled members were in the data

The 212,371 cancelled members are a retention story. They had ended their relationship with the service, and their records were still in the same live system as active members, reachable by the same path and exported in the same window.

JPCERT/CC's alert makes the same point in general terms. Among its generic countermeasures it lists not keeping data past the retention period set by law or contract, or after its purpose is finished. Two other posts here look at related data minimisation lessons: the Times Car breach, where ID images of withdrawn members were kept for years, and the Capcom ID breach, where stored profile and log data widened what a breach could expose.

Retention decides the size of the worst day: a breach cannot take what is no longer there. For a member system, ask what happens to a row when a member cancels, which fields survive, for how long, where, and who can read them.

Who is affected

What to do now

If you are or were a BOOKOFF member

1. Check whether you are in scope with the lookup on the BOOKOFF member site, reached from the official site. If you cannot log in, for example because you cancelled, call the dedicated line.
2. Change your BOOKOFF password in the official app or online store, typing the address yourself.
3. Change it everywhere you reused it, starting with email, shopping, payment and delivery accounts.
4. Turn on multi factor authentication, above all on your email account.
5. Distrust contacts that know your details. Knowing your name, address and birth date proves nothing about who is calling.
6. Check the sender against bookoff@2902.net and the subject above.

If you run a consumer login service

Large hash leaks raise the odds that stolen credentials are tried against your login. This week:

1. Watch login failure rates by source. A sudden rise in failed logins spread across many accounts and many IP addresses is the usual signature of credential stuffing.

# Failed logins per source IP in the last day (adjust path and status for your app)
zgrep -h 'POST /api/login' /var/log/nginx/access.log* \
  | awk '$9 == 401 {print $1}' | sort | uniq -c | sort -rn | head -50

# Distinct accounts attempted per IP, from an application log with JSON lines
jq -r 'select(.event=="login_failed") | [.ip, .username] | @tsv' app.log \
  | sort -u | cut -f1 | uniq -c | sort -rn | head -50

2. Rate limit login, password reset, SMS sending and search, per account and per source, as JPCERT/CC recommends.
3. Check new passwords against a breached password list at sign up and at change, so a password exposed elsewhere cannot be set again.
4. Offer and encourage multi factor authentication, and require it for any action that changes the email address or the phone number on file.
5. Prepare your own phishing guidance now: a page that says what your company will and will not ask for, like the one BOOKOFF published.

Check your logs for the JPCERT/CC indicators

Search web server, load balancer and API gateway logs from late August onward for the addresses JPCERT/CC lists. The pattern below uses real dots, not the defanged form.

cat > jpcert-at260030-ips.txt <<'EOF'
20.210.128.125
69.10.51.162
207.241.172.54
210.149.87.120
210.149.87.33
3.112.252.14
31.76.91.2
54.95.112.6
136.85.58.5
136.117.40.140
141.11.187.186
172.86.91.7
213.163.202.171
221.216.140.49
221.216.140.129
124.133.237.18
31.59.92.155
31.56.206.187
38.244.50.120
46.8.227.73
64.44.24.195
94.183.184.98
94.183.184.254
95.182.99.112
176.65.144.71
118.26.36.16
EOF

# Exact matches on the client IP field (first field in the combined log format)
zcat -f /var/log/nginx/access.log* \
  | awk 'NR==FNR {bad[$1]=1; next} ($1 in bad)' jpcert-at260030-ips.txt - \
  | head -100

# User agents JPCERT/CC lists for the API and Metabase cases
zgrep -hE 'python-requests/2\.3[34]\.|curl/7\.88\.1|Metabase-GHSA-vwf4' /var/log/nginx/access.log* | head -100

If your edge records JA4 fingerprints, search for t13d181100_85036bcba153_d41ae481755e, but only in combination with the other indicators. Ordinary Python clients produce the same value.

Check any Metabase instance you run

# Version reported by the instance
curl -s https://metabase.example.internal/api/session/properties | jq -r '.version.tag'

# Signs of the exploitation sequence Metabase describes
zgrep -hE 'POST /api/session/reset_password HTTP/[0-9.]+" 400' /var/log/nginx/access.log*
zgrep -hE 'GET /api/user/current HTTP/[0-9.]+" 200' /var/log/nginx/access.log*

If the version is below the fixed release for its line, upgrade, then follow Metabase's post upgrade steps. Business intelligence tools are easy to forget: JPCERT/CC specifically warns that systems never meant for the general public, including BI tools and staff management systems, have been breached in this wave.

Audit how your own member system stores passwords

Find out what your hashes actually are. Most formats announce themselves with a prefix.

-- PostgreSQL example; adjust table and column names
SELECT
  CASE
    WHEN password_hash LIKE '$argon2id$%' THEN 'argon2id'
    WHEN password_hash LIKE '$argon2i$%'  THEN 'argon2i'
    WHEN password_hash LIKE '$scrypt$%' OR password_hash LIKE '$7$%' THEN 'scrypt'
    WHEN password_hash ~ '^\$2[aby]\$' THEN 'bcrypt cost ' || substring(password_hash from 5 for 2)
    WHEN password_hash LIKE 'pbkdf2_sha256$%' THEN 'pbkdf2 sha256 (Django style)'
    WHEN password_hash ~ '^[0-9a-f]{32}$' THEN 'bare 32 hex: possibly unsalted MD5'
    WHEN password_hash ~ '^[0-9a-f]{40}$' THEN 'bare 40 hex: possibly unsalted SHA1'
    WHEN password_hash ~ '^[0-9a-f]{64}$' THEN 'bare 64 hex: possibly unsalted SHA256'
    ELSE 'unknown'
  END AS scheme,
  count(*)
FROM members
GROUP BY 1
ORDER BY 2 DESC;

Bare hex strings of a fixed length are a warning sign, not proof; check the code that writes them. If you find legacy hashes, upgrade them on next login rather than waiting for a reset campaign:

# Rehash on successful login with argon2-cffi; verify_legacy is your old check
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher()  # library defaults follow current guidance; tune for your hardware

def login(user, password):
    if user.hash.startswith("$argon2id$"):
        try:
            ph.verify(user.hash, password)
        except VerifyMismatchError:
            return False
        if ph.check_needs_rehash(user.hash):
            user.hash = ph.hash(password)
            user.save()
        return True
    if verify_legacy(user.hash, password):
        user.hash = ph.hash(password)
        user.save()
        return True
    return False

For accounts that never log in again, wrap the old hash inside the new function (hash the legacy hash with Argon2id) so no weak hash remains at rest, then unwrap on the next successful login. The OWASP cheat sheet describes this upgrade path.

Audit what you keep after cancellation

-- How many cancelled members still have full profiles in the live table?
SELECT
  date_trunc('year', cancelled_at) AS cancelled_year,
  count(*) AS rows,
  count(password_hash) AS with_password_hash,
  count(birth_date) AS with_birth_date,
  count(phone) AS with_phone
FROM members
WHERE status = 'cancelled'
GROUP BY 1
ORDER BY 1;

If the answer is "all of them, with every field", decide what each field is still for. Typical outcomes: delete the password hash at cancellation, since a cancelled member cannot log in; move anything you must keep for legal reasons into a separate store with separate credentials; and set a scheduled deletion that runs without anyone remembering to run it.

What changed since first reports

The figures did not change after 13 October. The 16 October correction explicitly says the counts and every other disclosed item stay the same.

Open questions

• What vulnerability was corrected, and in which component: custom code, an open source library, a commercial product or configuration?
• Which password hashing scheme, salt policy and work factor protected the 6,427,735 hashes?
• Why were the records of 212,371 cancelled members still in the live system, and will that change?
• Did the attacker reach anything beyond the member management system? The group wide inspection was still under way at the last report.
• Will a later disclosure publish the withheld details? Under PPC guidance, a final report for leaks that may involve a wrongful purpose is due within 60 days of discovery.

What would have helped

None of this judges BOOKOFF, which cut off the access, reported to the regulator, filed confirmed counts within a week, publicly corrected its own field list and built a self service lookup. The question for everyone else is how to make the same class of event smaller.

Practices any team can use

• Delete what a cancelled account no longer needs. Start with the password hash, since a member who has left cannot log in. Contact details and birth dates should follow on a schedule your storage enforces.
• Separate past customers from current ones. Anything kept after cancellation belongs in a different store, under different credentials, off the live app's path.
• Hash passwords with a slow, salted, modern function, upgrade old hashes on login, and publish the scheme so users can judge their risk after a breach.
• Collect fewer fields. Occupation and nickname ended up in this notice. Every optional field is a future line in yours.
• Treat every API behind a public app as public. JPCERT/CC and NICT describe attackers taking apart public Android apps to find back end endpoints and keys. Authorise every request on the server and rate limit everything.
• Take internal tools off the internet. BI dashboards and staff portals have been hit in this wave.
• Shorten the patch clock. Know every framework, library, image and product version in internet facing services, and rebuild fast when a fix ships.
• Write the customer message early. BOOKOFF's list of what it will never ask for is a good template.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API.

The limits: BOOKOFF has not said what the vulnerability was or where it sat. Safeguard has no advisory for it and no patched build related to it. These capabilities help in the shared layer of frameworks, libraries and base images that member systems are built from, where pulling patched, signed components and rebuilding fast removes one common way in. They do nothing about retention or password storage design, the lessons that matter most here.

Where Safeguard fits

Safeguard would not have prevented this incident, and it would not have changed how long cancelled members' data was kept or how passwords were hashed. What it covers, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind a member system, with JSON results under ./output.
• Component search across projects, showing every project that contains a given component and version when an advisory lands.
• Vulnerability matching and reachability analysis, ranking the vulnerable code paths your application actually calls.
• Policies and gates, so a build carrying a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which edits code and runs commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add rehash on login, or a migration that clears hashes when a member cancels, and approve each change.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

Where Safeguard does not help: it does not monitor logins or traffic, detect credential stuffing, manage retention schedules or see inside a vendor's hosted service.

Common mistakes and troubleshooting

• Reading "hash" as "safe". A hash is only as strong as its algorithm, salt and work factor. Until those are known, assume some passwords from any large hash dump will be recovered.
• Putting a reset link in the breach email. It trains people to click exactly the kind of link a phisher will send next week. BOOKOFF's notice deliberately has none.
• Searching logs only for the defanged form. 69.10.51[.]162 will never appear in a log. Convert indicators back to normal form before searching.
• Treating a single JA4 match as a hit. JPCERT/CC says the listed JA4 matches ordinary Python clients. Combine it with source address, user agent, path and timing.
• Upgrading Metabase and stopping there. If the reset password endpoint was reachable, Metabase says to clear sessions, review API keys and admin accounts, and rotate data source credentials after the upgrade.
• Soft deleting cancelled members. A status flag does not remove a row from backups, replicas or exports.

FAQ

What happened at BOOKOFF?

A third party accessed the domestic BOOKOFF member management system, run by BOOKOFF Corporation. Access was confirmed on 6 October 2026; data was taken between 4 and 6 October. Disclosure came on 9 October and confirmed counts on 13 October.

How many people are affected?

The second report gives 6,427,735 member records, counted by member number, and 6,383,279 people after treating records with the same email address as one person. Of those people, 6,170,908 were active members and 212,371 had cancelled.

Were passwords stolen?

Password hash values were taken, not plain text passwords. BOOKOFF has not named the hashing algorithm. Affected members should change their BOOKOFF password and any matching passwords elsewhere.

Were credit card or bank details taken?

No, according to BOOKOFF. Payment card and bank account data are not held in the affected system. ID document images from mail in buy back are in a separate system and were not affected, and ID images from in store buy back are not stored at all.

How did the attacker get in?

BOOKOFF has not said. Its first notice says it corrected a vulnerability and blocked external access; its second report withholds the system configuration, vulnerability and attack method to avoid inviting further attacks. No CVE or product has been named.

Is this linked to the other Japanese breaches this autumn?

BOOKOFF has not linked it to any other incident, and JPCERT/CC's wave alert does not name BOOKOFF. It falls in the same weeks as the breaches in our Japan breach wave roundup and the Sagawa Express breach, but that is timing only.

How can I tell a real BOOKOFF email from a fake?

The real notice came from bookoff@2902.net with the subject 不正アクセスによる個人情報漏えいに関するお詫びとお知らせ, between 15 and 22 October. It contains no password change link. BOOKOFF will not ask for passwords, card details or bank details by email, SMS or phone. When in doubt, use the official site and the free dial 0120-300-663.

Why were cancelled members included?

Their records were still in the live member management system when the data was taken. The filings do not say why they were kept. The lesson for other teams is to decide, field by field, what a cancelled account still needs, and delete the rest on a schedule.

Would Safeguard have prevented this?

No. The lessons here are about retention, password storage and API exposure, which Safeguard does not manage. Safeguard helps with one shared layer: finding and fixing known vulnerable components in the services you build, and making changes with an assistant that asks before it acts.

BOOKOFF has not named the vulnerability it corrected, so nobody can say whether a package fix was involved. For the parts of a member system that teams do build from open source, this is the general playbook.

Fix it without waiting for upstream

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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 BOOKOFF or its systems; each is a real Safeguard session applied here to a team running a member system.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a member service, you would run /scan . in the authentication service's repository, then ask the assistant to add rehash on login and a test that fails if a cancelled member keeps a password hash, approving each edit and command as it runs.

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 team could pick the folder holding a self hosted BI deployment, ask for the image tag to move to the fixed release for its line, and approve or deny every change before it lands.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands at night for a framework your login API uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches the member database until a second person has looked.

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 the wider month, read October 2026 security incidents and what would have helped.

Quick check

Sources

• BOOKOFF GROUP HOLDINGS: Apology and notice regarding a personal information leak caused by unauthorized access, second report (TDnet, 13 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Apology and notice regarding a personal information leak caused by unauthorized access, first notice (TDnet, 9 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Correction to the second report, occupation and nickname added (TDnet, 16 Oct 2026, PDF)
• BOOKOFF official online store: Correction notice (16 Oct 2026)
• BOOKOFF GROUP HOLDINGS: Correction to the Q1 FY2027 supplementary materials (TDnet, 16 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Q1 FY ending May 2027 earnings summary (TDnet, 13 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Q1 FY ending May 2027 supplementary materials (TDnet, 13 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Frequently asked questions on the leak (updated 23 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Web lookup added and dedicated free dial opened (23 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Temporary maintenance of group related sites (22 Oct 2026, PDF)
• BOOKOFF GROUP HOLDINGS: Contact form for this incident
• Nikkei: Disclosure index entry for the second report (13 Oct 2026)
• Nikkei: BOOKOFF leaks about 6.42 million member records, cancelled members included
• Kyodo News via Yahoo News Japan: Information leak at BOOKOFF, up to 6.43 million records (9 Oct 2026)
• Business+IT: Unauthorized access to BOOKOFF member system
• Security Measures Lab: BOOKOFF member management system breach write up
• JPCERT/CC: Alert on the run of unauthorized access at domestic organisations, JPCERT-AT-2026-0030 (8 Oct 2026, updated 23 Oct)
• JPCERT/CC Eyes: Investigation of attack methods in the run of unauthorized access incidents (15 Oct 2026)
• JPCERT/CC: Alert on the Metabase SQL injection vulnerability CVE-2026-72898, JPCERT-AT-2026-0023 (14 Aug 2026)
• Metabase: GHSA-vwf4-m7j8-wcjf, SQL injection using an unauthenticated endpoint leading to admin access
• NICT CYNEX: Warning on attacks against servers through app analysis (13 Oct 2026)
• Personal Information Protection Commission: Breach reporting (漏えい等報告について)
• OWASP Password Storage Cheat Sheet

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