Škoda's online shop was breached. The logs can't tell anyone what walked out.

Volkswagen Group subsidiary Škoda Auto confirmed on 11 May 2026 that attackers exploited a vulnerability in the software running its consumer online shop and reached customer personal data. The car maker’s own security monitoring picked the intrusion up, the shop was pulled offline, the flaw was patched, external forensics were engaged, and the European data protection authorities were notified. By the early-response checklist, this is textbook handling.

What follows is the awkward part. Škoda’s investigators have told customers they cannot confirm whether any data was actually exfiltrated. The logs that would tell them — what queries ran during the intrusion window, which records were returned, whether bulk reads or scripted access occurred — are not granular enough to answer the question. The customer notification therefore moves to the next worst position. Treat your data as compromised because we cannot prove that it was not.

The exposure window includes customer names, postal addresses, email addresses, phone numbers, order history, account information, and password hashes. Payment card data sat with a third-party processor and was not in scope. That is one architectural decision Škoda got right: the card data was never the e-commerce platform’s to lose in the first place.

The hash exposure is where defenders should now be paying attention. Even with a modern slow-hashing algorithm and a sensible password policy, a leaked hash combined with the email address it was set against is a credential-stuffing dataset. Anyone who reused a Škoda shop password on a higher-value account — their primary email, online banking, the connected-car app — has just been quietly added to somebody else’s target list. The lifespan of value in a stolen hash is years, not days.

The defender lens worth taking from this incident is the logging one. Most breach reporting focuses on root cause — which vulnerability let the attacker in. The Škoda disclosure is a reminder that the second-order question — what exactly the attacker did once they were inside — is just as costly to get wrong. A vulnerability that gets patched in a weekend can result in a notification obligation that covers every customer the system has ever held, because the alternative is an evidence vacuum that no regulator will accept on faith. Logs that record only the fact of a session, rather than the data shape of what that session touched, fail this test.

Three operational notes fall out of this story. First, e-commerce platforms running on widely-used “standard shop software” remain a recurring attack surface, and the working assumption that the platform vendor’s defaults are good enough is one that increasingly does not survive contact with a real attacker. Second, password hash storage policy needs to assume eventual exposure: slow algorithms, salt and pepper, mandatory rotation on incident, and no inheritance of legacy weakly-hashed records from earlier platform versions. Third, the logging requirement has changed shape. It is no longer “did someone log in”; it is “what did they read, at what rate, against what records”. The first version answers the question the SOC needed yesterday. The second version answers the one a regulator will ask tomorrow.

Škoda has done the conventional things competently. The unresolved question — whether customer data was actually taken — is one the logs cannot answer. That is the part of the breach playbook still being written across the industry, and the part most worth getting in front of before the next disclosure lands on someone else’s desk.