Odido, Booking.com, Basic-Fit: Dutch citizens data is exposed to hackers

Three very different Dutch companies leaked the data of millions of people. A telecom, a travel platform, a gym chain. If those three can get it wrong, the app you built in a weekend on Lovable almost certainly has.

Three breaches, three businesses, one pattern

Between February and April 2026, three household names in the Netherlands disclosed serious data breaches. Different sectors, very different tech stacks, same ending.

Odido: a phone call, a login, 6.2 million records

Odido, the Dutch telecom formed from the T-Mobile and Tele2 merger, confirmed on February 12 that hackers had accessed data tied to 6.2 million current and former customers. The attack itself happened between February 7 and 8. The technique was not a zero-day or some exotic exploit. It was social engineering.

A group linked to ShinyHunters impersonated Odido IT staff over the phone, tricked an employee into approving a multi-factor authentication prompt, and used that access to reach a Salesforce customer-contact system. From there they exfiltrated names, home addresses, email addresses, phone numbers, dates of birth, IBAN bank details, and identification document metadata (passport and driver's license numbers). Odido published a running timeline and FAQ on its cyber incident information page.

The attackers first demanded roughly one million euros, then dropped to 500,000. Odido refused to pay, citing advice from police and cybersecurity firms, and on March 1 the full dataset was dumped on the dark web. A follow-up analysis by NL Times found that the leak contained records for four Dutch ministers, a senior intelligence service employee, three people under government protection, and over 16,000 staff at strategic companies like ASML, Damen, and Philips. The Odido entry on Have I Been Pwned now makes it trivial for anyone to check if they are in the leak.

The takeaway on the attack itself: no exploit of Odido's code was needed. The human answered the phone, tapped "approve" on an MFA notification, and the attacker was in the CRM. The data was not encrypted at a level that mattered once the attacker held a valid session.

Booking.com: stolen tokens, hyper-targeted phishing

Booking.com confirmed on April 13 that hackers had accessed reservation data. According to BleepingComputer's reporting, the company force-reset reservation PINs and warned customers to watch for phishing. Exposed fields include names, email addresses, phone numbers, reservation dates, and the message history between guests and hotels through the platform. Payment card details were not accessed.

The mechanics here are the ones that have bitten Booking.com's ecosystem for years: attackers compromise the hotel side, usually by phishing hotel staff or stealing session tokens for the Booking.com extranet, then use the legitimate-looking channel to message guests. With real booking data in hand (property name, check-in date, reservation ID) the phishing message looks identical to a hotel notice, and fake "payment verification" pages harvest card details on the guest side. The Register's coverage notes the company is still investigating the exact scope and entry vector.

The takeaway on the attack itself: the value of a breach is not only what leaks, but what the leaked data enables next. Reservation metadata is a phishing toolkit.

Basic-Fit: one million members, including their visit logs

Also on April 13, Basic-Fit disclosed a breach affecting around one million members across six countries, with 200,000 in the Netherlands. The affected countries are Belgium, France, Germany, Luxembourg, Spain, and the Netherlands.

The leaked fields: names, home addresses, phone numbers, email addresses, dates of birth, bank details, subscription numbers, subscription type, and recent gym visits. Basic-Fit's own statement notes they do not store copies of ID documents and that passwords were not accessed. The unauthorized access was detected by system monitoring and stopped within minutes, according to The Record, but the data was already out.

The takeaway on the attack itself: "minutes of exposure" was enough. And the visit logs turn this into more than a privacy problem. If you know when a stranger regularly goes to the gym, you know when their home is empty.

Three totally different businesses. Same outcome: highly personal data is loose in the world, and regulators are paying close attention.

Regulators are acting quick.

The Dutch Data Protection Authority and the Netherlands Inspectorate for Digital Infrastructure are already assessing whether Odido had adequate controls in place. Under GDPR Article 32, companies must implement security measures "appropriate to the risk," and under Article 25, data protection has to be built in by design and by default. Not bolted on after the breach.

This is the part vibe coders tend to miss. GDPR does not care how fast you shipped or which AI tool you used. It cares whether a reasonable level of protection existed at the moment data was collected. If a consumer telecom with a full security team can get investigated, a solo founder who spun up a landing page with a contact form and a Supabase database is not off the hook. They are just less visible, until something goes wrong.

For context on which rules actually apply to your app, see our upcoming piece [ADD ARTICLE: The 5 GDPR Mistakes Every Vibe Coder Makes].

What we see in vibe-coded apps right now

In the past month at NEKOD, we ran 360° assessments on more than 10 apps built by vibe coders. The results were not encouraging.

On several of them, I was able to log in and see other users' details. Not through clever exploits. Through the front door. Missing authorization checks. Database tables with Row Level Security disabled in Supabase. Contact-form submissions stored without encryption, sometimes emailed in plain text. API keys hard-coded in client-side JavaScript. Admin panels reachable by anyone who guessed the URL.

We helped every one of those founders close the gaps. But those are the founders who asked. Most do not. They collect names, emails, phone numbers, sometimes IBANs for invoicing, and they assume "the platform" handles security. The platform handles hosting. It does not handle your data model, your auth rules, your consent flows, or your breach-notification plan.

This is the uncomfortable truth behind the Odido, Booking.com and Basic-Fit stories: if large companies with dedicated security teams can leak this much data, a vibe-coded app with none of that scaffolding is a ticking clock. The only question is whether the clock runs out before or after you have real customers.

For a concrete walkthrough of the most common issues we find, read The 5 Security Gaps Hiding in Every Vibe-Coded App.

"But my app is small" is not a defense

A common reaction from builders: "I only have 200 users, nobody is targeting me." Three things to keep in mind.

First, attackers do not target you. They target the platform you built on. Automated scanners sweep the internet for exposed Supabase projects, leaked API keys on GitHub, misconfigured storage buckets. Your app shows up in the same scan as a Fortune 500.

Second, the regulator does not care about your user count. If you collect a single EU resident's personal data without a lawful basis or adequate security, you are in scope. Fines scale with turnover, but enforcement starts with complaints, and one angry user is enough.

Third, small apps often hold disproportionately sensitive data. A waitlist form for a health product. A booking system for a therapist. A fitness coaching app logging client weight and workouts. Odido leaked identity documents. Basic-Fit leaked gym visits. What does your app leak if its database goes public tomorrow?

Context decides what's critical

Here is where most security content gets it wrong. It treats every app like it needs every check. That is not how real risk works.

A personal blog with no signup form does not need GDPR consent banners, encryption at rest, or breach-notification playbooks. A contact form that stores emails and phone numbers does. A booking app that stores addresses and payment info needs all of the above plus Row Level Security, audit logging, and a retention policy.

The right question is not "is my app secure?" It is "does my app handle the data it collects in a way that matches what it actually does?" That is the context-driven assessment NEKOD runs on every app. We do not dump a 200-page report. We tell you what matters for your app, given what it does and who uses it, and we give you a Launch Readiness Score you can actually act on.

Odido, Booking.com and Basic-Fit will be fine. They have legal teams, PR teams, and the balance sheet to absorb the fine. A solo founder does not. Which is exactly why the critical 5%, the gap between "it works" and "it's safe to ship," is worth closing before the first customer signs up, not after a regulator calls. If you are staring down that gap right now, our Solopreneur's Launch Checklist walks through exactly what to close first.

Key takeaways

• Three major Dutch breaches in eight weeks prove the same point: data held by your app is a liability the moment you collect it.
• Leaked data now includes IBANs, home addresses, identity documents, and behavioural patterns like gym visits. Phishing using real data is the next wave.
• GDPR Articles 25 and 32 apply regardless of company size. Small vibe-coded apps are not exempt, just less visible.
• In 10+ NEKOD assessments last month, the most common issues were missing auth checks, Row Level Security disabled, and unprotected contact-form data.
• What your app actually needs depends on what it does. Context, not a generic checklist, decides which controls are critical.

Before you launch, know what data your app stores

If you collect a single email, address, or payment detail, you are already in the same regulatory regime as Odido and Booking.com. The difference is they have a team to absorb the hit. You have a weekend and a founder.

Start with a quick check to see where your app stands, or run a complete 360° scan to get a full Launch Readiness Score with the exact fixes your app needs given what it does.

Do a Quick Check or Run a Complete Scan