Someone says they found a ‘critical’ cyber issue? It could be a beg bounty

Unsolicited claims of “critical” security issues may be designed to pressure your business into paying. Learn how to identify beg bounty tactics and respond with confidence.

At some point, many businesses will receive an unexpected email from someone claiming they have found a critical vulnerability in a website, application, or internal system. This is often followed by persistent follow-up emails and a demand for payment. This technique is known as a beg bounty. These messages are designed to create uncertainty and pressure so a business pays before confirming whether there is a real issue. Here’s what to look out for and how your business should respond.

What is a beg bounty?

Beg bounty emails are unsolicited messages from someone claiming to have found a security vulnerability and requesting payment for the information.

These messages often include a generic report, exaggerated severity rating, and limited technical detail. The sender may ask for payment before providing enough information to verify whether the issue is real.

Beg bounties have been around since at least 2020, when the technique was first observed at scale. They have become common because the barrier to entry is low. Someone can use free or cheap scanning tools, collect results quickly, and send a templated email demanding payment.

How do they work?

Step 1. An unsolicited email is sent to your business.

The sender claims they have found a serious security issue in your website, application, email domain, or online system.

They usually have no prior relationship with your business and no approved reason to be testing your systems.

Step 2. The sender uses automated scanning tools.

The sender may use free or low-cost tools such as Nuclei, SSL Labs, Shodan, or similar services.

These tools can identify internet-facing settings or configuration details in minutes. The results are then packaged into a report and presented as a serious vulnerability.

Step 3. Routine findings are presented as critical risks.

The issues raised are often not vulnerabilities in any meaningful sense.

Common examples include:

  • missing DMARC or SPF records 
  • absent HTTP security headers 
  • SSL certificate configurations allowing weak cipher suites 
  • subdomain enumeration results presented as CRITICAL risks 

These findings may still be worth reviewing, but the severity is often exaggerated.

Step 4. Payment is requested before meaningful detail is provided.

The sender may request payment or confirmation that your business intends to pay before they disclose the technical details.

The goal is to create enough uncertainty that the business pays before verifying whether there is an actual problem.

Step 5. Follow-up messages increase the pressure.

If your business does not respond, the sender may send repeated follow-ups.

Some messages may escalate in urgency or tone. Others may refer to regulators such as APRA or the OAIC to create pressure, especially in regulated sectors such as financial services, healthcare, and legal services.

Who is targeted?

Businesses without a published vulnerability disclosure policy are common targets.

Without a policy, employee may have no clear basis for declining a submission and no established escalation path. This creates uncertainty that beg bounty operators can exploit.

Small and medium-sized businesses are often targeted because they may be less likely to have dedicated security employees who can assess whether a claim has merit.

How to identify a beg bounty

The following signs, especially when seen together, may indicate a beg bounty rather than a legitimate vulnerability report.

Unsolicited contact with no prior relationship

The sender has no existing engagement with your business and gives no credible explanation for why they were testing your systems.

No clear connection to your business or region

The sender may be based overseas, have no relationship with your organisation, no Australian regulatory grounding, no ABN, and no plausible professional basis for testing your systems.

Overinflated severity claims

The message claims there is a CRITICAL vulnerability, or several CRITICAL vulnerabilities, without demonstrating an attack path or realistic business impact.

Payment demand before detail is provided

The sender asks for payment or confirmation of payment before sharing the technical information needed to verify the claim.

Persistent follow-up

The sender sends repeated emails that increase in urgency or tone, even when your business has not responded.

Promise of further findings on payment

The sender says they will disclose additional vulnerabilities once they are paid.

Poorly written or generic report

The report reads like a template, uses poor English or obvious AI-generated wording, or lacks detail specific to your business environment.

How to respond

Don’t pay unverified submissions 

We recommend against paying unverified beg bounty submissions. Documented cases show that initial payments may be followed by escalating demands. In one reported case, the demand increased from $500 to $5,000 with increasingly aggressive language. Paying once may also mark your business as receptive to further approaches.

Don’t engage if there is no verifiable detail

If a submission provides no verifiable technical detail and demands payment upfront, do not respond.

Publish a vulnerability disclosure policy

A clear vulnerability disclosure policy on your website can help reduce uncertainty and unwanted submissions. The policy should explain how security issues can be reported, what information is required, and whether your business pays bounties. If your business does not pay bounties, say so clearly.

Educate non-technical employees

Legal, finance, executive support, and other non-technical employees are often the first point of contact. They should know not to make any payment or commitment without review by the appropriate technical or security contact.

Verify independently

If a submission references a specific issue, have technical employees assess whether it exists before the conversation continues. Do not rely only on the sender’s severity rating or description.

Remediate verified findings

If a submission is technically verified, focus on fixing the issue. There is no legal obligation to pay an unsolicited researcher. There is also no obligation to tell them once the issue has been remediated.

Get a second opinion

If your business has limited internal capability to assess a submission, or the finding is unclear, seek advice from a trusted external security provider before responding.

Reduce your exposure

Most beg bounty campaigns rely on automated scans finding low-hanging fruit. Keeping systems patched, hardening internet-facing services, and reviewing your external attack surface can reduce what these tools find and make your business less attractive to beg bounty operators.

When it becomes threatening

If a message includes threats of public disclosure, regulatory reporting, or reputational damage unless payment is made, preserve all correspondence. This may cross into extortion under Australian law. Keep copies of emails, attachments, payment requests, timestamps, sender details, and any follow-up messages. Businesses that receive threatening messages should consider reporting them to the Australian Federal Police or the Australian Signals Directorate through ReportCyber.

Stay calm and verify first

Beg bounty emails are designed to create pressure. Do not pay upfront. Do not rely on the sender’s severity rating. Do not let urgency drive the response. Escalate the message internally, verify any specific technical claim, and focus on remediation if a genuine issue is found. A real security issue should be fixed, but an unsolicited payment demand should not decide how your business responds.

Signals: Cyber security articles for business

Easy-to-digest information and explainers to help you protect your business.

Things you should know

This information is intended to provide general information of an educational nature only. It does not have regard to the financial situation or needs of any reader and must not be relied upon as financial product advice. As this information has been prepared without considering your objectives, financial situation or needs. You should, before acting on this, consider the appropriateness to your circumstances.