# 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.

- Source canonique : [https://allaux.fr/en/securite/quelles-donnees-clients-ont-pu-partir](https://allaux.fr/en/securite/quelles-donnees-clients-ont-pu-partir)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Date the exposure window before anything else: modification dates of the dropped files, install date of the vulnerable version, first abnormal lines in the host error_log. Derive the perimeter from where the code ran: server-side, everything the site can read; browser-side, only what was typed during that window. Save the logs before they rotate.

## 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## What can almost never be proven

> In most cases it is impossible to demonstrate that no data left. Access logs are often kept for a few days only, and a database extraction run from the site itself looks like ordinary traffic. What can be established is the scope of what was reachable during a dated window. That scoping — not proof of absence — is what your risk assessment and your reporting obligations rest on.

## 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. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **What to do in the first two hours** — The order of priorities once the doubt is confirmed, including preserving evidence. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Cleaning an infected site** — Why restoring a backup isn’t enough, and how to proceed without destroying the evidence. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Reading PrestaShop error logs** — Where the logs are, what they keep, and for how long. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))

## FAQ

### How long after an incident can you still work out what left?

It depends entirely on how long your access logs are retained — often days to weeks on shared hosting. After that you still have file modification dates and third-party service logs, which lets you date the exposure window but rarely trace the extractions themselves.

### My card data sits with my payment provider, so I’m safe?

For stored data, yes. For data being typed, no: a script injected into the page surrounding the form can capture keystrokes before anything reaches your provider. Sansec documented a variant in February 2026 where a fake form appears before the real one, so the customer enters their card twice without noticing.

### Should I force every customer to change their password?

Only after the entry point is closed, otherwise you’re asking customers to type a new password into a still-compromised site. And it fixes nothing if the account can be taken without a password at all, as in the flaw patched in October 2025 in the PrestaShop Checkout module.

### Can data be exposed without any intrusion?

Yes, and it’s common. The May 2026 advisory on the upsshipping module for PrestaShop describes a log folder that was simply readable from outside, containing API credentials and customers’ personal data. Nobody needed to break in — they only needed to read.

### Can you tell me for certain that nothing left?

No, and in most cases nobody honestly can. I can establish what was reachable, over which period, and whether traces of exfiltration remain. That scoping is then what decides what you report and what you tell your customers.