What these emails look like
The pattern is consistent across thousands of variations. The email arrives from a generic or professional-sounding address, claims the sender discovered serious security issues on your domain, and creates urgency — legal exposure, user data at risk, GDPR fines, reputational damage. It then asks you to respond, pay for a remediation report, or hire them immediately.
// Typical email pattern
Subject: Critical Security Vulnerabilities Found on yourdomain.com
Body:
Dear Website Owner,
During a routine security audit, our team discovered multiple critical vulnerabilities on your website including SQL injection, exposed admin panels, and unprotected user data.
These vulnerabilities could expose your users to data theft and put you in violation of GDPR and other regulations, resulting in significant fines.
We offer a full remediation report for $299. Please respond within 48 hours to avoid further escalation.
— Security Research Team
The specific details change — the claimed vulnerabilities, the price, the deadline, the threat — but the structure is identical. Vague technical language. Urgency. A dollar amount. No actual proof of any finding.
Why it's almost always a scam
Real security researchers don't operate this way. The security community has a well-established process called responsible disclosure: find a vulnerability, notify the affected organization privately, give them time to fix it, and only publish findings after a fix is in place. No payment is requested or expected.
Legitimate bug bounty programs — run by companies like HackerOne, Bugcrowd, and directly by large organizations — pay researchers for valid findings through structured programs. Researchers who find real vulnerabilities submit them through these channels, not cold emails to generic inboxes.
No specific evidence
Real findings come with HTTP request/response pairs, screenshots, reproduction steps. Scam emails describe vulnerabilities in generic terms that could apply to any website.
Requests payment upfront
Legitimate researchers report findings first and ask for nothing. Asking for money before providing any proof is the defining characteristic of a scam.
Creates artificial urgency
"48 hours or we escalate" is a sales tactic. Real researchers give organizations 90 days to remediate (the industry standard) before any public disclosure.
Generic sender with no verifiable identity
Real security researchers have a public profile — a CVE history, a GitHub, a published report somewhere. An anonymous email from a free address provider is not a security researcher.
Mass-sent to thousands of domains
These emails are sent in bulk using automated tools that crawl domain registrations and WHOIS records. The sender has never looked at your specific site.
What they actually did (and didn't do)
In most cases, the sender ran an automated tool against your domain for a few seconds — or did nothing at all and simply guessed. What passive reconnaissance actually looks like:
# Typical passive recon — takes under 60 seconds, fully automated curl -s -I https://yourdomain.com # check HTTP headers curl -s https://yourdomain.com/robots.txt # read robots.txt curl -s https://yourdomain.com/sitemap.xml # read sitemap whois yourdomain.com # owner info from registry dig yourdomain.com # DNS records
This is not hacking. Fetching a public URL is equivalent to visiting a website. None of it requires authorization, none of it constitutes unauthorized access, and none of it produces evidence of vulnerabilities.
More sophisticated versions run a tool like Shodan or a basic header scanner to check for missing security headers (X-Frame-Options, Content-Security-Policy, etc.). Missing headers are a hardening gap — not a vulnerability, and certainly not evidence of SQL injection or user data exposure.
Is passive scanning illegal?
In most jurisdictions, no. Laws like the CFAA (US) and Computer Misuse Act (UK) target unauthorized access — actually getting into systems, reading data you're not supposed to read. Fetching a public URL, reading headers, or checking DNS records is not unauthorized access. The legal risk runs the other direction: the person sending you extortion-adjacent emails may be committing a crime.
What real security research looks like
The contrast with legitimate security research is stark. A real researcher who finds a SQL injection vulnerability in your application will:
Find your security contact
Look for security.txt at /.well-known/security.txt, a security@ email address, or a published bug bounty program.
Send a private disclosure with proof
The email includes the specific endpoint, the exact payload, the HTTP request and response proving the vulnerability, and reproduction steps — not vague claims.
Give you time to fix it
Industry standard is 90 days from disclosure before any public release. The researcher coordinates the timeline with you.
Ask for nothing, or apply through a bounty program
Responsible disclosure asks for acknowledgment. Bounty program submissions go through a formal process with defined rewards. Neither involves a cold payment demand.
If the email you received doesn't look like steps 1–4 above, it is not from a security researcher.
What to do
Do not reply
Replying confirms your email is active. It invites follow-up, escalation, and potentially more targeted social engineering. Ignore and delete.
Do not pay
Payment confirms you can be pressured. It does not result in a legitimate security report and marks you as a viable target for repeat contact.
Do not click any links in the email
Links may be tracking pixels confirming delivery, phishing pages, or malware. If you want to verify a claim, navigate directly to the relevant service yourself.
Report it if you have the time
In the US: IC3 (ic3.gov). In the UK: Action Fraud. In the EU: your national cybercrime reporting agency. These reports help authorities track patterns across organizations.
If the email is more targeted than usual, take it to a lawyer
Sophisticated extortion attempts that reference specific data, name your customers, or make credible legal threats warrant legal review. A generic "we found SQL injection" email does not.
But what if your app actually has vulnerabilities?
This is the right question — and the one the scam email is designed to make you avoid thinking clearly about. The email's claim is almost certainly fabricated. But that doesn't mean your application is secure.
Most web applications have at least one exploitable vulnerability. The OWASP Top 10 categories — broken access control, injection, authentication failures — appear in production apps at every scale, including apps built with modern frameworks and careful engineers.
The difference between a scam email and actual security testing is evidence. Real testing produces HTTP proof-of-concept — the exact request that exposes the vulnerability, the exact response that confirms it. That's what you need to know whether something is genuinely exploitable, and what you need to hand an engineer to fix it.
If the email made you wonder whether your app is actually safe, the answer is to find out with a real test — not to pay someone who sent you a cold email with no evidence.