# A customer ended up logged into someone else’s account > A shopper sees orders that aren’t theirs, or you get a complaint about an address nobody ever entered: that is an authentication flaw, and the checkout flow is a classic place for it. - Source canonique : [https://allaux.fr/en/securite/client-connecte-sur-le-compte-d-un-autre](https://allaux.fr/en/securite/client-connecte-sur-le-compte-d-un-autre) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Replay the journey in a private window, on another device, with no account. If a first name, a basket or an account block shows up to a visitor who never had an account, a personalised page has been cached and the cache is your lead. If the content only appears after login, look at the session cookies and the cart identifier instead. ## Three causes, one symptom The report almost always arrives in the same words: a customer sees orders in their account that aren’t theirs, or you get a complaint about a delivery address nobody ever entered. The first reflex, mine included for a long time, is to blame the cache. Sometimes it is the cache. Not always — and the difference completely changes what you do next. Three distinct causes produce this same symptom. A badly configured cache. A personalised page — a header with a first name, a basket, an account block — was cached during one customer’s visit and then served as-is to another visitor. The content is wrong, but the session itself is still correct. A shared session. Two people use the same browser on the same machine: a family computer, a reception desk, an in-store tablet. The open session was simply never closed. A genuine authentication flaw. The server really did tie the session to the wrong account. That is no longer a display problem: it is account takeover. ## What customers describe - A customer sees orders in their history that they never placed. - An unknown delivery address appears in a customer account. - The first name shown in the header isn’t the logged-in person’s. - An order was paid from an account whose owner says they never placed it. - A customer says they arrived already logged in without entering any password. - Logins or account creations appear at times that match nothing. ## The test that tells the three causes apart 1. **Replay it from a clean context** — Private window, another device, another network, logged out. If personalised content shows up for a visitor who has never had an account on the shop, you are very probably looking at a cache problem. 2. **Compare a cached page with one that isn’t** — A header or a page block can lie easily. The account detail page much less so. If it shows the right owner, this is a display problem. If it shows the other person, the server-side session already points at the wrong account. 3. **Check whether a real action goes through** — A page served from cache doesn’t let you act: a saved change lands back on the right account. If an address, a password or an order can genuinely be changed on someone else’s account, it is not the cache. 4. **Rule out the shared machine** — Logging out and back in with their own credentials settles the shared-browser case for good. If the problem returns on a personal device never lent to anyone, that cause is out. 5. **Open the authentication logs** — This is the only step that truly decides. It needs access to server and application logs, and it has to cover the whole period concerned, not just the day of the report. ## When it really is an authentication flaw The checkout flow is where this kind of flaw shows up most often, and express payment is its most sensitive point. Express payment exists precisely to remove steps: the customer arrives from a button, the payment method supplies an identity, and the shop must decide in a fraction of a second which account to attach the order to. Every step removed is a check that has to be done properly somewhere else. PrestaShop’s official payment module, ps_checkout, was affected by this. A missing validation on the Express Checkout feature allowed a silent login, and therefore takeover of a customer account from its email address. The flaw is CVE-2025-61922, with a CVSS score of 9.1: network exploitable, low attack complexity, no privileges required, no user interaction. Fixes were published on 16 October 2025, in versions 4.4.1 and 5.0.5. Silent login is worth translating into plain terms. The shop opens a session in a customer’s name without that customer entering a password and without telling them. On their side, nothing happens: no email, no confirmation request, no visible trace in their account. That silence is what makes the problem slow to detect. There are no failed attempts, no run of login errors to spot — just one more session that, from a distance, looks entirely normal. ## What a customer account actually holds People underestimate what an account gives whoever gets into it. It isn’t only a purchase history. The full order history: what was bought, when, for how much, delivered where. The address book: postal addresses, phone numbers, sometimes a work address and a company name. Contact details, directly reusable for convincing phishing aimed at that customer, because they allow a real order to be quoted. The ability to place an order from the hijacked account, using payment methods stored on the provider’s side where any exist. On that last point I stay careful, and you should too. What is genuinely reusable depends entirely on the payment provider and on how stored payment methods are implemented. The shop does not normally hold the card number. What I can state without logs is what was possible; what was actually done, I cannot. ## What the logs say, and what they won’t The advisory for this flaw recommends updating without delay, reviewing authentication logs, warning potentially affected customers, and watching for unusual orders and account creations. In practice, here is what I look for. Successful logins that no login form submission preceded. Logins to the same account from two very different contexts within a short window. Orders placed immediately after a login of that kind. Email, password or delivery address changes followed by an order. Bursts of account creations, or accounts built on the same address pattern. And here is what I cannot know without those logs: how many accounts were touched, whether a single customer was targeted or the shop was swept methodically, from exactly what date, and whether the access was used for anything beyond placing an order. Retention that is too short on the hosting side can leave those questions permanently unanswered. That is worth checking before you need it, not on the day a customer calls. ## A customer account holds personal data, so the GDPR applies > As soon as a security incident leads to the accidental or unlawful unauthorised disclosure of personal data, it is a breach under the GDPR. Every breach must be entered in an internal register, including the ones you do not report. If it presents a risk to people’s rights and freedoms, it must be notified to the supervisory authority — the CNIL in France — within 72 hours of becoming aware of it. If the risk is high, the individuals concerned must also be told directly, with protective advice. If you conclude there is no risk, you notify nobody, but your assessment must stand up to scrutiny. ## Related reading - **Suspicious orders and customer accounts** — How to read a run of orders or accounts that looks like nothing usual. ([/securite/commandes-comptes-clients-suspects](/securite/commandes-comptes-clients-suspects)) - **The checkout flow** — What the term actually covers, and why it is a sensitive area. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande)) - **PrestaShop payment problems** — When checkout misbehaves without security being involved. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement)) - **Checking whether my site is compromised** — What to do when the doubt covers the whole installation. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis)) ## FAQ ### Does this necessarily mean I’ve been hacked? No, which is why I always start with the separation test. A misconfigured cache and a shared machine produce exactly the same story from the customer’s side. Only a non-cached page and the authentication logs settle it. ### My payment module is up to date — am I safe? You are safe from the patched flaw, not from the symptom. An update closes the door going forward; it doesn’t undo what may have happened before. If your shop ran a vulnerable version, the log review is still needed. ### Do I have to warn the customers concerned? The advisory for this flaw explicitly recommends informing potentially affected customers. Beyond that, the GDPR requires informing individuals when the breach presents a high risk to their rights and freedoms. ### Should I log every customer out? It is a reasonable step after patching, just like closing admin sessions. It costs a little convenience and it removes every session opened while the flaw was exploitable. ### How can I tell whether an order was placed from a hijacked account? By matching the order against the login that preceded it: login context, absence of a login form submission, divergence from the account’s habits. Without authentication logs, that check isn’t possible.