What customer data could actually have left my site
After a breach, the most urgent question isn’t how to clean up — it’s what got out. The answer depends on the entry point, and it is reconstructed from things already sitting on your server.
Two families of data, two different theft routes
The first mistake, when working out what may have left, is treating everything as one problem. Two things need separating, because they aren’t stolen the same way and aren’t proven with the same traces.
On one side, data already stored: orders, customer accounts, delivery and billing addresses, purchase history, the contents of configuration files. These are stolen through access to the server or the database, and usually leave usable traces — abnormal queries, export files appearing in a folder, spikes in outbound traffic.
On the other, data in transit: what the customer is typing right now, card details above all. If your payment is properly delegated to a provider, this never touches your database — and yet it can still be stolen, because the theft happens in the customer’s browser before anything is sent. That’s how script-based input theft works: it needs neither your database nor your backups.
The distinction isn’t academic. It decides where you look, and what you will actually be able to state at the end.
What should make you suspect data left
- Your email provider or another third-party service disables an access key without you asking.
- Customers report having had to enter their card details twice on a recent order.
- Your bank or payment provider flags an unusual concentration of fraud on cards used on your store.
- Archive or export files appear in a site folder you didn’t create them in.
- Outbound traffic from the server rises noticeably at hours when the shop is quiet.
- A customer describes seeing orders in their account area that are not theirs.
Working from the entry point to the reachable scope
The method that actually produces answers is to start from the entry point and work out what was reachable, rather than hunting at random for proof of theft. Incidents published over recent months show the scope varies enormously depending on the door used.
When the door is a tampered extension running server-side, the scope is very wide. In the distribution-chain compromise documented in June 2026 at a WordPress plugin publisher, the payload extracted the full contents of wp-config.php, administrator accounts, credentials stored by email-sending plugins, and the last three months of WooCommerce orders. That last point matters: the attacker didn’t take the whole database, they took a window. Knowing which window changes what you will have to tell your customers.
When the door is a passive exposure, the scope is narrower but usually much older. The advisory published in May 2026 on the upsshipping module for PrestaShop describes a publicly readable log folder whose XML files contained UPS API credentials, shipper account numbers, and customer names, postal addresses and phone numbers. In one observed case that folder held more than 2.3 million files, roughly 8.7 GB, spanning February 2023 to April 2026. There was no intrusion here: the data was simply readable, and had been for three years.
When the door is a poorly protected endpoint returning a technical report, what leaves isn’t your catalogue but your keys. The flaw fixed in March 2026 in the Gravity SMTP plugin returned around 365 KB of data containing API keys and OAuth tokens for connected email services, database details, WordPress and PHP versions, the plugin inventory and the active theme. No customer data in that batch — but enough to open several other doors.
Finally, when the door is a script inserted into your pages, only data typed during the infection period is affected, and none of it sits on your server. That’s the case with the double payment form card theft described by Sansec in February 2026, and it is also what the JavaScript loaded from a tampered configuration value did during the SQL injection wave PrestaShop reported in January 2025.
How I scope it
-
Date the exposure window
I cross-reference modification dates on the files that were dropped, the install date of the vulnerable or tampered version, and the first abnormal entries in access logs. It won’t be an exact date — a range is enough for what follows.
-
List what was reachable from that entry point
Code running server-side with the site’s own rights can read whatever the site can read: database, configuration files, exports. A passive exposure only yields the contents of a folder. A script injected into pages only yields what visitors typed.
-
Look for traces of exfiltration
Archives or exports created in upload folders, repeated requests to a single page with unusual response sizes, outbound connections to destinations the site has no reason to contact.
-
Check the third parties’ own logs
Your payment provider, email service or carrier dashboard keeps a usage history for your keys. Usage from an unfamiliar source is evidence, not a hunch.
-
Preserve everything before cleaning
Copy the logs, copy the suspicious files, capture the administrator account list. Cleaning before this step destroys exactly what would have answered the question.
The special case of customer passwords
This question comes up every time, and the answer deserves precision. On an up-to-date PrestaShop or WordPress install, customer passwords aren’t stored in clear text: the database holds a one-way hash. So a copy of the customer table doesn’t hand over passwords directly.
That reduces the risk; it doesn’t remove it. A hash can be attacked offline, with unlimited attempts and no visibility on your side, and weak passwords fall first. More importantly, the real risk isn’t your shop — it’s reuse. A customer using the same password on their mailbox simply moves the problem elsewhere.
There are also scenarios where the password is captured as it is typed, in clear text, never touching the database — the same mechanism as card theft. And scenarios where the account is taken with no password at all: the flaw fixed in October 2025 in the PrestaShop Checkout module allowed a silent login to a customer account from their email address. In both cases, forcing a password reset isn’t enough — the door has to be closed first.
Related reading
-
Checking whether your site is compromised
The free checks worth running before concluding anything.
-
What to do in the first two hours
The order of priorities once the doubt is confirmed, including preserving evidence.
-
Cleaning an infected site
Why restoring a backup isn’t enough, and how to proceed without destroying the evidence.
-
Reading PrestaShop error logs
Where the logs are, what they keep, and for how long.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.