Anatomy of a fake bug bounty email
It always starts politely. Then, somewhere around sentence three, the friendly “security researcher” wants crypto. Here's how the shakedown actually works — and why the “critical vulnerability” is usually a missing DNS record.
You shipped something. Maybe it went a little viral, maybe it just got indexed. Either way, one morning there's an email in your inbox with a subject line engineered to spike your heart rate: “Critical vulnerability in your site — responsible disclosure.”
Nine times out of ten, it's not a researcher. It's a shakedown, and it follows a script. Once you've seen the script, you can't unsee it.
Hello, I am a security researcher. During routine testing I discovered a critical vulnerability affecting your website that puts your users at serious risk.
I am disclosing this responsibly. As is standard practice, I expect a bug bounty of $500 in BTC for my time. Please remit to the wallet below within 48 hours.
If I do not hear back, I will have no choice but to disclose publicly and notify your users of the risk they are exposed to.
Regards, X
The five moves
Every one of these emails is doing the same five things:
The authority costume
“Security researcher.” “Responsible disclosure.” “As is standard practice.” The vocabulary is borrowed to make an extortion note sound like a professional courtesy. Anyone can type these words. They mean nothing on their own.
The vague, scary finding
“A critical vulnerability.” Notice what's missing: no specifics, no steps to reproduce, no proof of concept. A real researcher shows you the bug— the request, the payload, the screenshot of the actual impact. A shakedown keeps it vague on purpose, because vague can't be checked.
The manufactured deadline
“Within 48 hours.” The clock exists to make you pay before you think. There is no real reason a disclosure needs a countdown — except to keep you in fight-or-flight instead of calmly verifying the claim.
The payment-first demand
Legitimate disclosure never leads with an invoice — and never with a crypto wallet. Real bug bounties (if you even run one) get paid after triage, on your terms, through a program you chose to set up. Money up front, in BTC, to a throwaway address is the tell.
The threat
“I'll disclose publicly and notify your users.” There it is. Strip away the costume and this is the entire product: fear. They're not selling you a security finding. They're selling you relief from a threat they invented.
What the “vulnerability” usually is
Here's the part that deflates the whole thing. When you finally see what they “found,” it's almost always something a free online scanner flagged in one click:
- No DMARC record — so email can be spoofed. Screenshotted straight from a free tool.
- Missing security headers — no HSTS, no Content-Security-Policy, no
X-Frame-Options. - A verbose server banner advertising your exact software version.
- An exposed
.envor.gitfolder — the one that's actually serious, which is exactly why you shouldn't reflexively ignore all of it.
These are real hygiene issues worth fixing. But they're config, not zero-days— and a stranger emailing you a scanner screenshot isn't doing you a $500 favor.
Shakedown vs. real researcher
The difference is almost always obvious once you know the tells:
- Vague & urgent
- Payment demanded up front (crypto)
- Threatens your users
- Templated, generic language
- Throwaway email address
- Specific, reproducible steps
- No demand — asks how to report
- Uses your security.txt / process
- Patient, professional
- Wants it fixed, not feared
What to actually do
- 1
Don't pay. Don't panic.
Paying doesn't make it go away — it marks you as someone who pays, and the next email is worse. Breathe. - 2
Don't hand over anything.
No credentials, no internal details, no “can you show me more?” over email. You don't owe an extortionist a conversation. - 3
Verify the underlying claim yourself.
If they named something real — an exposed.env, say — fix it and rotate any leaked secrets immediately, entirely independent of them. - 4
Close the hygiene so the next scan comes back empty.
Add DMARC. Set your headers. Lock down dotfiles. When the next lowlife runs their scanner, there's nothing to screenshot. You've become a boring target. - 5
Publish a security.txt.
A/.well-known/security.txtwith a contact line gives honest researchers a front door — and quietly signals you're not an easy mark.
The whole racket runs on one assumption: that you don't know what's actually on your own site, so a screenshot from a scanner feels like a threat instead of a to-do list. Take that away and the email is just spam.
Find out what a shakedown artist would find — before they do.
Scan your site free →