The message usually arrives at the wrong address: support, sales, the personal inbox of the founder. It says that the sender found a vulnerability in your product. Sometimes it includes details, sometimes it asks whether you have a bug bounty program, sometimes it mentions money in the first line.
What you do next decides two things: whether this vulnerability gets fixed quietly, and whether the next researcher writes to you or about you.
Who writes such messages
- Researchers acting in good faith. They found something, often by accident or while testing a whole class of products, and want it fixed. Many hope for a reward or an acknowledgement; few insist.
- Reporters of automated findings. A scanner found a missing header or an outdated library, and the report was sent to hundreds of companies. The finding may be real and is usually minor.
- Extortionists. The message contains a threat: pay, or the data is published. This is a crime and is handled as an incident, not as a report.
From the first message you often cannot tell which one you have. The plan below works for all three until you can.
The first hour
- Do not reply in anger and do not threaten. A threat of legal action turns a private report into a public story.
- Do not pay and do not promise payment. You do not know yet what you would be paying for.
- Do not click links and do not open attachments from the message on a work machine. Pass it to whoever handles security.
- Tell the person responsible for security. If nobody is, that is the first finding.
The first day
Acknowledge receipt. Two sentences are enough: the report has been received, it is being examined, and this is the person to talk to. Silence is what makes researchers go public.
Ask for the details, through a channel you control. A dedicated mailbox, ideally with an encryption key. Ask for the affected address, the steps to reproduce and what the reporter was able to access.
Verify on your side. Reproduce the issue yourself, in a test environment if possible. Look at the logs for the period the reporter names: what was accessed, from where, how often. The logs tell you whether the reporter stopped at the proof.
The first week
Assess the severity. What can an attacker do with it, and how hard is it? A CVSS score gives a common language for the answer.
Decide whether it is an incident. If the vulnerability gave access to personal data and you cannot rule out that it was used, the notification duties of data protection law may apply, with short deadlines. This is a question for your lawyers on the first day, not the last.
Fix, then tell the reporter. Say what was fixed and when. If you disagree with the report, say so and explain why.
Thank them. A public acknowledgement, with the consent of the reporter, costs nothing. A reward is your decision; if you pay one, pay it for the finding and not under pressure, and say that it is voluntary.
When money is mentioned first
A researcher who asks whether you have a bounty program is asking a normal question. The answer can be “no, but we are grateful for the report”.
A sender who refuses to give any detail before payment, sets a deadline or threatens publication of data is not reporting a vulnerability. Preserve the messages, do not negotiate alone, involve your lawyers and consider involving law enforcement.
So that the next report arrives properly
The report went to the wrong inbox because there was no right one. Three things fix that:
- A disclosure policy on your website: what may be tested, how to report, what the reporter can expect, and your commitment not to pursue people who follow the rules.
- A security.txt file at
/.well-known/security.txt, the place where researchers look first. RFC 9116 requires two fields,ContactandExpires; after the date inExpiresthe file is considered stale. - A process behind the mailbox: who reads it, who verifies, who decides, within what time.
This is what a vulnerability disclosure program consists of. If a report is waiting for an answer right now, send us a request and say so: such requests are answered first.