Spam in the security mailbox: handling beg bounties, scanner reports and bulk mail

Every public reporting address attracts e-mails that are not genuine vulnerability reports: automated "findings" with a request for a reward (beg bounty), unverified scanner reports, machine-generated reports, advertising and ordinary spam. Deleting them is still the wrong answer. The Commission guidance requires the initial assessment of a report to start immediately, and BSI TR-03183-3 requires that no report is closed by a single person. A professional approach therefore has three parts: a policy that states clearly what counts as a vulnerability and that there is no reward; a classification of every e-mail against fixed criteria, with a record; and prepared replies for the recurring cases.

Why does so much junk end up in the security mailbox?

A security.txt file is meant to be found, by people and by programs. The same programs are also used by people who ask for money in many places for little effort. The pattern has been described for years: a tool checks a domain for run-of-the-mill findings, such as a missing DMARC record or a missing HTTP header, and a template turns the result into a "Vulnerability Report" e-mail asking about a reward. The targets are deliberately smaller companies without a reward programme of their own. Some senders become more demanding after a refusal, up to and including threats.

Since 2025 these have been joined by machine-written reports that sound plausible but are wrong. The open-source project curl has documented this publicly: in 2025 only around 5 per cent of submissions were valid, the project lead classed about 20 per cent as machine-generated nonsense, and each report tied up three to four people for 30 minutes to three hours. At the end of January 2026, curl ended its bounty programme to remove the incentive. These figures come from reward programmes. How many such e-mails reach the ordinary mailbox of a mid-sized company has not been publicly measured. Only the direction is clear: with the reporting obligation under Article 14 of Regulation (EU) 2024/2847 and the contact address under Annex I, Part II, point (6), many manufacturers' mailboxes are becoming discoverable by machines for the first time.

What kind of e-mails arrive?

The last row is the reason for this guide. A genuine report does not always look professional. Good researchers often write three sentences, in English, from a free webmail address. An e-mail a customer sends at night because something strange is happening on their equipment has no structure and no technical terms. If you sort by form, these are exactly the reports you sort out.

Why may nothing be silently deleted?

The 24-hour deadline for the early warning notification does not start when an e-mail arrives, but with awareness (Article 14(2)). According to the Commission guidance C(2026) 5252, awareness exists when the initial assessment establishes with a reasonable degree of certainty that a vulnerability in your own product is being actively exploited. Receipt does, however, trigger the duty to start that initial assessment immediately (paragraph 213). An e-mail that sits in the spam folder for three days has not been assessed immediately. Whether the manufacturer can then rely on the later point in time is an open question; the authorities have not yet established any practice. The only certainty is that it will have to explain why the assessment started so late. More on this in When does the 24-hour deadline start?

BSI TR-03183-3 sets two further rules in section 4.4.7. All incoming reports are to be treated to the best extent possible and cannot be closed by a single analyst, so that no valid vulnerability is missed (point (g)). Reports of vulnerabilities that have already been remedied should still be received and checked (point (a)). Automatic deletion contradicts both.

In technical terms, this means: the spam filter on the security mailbox marks messages and sorts them into folders; it does not reject or delete. Every folder is checked daily, though not all with the same care.

What belongs in the policy

The coordinated vulnerability disclosure policy is the most effective tool against beg bounties, because it gives the answer in advance. Three points make the difference.

Whether there is a reward

Recital 76 of the Regulation provides that manufacturers can set up reward programmes, and TR-03183-3 recommends one. It is not mandatory. If you do not offer one, say so explicitly, for example: "We do not run a bug bounty programme and do not pay rewards. On request, we will name reporters on our acknowledgements page." An acknowledgements page (Hall of Fame) is a non-monetary incentive that the TR expressly mentions.

What counts as a vulnerability

Under section 4.4.5 of the TR, the manufacturer has to publish what it regards as a valid vulnerability. The TR recommends only three criteria for this: the vulnerability affects one of the manufacturer's products or its infrastructure, the information is ideally not publicly known, and the report is not merely the result of automated tools without supporting documentation. A long list of additional exclusions therefore does not fit the TR. What does fit is a list of examples that explains the third criterion:

• Missing or non-standard HTTP security headers without evidence that they make an attack possible.
• Comments on SPF, DKIM or DMARC for the mail domain without any specific misuse.
• Clickjacking on pages where no action can be triggered.
• Visible version numbers of servers or software without evidence of a vulnerable version.
• Missing rate limiting on forms without evidence of harm.
• Self-XSS and other flaws that only affect the reporting person.

The key is the wording "without evidence of impact". A missing header can be a real problem in a particular application. The list does not exclude the topic, it excludes the report without evidence.

Who the response times apply to

In section 4.4.8, the TR requires a personal, non-automated response to a vulnerability report within 5 working days and detailed feedback within 10 working days. A beg bounty e-mail is a weak report and receives this response; the standard text is enough. Advertising and phishing are not reports. The policy can make this clear: "These response times apply to vulnerability reports. We do not reply to advertising or bulk e-mail." The sentence "Please use our reporting form where possible" also helps. A form with mandatory fields for product, version and steps to reproduce produces better reports than a free-text e-mail. The e-mail address must remain all the same, because the TR requires it (sections 4.3.1 and 4.4.3).

Classify, do not delete

Every incoming e-mail gets a category, and every category has a reason. For a bulk e-mail this takes half a minute and achieves two things: nobody has to rely on gut feeling, and the manufacturer can later show that it looked at every e-mail.

1. Sign of exploitationThe e-mail claims or shows that a vulnerability is already being exploited ("in the wild", unknown access, log extracts, extortion after an attack), or a customer reports anomalies on a product. Straight to the call chain, whatever the e-mail looks like. This category is never downgraded and is only closed after a documented initial assessment.
2. Vulnerability reportSpecific product or system, a description that can be followed. To the PSIRT or CSIRT, response within 5 working days.
3. Weak report, beg bountyRun-of-the-mill finding without evidence, template text, question about a reward. Reply with the standard text; a second person confirms the closure.
4. Bulk e-mailAdvertising, address trading, phishing, no connection to a vulnerability. Catch-all folder, no reply, a daily glance down the list.

Two rules keep the process safe. First, a message is only downgraded on clear criteria; when in doubt, the higher category stays. Second, lack of polish is not a criterion: a webmail sender, poor English, brevity or a missing subject line say nothing about the content.

How to recognise bulk e-mail

• The finding fits any domain. Headers, mail records, version details. None of it requires anyone to have looked at the product.
• No link to a product. The e-mail names no product and no version, only the website.
• The reward comes before the finding. "Do you offer a bug bounty?" in the first sentence, details only once a payment is promised.
• The same text to several addresses. info@, security@ and the managing director all receive the same e-mail.
• Pressure without substance. Urgency, deadlines or references to "critical" without any description of the impact.

The record does not have to be elaborate: date, sender, subject, category, a one-sentence reason, who classified it and who closed it. A spreadsheet is enough. Over a year it also shows how many genuine reports came in and how quickly they were handled.

How to reply

For the recurring cases, standard texts in English and in your own language are worth having, agreed once and then used unchanged.

• Beg bounty. Thanks for the message, a reference to the policy and to the fact that the finding does not count as a vulnerability without evidence of impact, no bug bounty programme, case closed. Follow-ups without new content receive no further reply once the case is closed. If a follow-up brings new information, it supplements the report and receives a response within 5 working days (TR, section 4.4.8, point (a)).
• Weak report. Thanks, a request for the product, version, steps to reproduce and observed impact, and a note that the report will be closed after 30 days without a reply. This matches the end states provided for in section 4.4.11 of the TR.
• Threat or demand. Anyone who asks for money and threatens publication or an attack gets no negotiation. Secure the evidence, involve senior management, check whether there is a sign of exploitation after all. Whether to report the matter to the police is for senior management to decide, with its lawyers if needed.
• Bulk e-mail and phishing. No reply. A reply only confirms that the address is read.

Attachments to genuine reports, such as a proof-of-concept script, are only opened in an isolated environment. The security mailbox is an obvious target for attacks precisely because someone there expects attachments. The CRA Reporting Kit contains the standard texts and a printable classification aid.

Common mistakes

• Spam filter set to reject. The sender gets an error message and the manufacturer sees nothing. This often affects reports from private addresses or new domains in particular.
• Forwarding to a shared address with no one responsible. security@ ends up in info@, where everyone reads a bit of it and nobody reads all of it.
• Arguing with beg bounty senders. Every further reply costs time and prompts new follow-ups. One reply, then stop.
• Paying "as a goodwill gesture". Pay once and you are on the list of companies that pay.
• Sorting by form. The brief e-mail in English from a webmail address ends up in spam, while the long template e-mail full of technical terms lands with the head of development.
• No record. Without a list, you cannot show later that an e-mail was looked at and closed with a reason.

What this means in practice

For a manufacturer of measuring instruments with 90 employees, this means: add the sentence on rewards and the list of examples to the policy, set the spam filter on the security mailbox to mark rather than reject, name two people for the daily review, approve the standard texts, set up a spreadsheet as the record. That can be done in an afternoon. It gets difficult outside working hours and during holidays, when the e-mail pointing to exploitation is stuck between twenty bulk e-mails. CRA Response Center separates every e-mail to the reporting address into Important and Everything else and gives the reason for its classification in one sentence. The manufacturer sees everything else sorted by tag, such as bug bounty or advertising; e-mails pointing to exploitation always remain important under fixed rules and trigger the alert. The manufacturer writes the replies to reporters itself.

Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kit

Frequently asked questions

Further reading

• Coordinated vulnerability disclosure policyWhere rewards, valid vulnerabilities and response times are set out.
• PSIRT for SMEsWho reads the mailbox, who assesses and who replies, with only a few people.
• When does the 24-hour deadline start?Why the arrival of an e-mail starts the initial assessment, not the deadline.
• security.txt under RFC 9116 and BSI TR-03183-3The file through which the mailbox is found.
• What security.txt can do against spamThe bug bounty field, the policy, a dedicated address and Sieve filter rules that sort rather than delete, on security-txt.eu.
• Spam since publishing security.txtHow CRA Response Center finds the report that matters, and alerts you only for that.

Sources

• Regulation (EU) 2024/2847, Article 13(17), Article 14, Annex I, Part II, recital 76, Publications Office of the EU, 20 November 2024.
• Commission guidance C(2026) 5252, Annex, paragraph 213, European Commission, 27 July 2026.
• BSI TR-03183-3 Vulnerability Reports and Notifications, version 1.0.0, section 4.4, German Federal Office for Information Security (BSI), 20 August 2025.
• Have a domain name? "Beg bounty" hunters may be on their way, Sophos, 2021.
• Death by a thousand slops, Daniel Stenberg (curl), 14 July 2025.
• curl ending bug bounty program after flood of AI slop reports, BleepingComputer, 22 January 2026.