What to Do When You Receive a Bug Bounty Email

by Deepak Gupta on June 15, 2026

At some point, most companies with a website get the email. A stranger writes to say they have discovered a security vulnerability in your systems, and they would appreciate a reward for letting you know.

Your reaction in the first ten minutes matters. Handle it well and you might fix a real issue and build goodwill with a skilled researcher. Handle it badly and you could ignore a genuine warning, overpay a low-effort scanner, or, in the worst case, mishandle something that has legal implications. I have been on multiple sides of this: running security for products at scale, receiving these emails, and watching other companies get it wrong.

The hard part is that these emails fall into three very different categories that can look similar at first glance: a legitimate vulnerability disclosure, a low-effort “beg bounty,” and outright extortion. Your response should be different for each. So let me give you a clear way to tell them apart and a practical playbook for what to do and what to avoid.

Email type	Hallmarks	The right response
Legitimate disclosure	Specific, reproducible issue; any reward requested politely, after the details	Fix it, respond constructively, thank them
“Beg bounty”	Generic scanner output; a vague reward hint; typically a $150-2,000 ask	Assess; usually decline; do not reward non-issues
Extortion	Payment demanded as a condition; threats to publish or exploit	Treat as a legal/security incident; involve counsel

The Three Kinds of Email You Might Be Getting

The first task is classification, because the right response depends entirely on which of these you are dealing with.

1. A legitimate vulnerability disclosure. A genuine researcher has found a real, specific issue and is reporting it responsibly. The hallmarks: they describe a concrete vulnerability with enough detail to reproduce it, they explain the potential impact, and, if they mention a reward at all, they do so politely and after providing the information, not as a precondition. Good-faith researchers following responsible disclosure norms do not hold the details hostage. This is the email you want, even when it stings, because someone is helping you find a real problem before an attacker does.

2. A “beg bounty.” This is the most common category by volume, and it is a gray area rather than a scam. Someone ran an automated scanner against your site, copied the output into a templated email, and is hinting that a reward would be appreciated. The “vulnerabilities” are usually generic findings: missing optional security headers, theoretical issues already mitigated by your hosting, or weaknesses that do not actually apply to your environment. Security researchers have documented that these requests typically ask for somewhere between $150 and a couple thousand dollars per “bug,” and that on investigation, the findings frequently do not warrant any payment. The sender is not necessarily malicious; they are running a low-effort numbers game across many companies.

3. Extortion. This is the dangerous category. The sender demands payment as a condition of telling you the details, or threatens to publish the vulnerability, report you to regulators, or exploit it unless you pay. The OWASP vulnerability disclosure guidance is explicit that demanding payment in exchange for not publishing or reporting details may constitute extortion. When a “researcher” leads with a threat and a payment demand rather than helpful information, you have crossed from disclosure into something closer to a ransom situation, and it should be treated accordingly.

The distinction between these three is not always obvious from the first email, which is exactly why your initial response should be measured and information-gathering rather than reactive.

What to Do

Here is the practical sequence when one of these lands in your inbox.

1. Stay calm and do not panic-reply. These emails are often written to create urgency and alarm. Resist that. Nothing about a typical disclosure requires you to respond within minutes. A measured response a day later is far better than a panicked one in the first hour.

2. Acknowledge receipt politely, without committing to anything. A short, professional acknowledgment is good practice for genuine researchers and harmless for the rest. Thank them for reaching out, say you take security seriously, and that you will review the report. Do not promise a reward, do not confirm the vulnerability exists, and do not agree to any terms at this stage. You are buying time to assess, not entering a negotiation.

3. Assess the technical substance. Get the actual claim in front of someone who can evaluate it. Is the vulnerability specific and reproducible, or is it generic scanner output? Does it actually apply to your environment, or is it a theoretical finding already mitigated? This assessment is what tells you which of the three categories you are in. A real, reproducible, impactful issue is a legitimate disclosure regardless of how the email was phrased. Generic, non-applicable findings point to a beg bounty.

4. If it is a real vulnerability, fix it and respond constructively. This is the whole point. If a researcher found a genuine issue, prioritize the fix, keep them reasonably informed, and treat them as someone who did you a favor. Many of the best long-term security relationships start with an unsolicited disclosure that the company handled with professionalism. Even without a formal program, acknowledging good work and fixing the issue is the right response.

5. Route it through a formal channel if you have one. If you run a bug bounty program through a platform like HackerOne or Bugcrowd, direct the reporter there, because that is where submissions, triage, and any rewards are handled consistently. A clear, published security contact or disclosure policy turns a chaotic inbox situation into a structured process. This is one of the strongest preventive measures you can put in place.

6. If it reads like extortion, involve the right people immediately. The moment an email crosses into threats and payment demands as a precondition, treat it as a potential security and legal incident, not a routine disclosure. Loop in legal counsel and senior leadership. Document everything. Do not improvise a response on your own.

What Not to Do

The mistakes here are as important as the right moves, and some carry real consequences.

Do not ignore it outright. Even a beg bounty occasionally contains a kernel of a real issue, and a genuine disclosure ignored is a real risk left unaddressed. Assess before you dismiss. The cost of a quick technical review is low; the cost of ignoring a real warning can be enormous.

Do not pay reflexively to make it go away. Paying a beg bounty for a non-issue encourages more of the same and funds a business model that targets companies that fold under pressure. And paying an extortion demand is far more fraught than it looks, which leads to the most important caution below.

Do not get hostile or threaten legal action against a good-faith researcher. Responding to a legitimate disclosure with aggression is both unfair and counterproductive. It discourages the responsible disclosure that protects you, and it can turn a helpful researcher into a public critic. Good disclosure guidance specifically advises organizations not to threaten researchers acting in good faith.

Do not handle a suspected extortion case as if it were a normal reward. This is where the stakes are highest. The case of former Uber security chief Joe Sullivan is the cautionary tale the whole industry references: he was prosecuted in connection with handling a payment to hackers in a way that was treated as covering up a breach rather than a legitimate bug bounty. The lesson is that disguising an extortion payment as a routine bounty can have serious legal consequences. If a situation involves a real breach, exfiltrated data, or a payment under threat, that is a legal and regulatory matter requiring counsel, not something to quietly resolve as a “reward.”

Do not paste sensitive internal details into casual replies or tickets. Keep the specifics of any real vulnerability in appropriate, secure channels. Spreading the technical details of an unpatched issue around increases your exposure.

Get Ahead of It: The Preventive Move

The best way to handle these emails is to make the handling routine before they arrive. A published security contact and a clear vulnerability disclosure policy do two things at once.

First, they give genuine researchers a defined, secure way to report issues, which improves the quality of what reaches you and reduces the chance that a real warning gets lost in a general inbox. Second, a well-publicized disclosure policy with clear scope and terms reduces the power of beg-bounty and extortion attempts, because it sets expectations about what you reward and how, and signals that you handle these situations professionally rather than in a panic.

A simple disclosure policy page does not require running a paid bounty program. It just needs to state how to report a vulnerability securely, what is in and out of scope, that you will respond in a reasonable timeframe, and that you will not pursue good-faith researchers. That single page converts an unpredictable threat into a managed process.

The underlying principle is the same one that governs good security generally: you handle incidents far better when you have decided in advance how you will handle them. The bug bounty email is going to arrive. Decide now how you will triage it, who gets involved when it turns serious, and where legitimate researchers should send their work, and the next one becomes a process to follow rather than a fire to fight.

This article covers handling unsolicited security reports. If a message involves an active breach, data theft, or a payment demand under threat, treat it as a legal and security incident and involve qualified counsel rather than relying on general guidance.