23 million people. 22.5 million records. 11 million more.
That’s ShopServe, Sourcenext and Burger King Japan, three of the breaches Japanese companies have disclosed in recent weeks.
They aren’t the only ones.
On October 9, Japanese lawmakers met to discuss the data breaches hitting companies across the country. Masaaki Taira, who leads the Liberal Democratic Party’s cybersecurity group, called the situation an emergency. He asked for a response from the whole country, government and public together.
The government’s advice that day was simple: fix web vulnerabilities fast, check your suppliers, and watch who is accessing your most important data.
A week later, JPCERT/CC, Japan’s national incident response team, showed how the attackers worked. They used AI to hunt for known weaknesses and attack APIs. They even studied the code of mobile apps to find more APIs to attack.
This issue follows that story from start to finish.
Inside this issue
🌡️ Threat Level: High Alert
⚡ News covers three of the breaches: Sourcenext, Burger King Japan and Studio.
🔎 Deep Dive goes inside ShopServe, where stores that had left the platform years ago were still affected by the breach.
🎣 Is It a Phish?
🔬 Technical Research: How Metabase’s Password Reset Gave Attackers Admin Access (CVE-2026-72898)
🛠️ Tool of the Week is Blutter, which JPCERT found in the attackers’ toolkit. Use it to see what your own app gives away.
👏 Person of the Week is Loren Kohnfelder, author of the book : Designing Secure Software
📅 Event of the Week is CODE BLUE in Tokyo, November 17–18, where Shusei Tomonaga, CTO of JPCERT/CC is speaking.
📚 Book of the Week is Designing Secure Software, on designing apps that stay secure even when attackers know exactly how they work.
😅 The Meme
❓ One Question Before You Leave.
Let’s dig in.
🌡️ Threat Level
⚡ News
Attackers abused Sourcenext’s member API, putting 22.5 million records at risk
Sourcenext is a Japanese software company that sells apps and PC software to consumers.
From October 9 to 13, attackers abused the API Sourcenext uses to look up member information. The company lists 22,519,960 records as potentially affected.
Depending on the customer, those records can include email addresses, passwords, names, addresses, phone numbers, birth dates and account details. Card details weren’t stored in the affected system.
Why it matters: The exposed data can include customers’ passwords. That’s the part to worry about.
Most people use the same password in more than one place. So with your email and your Sourcenext password, attackers can try logging in to your email, your shopping accounts, even your work account. If you reused it, they get in.
That’s why Sourcenext’s notice asks customers to change that password anywhere else they used it.
Burger King Japan’s app leaked about 11 million member records
From October 2 to 7, attackers got into the system that manages Burger King Japan’s app memberships. The company confirmed a leak of about 11.18 million records: names, contact details, birth dates and membership information.
No card numbers were held in that system, and there’s no sign so far that passwords leaked. How the attackers got in is still under investigation.
Why it matters: No card numbers leaked, so it’s easy to think this one is harmless. It isn’t.
With a name, a phone number and a birth date, a scammer can send you a message pretending to be Burger King. Because it knows real details about you, it looks real. You tap the link, and a fake page asks for your password or card number.
That’s why Burger King is warning customers to watch out for suspicious emails, texts and calls.
Studio’s data was encrypted. The attacker reached the keys too.
A vulnerability in Studio, a Japanese website builder, let an attacker into its cloud environment. Every registered customer is potentially affected.
What may have been exposed: account details, website content, form responses, and the API keys customers used to connect Studio to other services. Studio hasn’t confirmed the data was downloaded, but it’s responding as if it was.
Why it matters: Studio is the one to read closely, because three things that usually feel safe didn’t hold:
Encrypted. Some data was encrypted, but the attacker also reached the keys to decrypt it.
Deleted. Form responses sitting in the trash may have been exposed too. Only ones permanently deleted before September 30 were left out.
Fixed. Patching Studio doesn’t end it. Customers had to replace some of the keys to their other services themselves.
A website builder doesn’t just hold websites. It holds the keys to everything those websites connect to.
🔎 Deep Dive
ShopServe’s Breach Exposed Customers of Stores That Had Already Left the Platform
In August 2022, King Jim, the Japanese stationery company, moved its main online store off ShopServe.
Four years later, it was apologizing to its customers for a breach at ShopServe.
It was one of 7,858 current and former stores caught up in that breach, which affected about 23.36 million people.
King Jim wasn’t using ShopServe anymore. But the records of people who had shopped with it back then were still there. When ShopServe was breached, those records were exposed.
So this deep dive asks a simple question: when you leave a platform, what happens to the customer data you leave behind?
What happened at ShopServe
ShopServe is an online store platform run by the Japanese company E Store. Thousands of businesses have used it to sell online.
From May 21 to August 1, 2026, attackers used a flaw in one of its applications to run their own programs and send information from its database out of the system. E Store hasn’t said what the flaw was.
E Store published its final report on October 16. About 23.36 million people were affected, across 7,858 current and former stores. About 2.1 million of them had part of their card details exposed, though not full card numbers or security codes.
The attackers didn’t only get shopper data. They also got the logins stores use to manage their shops, and logins for E Store’s affiliate program.
And notice the words “current and former”. Some of those stores had left ShopServe a long time ago and were still affected by the breach.
Two stores that had moved their main shop off ShopServe and still got breached
King Jim, the stationery store, left four years ago.
King Jim’s September 4 notice confirmed that information about its past customers was exposed. Its current online store wasn’t affected.
And it wasn’t only the old store. The notice also covered Office Online, another King Jim store that had already shut down. That store didn’t exist anymore, but its customers’ data was still part of the breach.
Then came the hard part. King Jim said it couldn’t check whether any individual customer was affected, because it didn’t have the information to do that. It had to send customers to E Store with their questions.
So King Jim apologized for a breach on a platform it had left, and still couldn’t answer its own customers.
PFU’s records went back to 2008.
PFU, a Ricoh group company that makes scanners, moved its main store off ShopServe in October 2025. Some separate sales pages stayed on the platform until September 2026.
The records at risk went back to December 2008: up to 169,355 orders.
What stands out is how long it took PFU to find out its own customers were involved:
August 2: PFU is told about the breach.
September 8: PFU asks E Store, and learns that past customers of its main store might be affected.
September 17: PFU gets confirmation that its past customers’ data was affected.
September 18: PFU publishes its apology.
That’s more than six weeks between hearing about the breach and knowing its own customers were in it.
The stores still had to answer to their customers
The breach happened at ShopServe. But King Jim and PFU are the ones who wrote to their customers, said sorry, and answered the questions.
That’s how customers see it. They didn’t shop with E Store. They shopped with King Jim, or with PFU. When their data leaks, they look at the name they know.
Leaving the platform didn’t change that, because the old data was still there. Nobody has said why it was kept, or whether anyone asked for it to be deleted.
We’ve only read these two stores’ notices, out of 7,858. But any store that left ShopServe while its old customer data stayed behind could be in the same position.
What to do when you leave a vendor
Ask for deletion, in writing. When you move off a platform, ask the vendor to delete your customers’ data and confirm it’s done.
Know what they still hold. If they have to keep some records, find out which ones and for how long.
Agree on what happens if they’re breached. They should tell you quickly, and tell you which of your customers were affected, so you’re not waiting six weeks to find out.
Changing platforms is one step. Getting your customers’ data deleted is another, and it’s easy to forget.
Sources: E Store final report · King Jim notice · PFU notice
🎣 Is It a Phish?
An email from “ShopServe Customer Support” says your details were part of the ShopServe breach.
It knows your name, your old delivery address and the last four digits of your card. To see what was exposed, it asks you to sign in to an incident review portal.
Take a close look at the message, and at where the button leads.
Is it a phish?
🔬 Technical Research
How Metabase’s Password Reset Gave Attackers Admin Access (CVE-2026-72898)
Anyone can use a password reset page. That’s the point: if you forgot your password, you can’t log in first.
So the page should only ask for two things, the reset token from your email and a new password, and ignore anything else you send.
Metabase’s reset page didn’t ignore the rest. If an attacker sent one extra field, Metabase put it straight into a database query. And it did that before checking whether the reset token was even valid.
That’s CVE-2026-72898, an SQL injection that works without logging in. It affects Metabase, the open-source tool many companies use to build dashboards on top of their data warehouses.
It’s rated CVSS 10.0. Attackers used it before a fix existed, first against Metabase’s own cloud service, then against companies running Metabase on their own servers around the world.
It ties in with this issue. JPCERT/CC published a dedicated alert about this flaw on August 14. On October 8, it listed Metabase attacks as one of the methods behind the recent wave of breaches at Japanese organizations.
JPCERT hasn’t named the Japanese victims or said how many there were, and nothing public links this flaw to the ShopServe breach in our deep dive. What it does show is how one internal tool, reachable from the internet, can lead attackers to the customer data behind it.
What Metabase is, and why attackers target it
Metabase lets people across a company build dashboards and run queries without writing SQL. To do that, it connects to the company’s real databases (PostgreSQL, MySQL, Snowflake, BigQuery, Redshift and others) and stores the credentials for those connections.
So by design it’s a system that:
Holds working credentials for the company’s most important databases.
Can query and export data from all of them.
Often gets deployed by a data team rather than the security team, and is sometimes left reachable from the internet so people can use it from anywhere.
Metabase keeps its own state (users, sessions, API keys, settings and those connection details) in an internal application database. That internal database is where this injection lands.
The bug: the reset endpoint accepted extra fields
Metabase’s reset endpoint, POST /api/session/reset_password, declared the two fields it expected:
request-body :- [:map
[:token ms/NonBlankString]
[:password ms/ValidPassword]]That schema checks that token and password are present and valid. It doesn’t reject other fields.
Metabase’s schema library, Malli, treats maps as open by default, so any extra keys in the JSON body passed validation and were handed, together with the token and password, to the shared login code.
That login code began like this (from auth_identity/provider.clj in version 0.58.22):
(merge request (authenticate provider request))
...
(when-let [user-id (:user-id $)]
(t2/select-one [:model/User ...] :id user-id))It merges the request with the authentication result, then looks up the user by :user-id.
When authentication succeeds, the result contains the real :user-id and overwrites anything in the request.
When it fails, for example because the reset token is invalid, the result has no :user-id. Clojure’s merge only overwrites keys that are present in both maps, so a user-id supplied by the attacker survives the merge, and the code then looks up a user with it.
That’s the first problem: the lookup ran even when authentication had failed.
How the extra field became SQL injection
On its own, a surviving user-id would let an attacker choose which user record the code fetched. What turned it into SQL injection is how Metabase builds queries.
Metabase uses HoneySQL, a library that builds SQL from Clojure data structures. Normally values are sent as parameters, which is what keeps queries safe. But HoneySQL also supports a :raw form whose content goes directly into the SQL text, unparameterized. As Wiz’s analysis explains, a JSON object sent as user-id arrives as a Clojure map, and if that map has a raw key, HoneySQL treats it as a directive to insert the string into the query as-is.
Put together:
The attacker sends a reset request with any token, a valid-looking password and an extra user-id field containing a raw SQL fragment.
Validation passes, because the schema only checks the fields it declares.
The token check fails, so the authentication result has no user-id to overwrite the attacker’s.
The user lookup builds its WHERE id = ... clause from the attacker’s fragment and runs it against the application database.
The request fails with a 400 “Invalid reset token” error, but by then the injected SQL has already run against the application database.
We’re explaining the bug here, not handing out a working exploit. The exact payload depends on which database backs Metabase (H2, PostgreSQL, MySQL or MariaDB), and public proof-of-concept code has been available since August 10.
What the attacker gets: admin access and every connected database
The injection runs against Metabase’s internal store, not the customer’s data directly. That still gives an attacker a lot, because of what the internal store holds. The vendor advisory is titled “SQL injection using an unauthenticated endpoint leading to admin access”, and Bishop Fox lists what follows from it:
Full administrator access to Metabase.
Changing application settings, and reading secrets available to the running application.
Querying and exporting data from every database Metabase is connected to, with Metabase’s privileges.
That’s why the CVSS vector marks the scope as changed. The bug is in Metabase, but the damage reaches every database it can query.
Real incidents confirm this. Metabase confirmed active exploitation, CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 11, and companies including Framework, Tally, n8n and ChecklyHQ disclosed that customer data was accessed through their Metabase instances.
Reported data included names, email addresses, phone numbers, billing addresses, password hashes and API tokens.
How Metabase fixed the vulnerability
The fix shipped in 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5, with matching Enterprise 1.x releases. Self-hosted Metabase on the 58 to 63 release lines before those versions is affected, and Metabase Cloud was patched before the public advisory.
Looking at the reset and login code in Metabase’s current source, the problem is now closed in several places rather than one:
The endpoint schema is closed. It’s now [:map {:closed true} ...], so a request with undeclared fields is rejected.
Only the expected fields are passed on. The handler calls select-keys to forward :token and :password, and nothing else.
Request data can’t supply the identity fields. Before merging, the login code removes from the request every key that authentication is supposed to set, such as :user-id, :user and :success?.
No lookup without success. The user is resolved only when authentication actually succeeded, and only if user-id is a positive integer. Anything else is logged and refused.
Any one of these would have stopped this exploit. Having all four means a future mistake in one layer is less likely to become another CVE.
What to check if you run Metabase
Patching answers “am I still vulnerable?” It doesn’t answer “was I already compromised?”
If /api/session/reset_password was reachable from the internet on an affected version, the vendor and JPCERT both say to treat the instance as possibly compromised:
Look for the exploitation pattern. A POST /api/session/reset_password returning 400, followed by a GET /api/user/current returning 200. JPCERT says this sequence strongly suggests compromise. Wiz adds that legitimate reset requests contain only token and password, so any body with a user-id key is suspicious.
Check for the indicators JPCERT published. Requests between early August and early September 2026 from 213.163.202[.]171, 221.216.140[.]49 or 221.216.140[.]129, or with the user agents python-requests/2.33.1 or Metabase-GHSA-vwf4/2.0. JPCERT notes these IPs may be used legitimately by now.
Revoke and rotate. Delete all rows in the core_session table to end every session, remove API keys nobody recognizes, review administrator accounts, and rotate the credentials for every connected database.
Review the data side. Check Metabase’s activity and query history and your warehouse logs for queries or exports nobody on the team ran.
If you can’t upgrade right away, block /api/session/reset_password at the reverse proxy or firewall.
Lessons for developers
Validate what you receive, not only what you expect. A schema that checks required fields but accepts extras is a filter with a hole in it. On unauthenticated endpoints, reject undeclared fields, or pass on only the fields you need.
Don’t let request data share a namespace with trusted data. Merging user input into a map that also holds the authentication result means a missing key on one side becomes attacker input on the other. Keep them apart, or strip trusted keys from the input first.
Failure paths need as much care as success paths. This lookup ran after authentication had already failed. Code that runs on the error path is still reachable by anyone who can trigger the error, and on a reset endpoint that’s everyone.
Query builders still need you to know where the escape hatch is. HoneySQL parameterizes values by default, but its :raw form doesn’t. If untrusted data can reach a query builder as a structure rather than a scalar, check whether that structure can express raw SQL.
Treat internal tools as internet-facing when they are. JPCERT’s October alert singles out BI tools and employee systems: check them with the same measures as public-facing apps. A dashboard tool with stored warehouse credentials is one of the most valuable systems an attacker can reach.
🛠️ Tool of the Week: Blutter
On a server it investigated, JPCERT/CC found Android app files alongside files linked to two reverse-engineering tools: the JADX decompiler and Blutter.
The attackers were reverse-engineering apps to find the APIs behind them, then testing those APIs for weaknesses.
Blutter is the one built for Flutter apps.
What Blutter does
A decompiler like JADX doesn’t get far with a Flutter app, because the Dart code is compiled to native machine code in libapp.so. Blutter is built to reverse-engineer that file. It gives you:
The app’s code in assembly, with recovered function names.
A dump of the app’s Dart objects, where server addresses and hardcoded keys show up.
A Frida script template to hook the app at runtime.
How to use Blutter on your own app
Run it on your own app, or one you’re authorized to test. Look through the extracted objects for server addresses and hardcoded keys, and check what each key can access.
Limits
Android ARM64 only, and recent Dart versions. iOS support isn’t finished, and obfuscated apps aren’t fully supported.
It’s not a full decompiler. You get assembly and objects, not source code.
Setup needs build tools, and it may have to compile the matching Dart runtime first.
The takeaway
With tools like this, anyone who downloads your app can work out how it talks to your server. Keeping the API inside the app doesn’t protect it.
What protects it is the server checking, on every request, who is asking and what they’re allowed to see.
👏 Person of the week: Loren Kohnfelder
In 1978, Loren Kohnfelder wrote his undergraduate thesis at MIT, Towards a Practical Public-key Cryptosystem. It introduced the digital certificate: a signed record that ties a public key to a name. The certificates behind HTTPS today build on that idea.
At Microsoft, he and Praerit Garg created STRIDE, one of the most widely used ways to think through threats to a system. He also led security work for the .NET platform. At Google, he worked on the security team, helped found the privacy team and reviewed the security designs of large systems.
Now retired, he has put that experience into this issue’s Book of the Week.
For more than four decades of work on making systems secure by design, Loren Kohnfelder is our Person of the Week.
📅 Event of the Week
CODE BLUE 2026
CODE BLUE is an international security conference in Tokyo. Researchers from Japan, the rest of Asia, Europe and the US present their latest work, alongside workshops, contests and a track for speakers under 25.
After an issue about Japan’s breach wave, it’s the natural next stop. Most talks have Japanese-English interpretation, so you don’t need to speak Japanese to follow along.
One talk fits this issue closely. Shusei Tomonaga, CTO of JPCERT/CC, and Yuki Yano, from its Incident Response Group, are presenting Quality Assurance for Incident Response in the Age of AI.
After a breach, someone writes an investigation report. But how do you know that report actually backs up its conclusions?
In their talk, they describe how JPCERT/CC worked with 13 Japanese incident response providers, CSIRTs and SOC teams to write two checklists and a sample report, then built an LLM agent that reviews reports against them.
📍 Bellesalle Takadanobaba, Tokyo, Japan 📅 November 17–18, 2026
📚 Book of the Week
Designing Secure Software
This issue keeps coming back to one fact: attackers will work out how your system works. JPCERT found attackers reading mobile apps to map the APIs behind them.
Designing Secure Software: A Guide for Developers by Loren Kohnfelder, our Person of the Week, starts from that assumption. The book is about building security into a system’s design, not adding it at the end.
One of its patterns is Transparent Design: a system should stay secure even when attackers know exactly how it works. That doesn’t mean publishing passwords or keys. Those stay secret. It means the design itself shouldn’t depend on being hidden.
😅 The Meme
If one of your old vendors were breached tomorrow, how long would it take you to find out whether your customers were affected?
The Breach Brief,
Ostorlab Team