The scammer knows what you bought on Tuesday

What happened

Picture the corner shopkeeper who remembers everything. He knows the oat milk was missing from your bag last Tuesday, that you live on the third floor, and that your doorbell is broken. He writes it all down in a notebook so he can help you faster next time. Now picture someone photographing that notebook. Next, they call you, and they sound convincing, because they know everything about you.

On 5 October 2026, Kifli.hu, the Hungarian online supermarket of the Czech Rohlik group, lost exactly that kind of notebook. The company detected unauthorised access and data downloads in its internal customer service system. According to its statement, it shut off the access the same day, fixed the flaw, and emailed affected customers on 11 October.

According to the company’s letter and several consistent press reports, this may have been taken:

emails sent to customer service since 8 July 2026;
chat and phone call transcripts since 21 April 2026, whether you spoke to a person or the virtual assistant;
files uploaded to those conversations;
the names, email addresses, phone numbers, delivery addresses and order numbers in them;
products recently added to or removed from the basket;
the virtual assistant’s short notes on what you wanted.

The same weekend, the group’s Czech business, Rohlík.cz, announced that data had been downloaded from its customer service tool and reported the case to the Czech cybersecurity and data protection authorities. The Czech company explicitly said its login and payment systems were not affected. The Hungarian statement contains no such sentence; it only says a customer service system is involved, not the full customer database. The company hasn’t publicly said whether the two cases are the same intrusion, though the timing and descriptions suggest so.

What we still don’t know as of 22 October 2026: how many customers are affected, how the attackers got in, whether the tool was built in-house or supplied by a vendor, and who is behind it. The April date shows how far back the leaked conversations go, not how long the attackers were inside. There is also no public report yet of a fraud wave using the leaked data. That’s good news, but no reason to relax: data like this can be used weeks or even months later.

Why it matters to you

You can change a leaked password. What you can’t undo is someone knowing your order, what was missing from it, and where you asked for delivery. To a scammer, that context is worth more than a password, because it makes them believable.

If you chatted with or called Kifli’s customer service since 21 April 2026, or emailed them since 8 July, expect that someday someone may contact you in their name. The company itself warned that scammers may pose as customer service or as a staff member handling a refund.

And if you run a business: your customer service system is probably your most candid database. Customers write everything there, sometimes things that don’t belong there. According to Rohlík, some Czech customers even shared passwords or card details in conversations; they were notified separately.

The wider context: according to Origo, Kifli.hu was Hungary’s second-largest online retailer in 2024, and its parent group operates in several countries (as Knuspr in Germany, for example). There’s no public report of affected customers outside Hungary and the Czech Republic. It’s also not public whether Kifli notified NAIH, Hungary’s data protection authority. Under the GDPR, a serious breach must be reported within 72 hours, so it’s likely, but unconfirmed.

Red // attacker's view

How they got in, I can’t tell you. I’m not being coy: nobody knows that publicly. What I can tell you is what a scammer does with a notebook like this.

Context is the treasure, not the password. Order number, missing item, past complaint, basket contents. That’s what I build a pretext from, and three obvious ones present themselves: a refund (“we’d like to credit the missing item, just confirm your details”), a customer service callback (“I’m calling about your complaint last week”), and a code request over a “suspicious login”. This is impersonation phishing at its most convincing.

A real detail switches off suspicion. If I know what was missing from your bag last week, why would you doubt me? And urgency makes sure you don’t have time to think.

The AI assistant wrote my script for me. The virtual assistant’s notes summarise what you wanted and what bothered you. I don’t need to invent a story; I just read it out.

Customer service is a house with many doors. Lots of staff, sometimes outside partners, integrations and AI tools all reach the same notebook. In October 2025, attackers got into Discord’s support conversations through an outside customer service partner. Whether that’s what happened at Kifli, we don’t know. The better question is how many doors open onto that notebook at your company.

Blue // what to do now

As an individual (as a Kifli customer, but at any other online shop too)

If someone calls or writes in Kifli’s name, hang up or don’t reply, and contact them yourself through the app or by typing the kifli.hu address into your browser.
Don’t click links in messages, and don’t install anything to get a “refund”.
Never give a password, online banking details, your card’s security code or an SMS code in response to an unsolicited call or message.
If you ever typed a password into a customer service chat, change it everywhere you use it. If you shared bank details, call your bank right away.
Tell your parents and grandparents: they get the most convincing calls.

As a business (online shop, service provider, anyone running customer service)

Treat your customer service platform (ticketing, chat, call recording, AI assistant) as a high-value data store: multi-factor authentication, logging, monitoring for bulk exports and unusual logins.
Set retention periods, and turn on automatic masking of card number and password patterns if your system supports it.
Review who can access the system (staff, outside partners, integrations, AI tools), revoke what isn’t needed, and make sure access can be pulled quickly.
Tell your customers upfront, plainly: “this is how we contact you, and this is how we never do”, naming your official channels. In an incident, make that the first paragraph of your letter.
After an incident, don’t stop at plugging the hole: find out how the flaw got into the system (that’s what Péter’s note below is about).

For professionals: technical details

CVE, affected product: unknown; the company named neither the system nor a vulnerability. It’s not known whether the tool is in-house or vendor-supplied.
Leaked data (HU): customer service emails since 8 July 2026; chat and call transcripts since 21 April 2026 (human agents and virtual assistant); attachments; PII (name, email, phone, delivery address); order numbers; basket events; the AI assistant’s summary notes.
Different periods (CZ): Czech reports say chats from 1 April to 5 October, call transcripts from 28 April to 5 October, and emails from 28 June to 22 September 2026. The reason for the difference is unknown.
Likely MITRE ATT&CK techniques (for the follow-on, not the intrusion): T1566 / T1598 (phishing using leaked context), T1656 (impersonation). The intrusion technique is unknown.
Detection ideas for customer service platforms: bulk exports or API queries, agent logins at unusual times or from unusual locations, new integration tokens or apps, high-volume attachment downloads.
Official guidance: the company’s own advice (see Blue). The Czech authorities (NÚKIB, ÚOOÚ) were notified and have not published guidance on the case.
Indicators: none published.
Precedent: on 3 October 2025, Discord disclosed that attackers had accessed support conversations and ID photos of around 70,000 users through an outside customer service partner.

Péter // the chief's note

In this case, there’s very little information about how the attack itself worked: we don’t know how they got in, whether the tool was in-house or a vendor’s, or who’s behind it. That makes it hard to analyse. So let’s talk instead about how the incident response itself went.

From a communications point of view, it seems Kifli took the steps you’re required to take in a situation like this. They detected the unauthorised access on 5 October and, according to the company, shut it off the same day. On 11 October they wrote to customers, said which data was affected, and specifically warned that scammers might pose as customer service. So in theory, they fixed the flaw quickly once they found it.

But there’s a real question about how long the flaw was exploitable, and how it got into the system in the first place. The public statements don’t answer that. This is when you have to review the security controls built into the development cycle, and it’s worth looking at security testing practices and earlier test reports too: did an earlier test flag anything, and if so, what happened to it? Strengthening those controls can make it far less likely that something like this happens again.

Unfortunately, in my experience, in today’s rushed, agile development world these principles often slip into the background because of the pace, even more than they did in classic development models. That’s why applying the security by design principle matters: security shouldn’t arrive at the end as a final check, but be part of the requirements from day one of design.

A fast response is good news. But good incident response doesn’t stop at plugging the hole: it also asks how the hole got there, and what will stop it from appearing again.

Background report for professionals

The full research in one PDF

Timeline, actors, how the attack works, actions for each audience, technical details and source assessment. All in one place, printable and easy to pass on.

PDF · 5 pages · 149 KB · research revision v1

Open the PDF (English) Magyar eredeti (PDF)

Sources

Made with an AI crew, reviewed by Péter