There’s a scam pattern targeting Booking.com users that’s worth understanding because it breaks the rules of how we usually teach people to spot phishing.
How it works
Booking.com lets you log in by clicking a verification link sent to your email. No password required. It’s frictionless — and that’s the problem.
Here’s the playbook:
- Scammers obtain your email address from an unrelated data breach
- They go to Booking.com and trigger a login request for that email
- Booking.com sends you a genuine verification email — from their real servers, with their real domain
- They convince you to click it (or, in some variants, intercept the link itself)
The email is actually from Booking.com. No spoofing. No lookalike domain. No grammar mistakes. Your email security filters won’t flag it. Anti-phishing training won’t catch it — there are no traditional phishing tells, because it isn’t traditional phishing.
Why MFA doesn’t save you
I tried enabling multi-factor authentication on my Booking.com account to add a layer of protection. The verification link still grants login when clicked.
That’s the deeper issue: when a “magic link” is treated as a sufficient authentication factor on its own, MFA loses meaning. The link is the credential. If an attacker can get you to interact with it — or sit close enough to your inbox to grab it — they’re in.
The pattern worth naming
This isn’t a Booking.com bug. It’s a class of weakness in any system that uses email-based magic links as a primary authentication path:
- The email itself is genuine, so security tools don’t flag it
- The “trigger a login link” endpoint is usually unauthenticated
- MFA settings often don’t apply to the magic-link flow
- Users have been trained to trust emails that look legitimate
The whole point of MFA is that knowing one factor (your email) shouldn’t be enough. Magic links quietly collapse the model back to one factor.
What might actually fix it
I keep coming back to the same question: is passkey-based authentication the real answer here?
Passkeys bind authentication to a device you possess, not a link in an inbox someone else may also be reading. There’s no link to click, no link to intercept, no “trigger a login email” endpoint to abuse. The cryptographic challenge happens between the browser and the relying party — there’s nothing useful for an attacker to sit in the middle of.
Until then, the practical advice is uncomfortable: if a service uses magic links, assume the security floor is roughly the security of your email account. And don’t click verification links you didn’t ask for — even when they look completely legitimate. Especially then.