Someone Emailed Saying They Found a Vulnerability on Your Website. Read This Before You Pay Anything.
If you run a website or small app, there is a good chance you will eventually receive an email from a 'security researcher' who has found a vulnerability and wants payment. Most of these are a scam with a specific name: beg bounty. Here is how to tell the difference, what to do, and how to make sure it never catches you off guard.
The Email
It arrives in your inbox looking professional. The sender describes themselves as an independent security researcher or ethical hacker. They say they have discovered a vulnerability in your website. They explain, sometimes in quite technical language, what the issue is and why it represents a risk. And then, near the end, they mention that they would appreciate a reward for their responsible disclosure, typically somewhere between $150 and $500 to start.
If you do not have a bug bounty program and have never invited anyone to test your site, this email is almost certainly not what it looks like.
It has a name: a beg bounty. And it is one of the most common low-skill scams targeting website owners and solo founders right now.
What Is a Bug Bounty, and What Is a Beg Bounty?
A legitimate bug bounty program is a formal arrangement where a company publicly invites security researchers to test their systems, defines what is in scope, and commits to paying verified, meaningful findings according to a published scale. Companies like Google, Microsoft, and Apple run these programs. So do many SaaS products. The researchers who participate find real, exploitable vulnerabilities and disclose them responsibly. Everyone benefits.
A beg bounty is something else entirely. The sender runs an automated scanner against your website. The scanner checks for a list of common, easy-to-find misconfigurations, things that take seconds to detect and require no skill. The sender pastes the output into a template email and sends it to you. They did not find anything through skill or effort. They pressed a button.
The critical distinction: you did not invite them. You do not have a bug bounty program. They scanned you without permission, found something a free tool can detect in thirty seconds, and are now asking to be paid for it.
What They Actually Find
The issues that appear in beg bounty reports are almost always the same short list:
Missing DMARC record. DMARC is an email authentication standard that helps prevent your domain from being used to send spoofed emails. It is configured via a DNS record. Many small websites do not have one set up. This is worth fixing, but it is not a vulnerability in your website. It has nothing to do with your website code. It takes about ten minutes to configure. The beg bounty sender did not discover it through any skill; they ran a free DNS lookup.
Missing or weak SPF record. Same category as DMARC. An SPF record tells email servers which servers are allowed to send email from your domain. Missing or misconfigured SPF is worth addressing. It is not a secret finding.
Missing security headers. HTTP security headers like Content-Security-Policy, X-Frame-Options, and HSTS are instructions your web server sends to browsers. Missing headers are a common misconfiguration. They can be detected by any free tool in seconds.
Insecure cookie settings. If your cookies lack the HttpOnly, Secure, or SameSite flags, that is worth fixing. It is also detectable by opening browser developer tools on your own site.
Open directory listing or exposed files. If your server is configured to list directory contents, or if files like .env or .git are publicly accessible, that is a genuine issue. But again, a free scanner finds this instantly.
None of these require expertise to find. None of them required the sender to invest more than a few seconds. And in many cases, the "finding" is not even a vulnerability in any meaningful sense: a missing DMARC record does not give anyone access to your application or your users' data.
How the Scam Escalates
The opening email is usually polite. It frames the sender as doing you a favour. The requested amount is kept small enough that paying feels easier than investigating.
If you pay, two things happen. First, more emails follow. The sender now knows you respond and pay. They run more scans and find more items on the same checklist. Demands increase. One documented case started at $500 and reached $5,000 within a few weeks, with the tone becoming increasingly threatening.
Second, paying does not fix anything. The sender has no obligation to stop reporting the same issues, or to keep quiet about them. You have spent money and your site is unchanged.
Some senders escalate to explicit threats: pay, or they will publish the findings publicly, report you to regulators, or notify your customers. This crosses from irritating into extortion, and it is worth treating it as such.
How to Tell a Legitimate Report from a Beg Bounty
Not every unsolicited vulnerability report is a beg bounty. Genuine security researchers do sometimes find real issues in sites that have no formal program, and they disclose responsibly because it is the right thing to do. Here is how to tell them apart.
A legitimate researcher:
- Provides enough detail to reproduce the issue without you having to pay first
- Does not demand payment before disclosing what they found
- Reports something specific to your implementation, not a generic misconfiguration any scanner finds
- Does not threaten to publish if you do not respond within 48 hours
- Has a verifiable online presence (GitHub, security conference talks, a professional profile that predates your conversation)
- Accepts a genuine "thank you, we will fix it" if you do not have a formal bounty program
A beg bounty sender:
- Uses templated language that could apply to any website
- Reports something that a free tool finds in seconds (DMARC, headers, cookie flags)
- Asks for payment upfront or makes payment a condition of receiving the full details
- Applies pressure with a deadline or a threat to go public
- Has little or no verifiable presence outside of the email itself
- Escalates quickly when you do not respond
The DMARC email is perhaps the most recognisable. You will receive a message with a subject line like "Security Vulnerability Found on yourdomain.com" that explains your domain has no DMARC record and this could allow spoofing attacks, and asks for payment for the disclosure. This is sent to thousands of domains. The sender ran one DNS query per domain.
What to Do When You Receive One
Do not pay. Payment does not make the problem go away. It confirms you are a target worth continuing to contact.
Do not ignore the underlying issue entirely. If they found a missing DMARC record or a misconfigured header, those things are worth fixing on their own merits, just not because someone is demanding money for finding them. Fix it because it is good practice, not as a reward.
Do not engage with the sender. Responding, even to decline, confirms your email address is active and monitored. Engaging tends to invite escalation.
If they are threatening: document everything. Save the emails. If the demands become explicit (pay or I will publish, pay or I will report you), that is extortion, and it is worth reporting to your national cybercrime authority. In the US, report to the FBI at ic3.gov. In the UK, Action Fraud. In Finland, NCSC-FI (Traficom).
Check the finding independently. If someone says you have a misconfigured security header or a missing DMARC record, verify it yourself using free tools like MXToolbox for email authentication or SecurityHeaders.com for HTTP headers. If the finding is real, fix it through your own process. You do not owe the sender anything for pointing at something any automated tool can find.
How to Get Ahead of It
The most effective defence against beg bounty emails is fixing the things they report before they report them. If your DMARC record is configured, your security headers are set, your cookies are flagged correctly, and there are no exposed files, the standard beg bounty checklist comes back empty.
This is exactly what a pre-launch security audit covers. Tools like CanIShip run these checks automatically as part of a broader audit. CanIShip checks for missing DMARC, SPF, and DKIM records, misconfigured security headers, insecure cookie settings, exposed sensitive files, CORS misconfigurations, and error leakage, then gives you a plain-English report on what to fix. For a solo founder or indie builder shipping a new product, running this audit before launch means that when a beg bounty email arrives, you already know what your site looks like from the outside.
It does not prevent the emails from coming. Anyone with a scanner can still run it against your domain. But it means you will not be caught off guard by the findings, you will have already fixed the issues that have real merit, and you can recognise the email for what it is.
The Broader Context
Beg bounties exist because the line between a legitimate vulnerability disclosure and an automated scan with a payment demand is not obvious to most site owners. The security researcher persona is credible. The technical language is intimidating. And the amounts requested are deliberately kept small enough that paying feels like the path of least resistance.
The people sending these emails are banking on the fact that you do not know what DMARC is, do not know whether your security headers are configured, and do not have the time to find out. For many small business owners, that bet pays off.
The counter to it is straightforward: know what your site looks like before they tell you. Fix the real issues on your own timeline. And treat any unsolicited payment demand, no matter how it is framed, as the commercial pressure it is.
You can run any suspicious domain through RiskScope to check for threat signals and business legitimacy before engaging with anyone who contacts you about your site.
Related Reading
- Protect Yourself from Online Shopping Scams: how to assess any external claim about your accounts or transactions before acting on it
- Got a Text About an Unpaid Fine?: the same pressure tactics used in beg bounties, applied to consumers via text message
- How to Spot AI-Generated Fake Ads: recognising manufactured urgency and false authority across different scam formats
Sources: Sophos: Have a Domain Name? Beg Bounty Hunters May Be on Their Way, Infosecurity Magazine: Experts Warn of Beg Bounty Extortion Attempts, Computer Weekly: Dealing with the Challenge of Beg Bounties, Scott Helme: Bug Bounties and Extortion, DMARC Report: No DMARC Record Found Bug Bounty Is Actually a Beg Bounty, Red Sift: What Is a Beg Bounty?, SC Media: What to Do When a Bug Bounty Request Sounds Like Extortion, KnowBe4: Bogus Bug Reports as Phishbait, Indie Hackers: Received Cold Email from Ethical Hacker
Check Any Website Yourself
RiskScope is free. No signup required. Enter any domain and get an instant risk assessment.