Tracing a silent account overwrite across two WooCommerce stores

The incident

The brand runs two shops: a trade store for professional customers and a consumer store. One evening, a long-standing trade customer's account email was replaced with someone else's. WordPress sent its own "email changed" notification, so the timing was certain. At that same minute, an unrelated customer with the same first name had placed an order on the consumer store.

The audit log recorded nothing. There was no login, no password reset, no admin edit. The working theory, from the client and their previous advisers, was that the two shops shared one WordPress installation and had merged the two customers by mistake.

Ruling out the obvious explanation first

Before chasing the incident, we checked how the two sites were actually built, because the working theory depended on it. They were not one installation. They were two separate WordPress sites, on separate hosting environments, with separate databases. Their customer lists lived in entirely different places.

We told the client plainly that the most likely explanation could not be what happened. That narrowed the search: something had to be carrying data from one site to the other.

The cause

That something was a store-sync plugin that copies customer records from the consumer store to the trade store whenever an order is placed. Before copying, it checks whether the person already exists on the trade store. It made that check on the username alone.

Both customers had the same username. When the order arrived, the sync found the trade customer, treated her as the same person, and wrote the consumer customer's email onto her account. The plugin's own log recorded the update at that exact minute, matched on username, so the cause was confirmed rather than suspected. A second fault in the same code explained why only the email changed and her address and phone did not.

The fix

We wrote a small, focused plugin that sits in front of the sync. It uses the email address as the identity test. If an automated process tries to change an existing customer and the email does not match, nothing is written to that account at all. Normal syncing carries on, and the client's team can still edit customers in the admin exactly as before.

It was tested on the live site using a temporary test account that was deleted straight afterwards, so no real customer records were touched. We then checked every account the sync had ever linked between the two sites, including the administrator accounts. The final count was one affected account, and nothing outstanding.

The client asked for a plain-English explanation they could send the affected customer. We wrote it, so they could reassure her that this was not a hack and her account was safe.

The second risk

While tracing the sync, we noticed it also mirrored customer deletions. We did not assume. We tested it on a copy of the site with a dummy account: deleting a customer on the consumer store immediately deleted the matching account on the trade store. A trade customer with years of orders could have disappeared because of an action on a different shop.

In a short follow-up, we switched deletion syncing off, confirmed the account survived with the setting changed, and removed a hidden cross-store link from the affected customer's account. Her 21 orders, trade status and settings were left untouched.

Results

• Root cause established and documented, with the log extract available for the client's data protection records.
• A guard plugin that makes the same overwrite impossible, without changing how the team works.
• Exactly one affected account, verified by checking every linked record.
• A cross-store deletion risk proven on a copy and closed before it ever fired.

Client name and sites withheld at our discretion. Details are taken from the project record.