Bug Bounties

Coordinated Vulnerability Disclosure: A Complete Guide for Researchers

You found a vulnerability in a product that has no bug bounty program. Now what? If the vendor has a program on HackerOne or Bugcrowd, the path is clear. But most software in the world has no formal intake process for security issues. Coordinated vulnerability disclosure (CVD) is how you handle those cases responsibly, and it is a skill worth learning even if you mostly work through platforms.

What coordinated disclosure actually means

CVD is an agreement between you and a vendor: you report the issue privately, they fix it within a reasonable timeframe, and then you both go public. The “coordinated” part means neither side acts unilaterally. You do not drop a zero-day on Twitter, and the vendor does not silently patch and pretend nothing happened.

This sounds simple. In practice, it breaks down constantly. Vendors ignore emails. Legal teams send threatening letters. Patches take eighteen months. The coordination part requires real effort from both sides, and you will sometimes be the only one putting in that effort.

The 90-day disclosure deadline

Google’s Project Zero popularized the 90-day standard in 2014. The idea: vendors get 90 calendar days from initial notification to ship a fix. After that, the researcher publishes regardless.

This is not a law. It is a norm, and a useful one. Before Project Zero enforced deadlines publicly and consistently, some vendors sat on reported vulnerabilities for years. The deadline creates accountability.

I recommend 90 days as your default, but adjust based on context:

Whatever deadline you choose, communicate it in your first message. Do not surprise a vendor with publication after a deadline they did not know about.

Finding the right contact

Before you write your disclosure email, figure out where to send it. Check these in order:

  1. security.txt - visit /.well-known/security.txt on the vendor’s domain. This is the standard place to publish security contact info. See our security.txt guide for details on reading these files.
  2. Security page - look for a /security or /responsible-disclosure page on their site.
  3. security@ email - try security@[domain]. RFC 2142 designates this as the conventional mailbox for security issues.
  4. Bug bounty platform profiles - some vendors have disclosure-only programs (no bounties) on HackerOne or Bugcrowd.
  5. CERT/CC - if none of the above works, CERT/CC can act as a neutral intermediary. More on this below.

Do not report vulnerabilities through customer support tickets, public issue trackers, or social media DMs. Support agents are not equipped to handle security issues, and public trackers expose the vulnerability.

First contact email template

Your initial disclosure email needs to establish credibility, describe the issue clearly, and set expectations. Here is a template I have used successfully:

Subject: Security vulnerability in [Product Name] - [Brief description]

Hello,

I am a security researcher and I have identified a vulnerability
in [Product Name] that I would like to report through coordinated
disclosure.

Summary: [One sentence describing the vulnerability class and
affected component]

Severity: [Your CVSS assessment or a plain-language severity rating]

I have prepared a detailed writeup with reproduction steps and
proof of concept. I am happy to share this over an encrypted
channel if you can provide a PGP key, or I can send it in
plaintext to this address.

I follow a 90-day coordinated disclosure policy. I intend to
publish my findings on or after [date 90 days from now], which
gives your team time to develop and deploy a fix. I am happy
to adjust this timeline if circumstances require it.

Please confirm receipt of this email and let me know who will
be coordinating the fix on your end.

Best regards,
[Your name]
[Your website or security profile URL]

Keep the first email short. Do not dump the full technical writeup into an unsolicited cold email. Wait for confirmation that you are talking to the right person, then share the details.

Follow-up cadence

Not every vendor responds promptly. Here is the schedule I follow:

Document every attempt. Save emails, screenshots of sent messages, and timestamps. This record matters if the vendor later claims they were never notified.

Follow-up email template

Subject: Re: Security vulnerability in [Product Name] - Follow-up

Hello,

I sent a vulnerability disclosure to this address on [date] and
have not received a response. I want to make sure this reached
the right team.

The issue affects [brief description]. My disclosure timeline
gives your team until [deadline date] to address it.

Could you confirm receipt and provide a point of contact for
coordinating the fix?

Thank you,
[Your name]

Working with CERT/CC

The CERT Coordination Center at Carnegie Mellon has been coordinating vulnerability disclosures since the 1980s. When a vendor is unresponsive, CERT/CC is your strongest escalation path.

To submit a vulnerability to CERT/CC:

  1. Go to their Vulnerability Reporting Form
  2. Provide the technical details, your timeline, and documentation of your contact attempts
  3. CERT/CC will attempt to contact the vendor through their own channels
  4. They publish a Vulnerability Note (VU#) if coordination succeeds, or after their own 45-day deadline

CERT/CC carries institutional weight. A vendor who ignores an email from an unknown researcher will often respond to CERT/CC within days. I have seen this happen multiple times.

CISA also runs a coordinated disclosure process for vulnerabilities in critical infrastructure and government systems. If your finding affects government software or ICS/SCADA systems, go through CISA directly.

The CVE process

Getting a CVE identifier assigned to your finding is useful for several reasons: it creates a permanent public record, it helps defenders track the issue, and it adds credibility to your disclosure. See our full CVE guide for a deeper treatment.

The short version:

  1. Identify the correct CNA (CVE Numbering Authority) for the product. Many major vendors are their own CNA. The CNA rules and list are on the CVE website.
  2. If the vendor is a CNA, they should assign the CVE as part of the fix process. Ask them to do so explicitly.
  3. If the vendor is not a CNA, or is unresponsive, submit a request to MITRE’s CVE form or to a root CNA like CERT/CC.
  4. Provide the vulnerability type (CWE if you know it), affected versions, and your advisory text.

A common frustration: you report a vulnerability, the vendor patches it, and no CVE ever gets assigned. If this happens, request one yourself through MITRE. You do not need the vendor’s permission to request a CVE.

When the deadline passes

Your 90 days are up and the vendor has not shipped a fix. What do you do?

This is where disclosure gets uncomfortable. I think enforcing deadlines is the right thing to do, because the alternative is letting vendors ignore security issues indefinitely. But publication of an unpatched vulnerability causes real harm to users. Here is how I handle it:

  1. Send a final warning at day 80 - give the vendor a last chance to request a short extension (14 days maximum) with evidence of progress.
  2. If the vendor has been communicative and is close to a fix - a short extension is reasonable. Do not extend indefinitely. Two weeks, once.
  3. If the vendor has been silent - publish on schedule. You gave them fair notice.
  4. Limit the detail in your initial publication - describe the vulnerability class and impact, but consider withholding a working exploit for 30 additional days. This is what Project Zero calls a “grace period.”

Final notice template

Subject: Re: Security vulnerability in [Product Name] - Disclosure
deadline approaching

Hello,

My 90-day disclosure deadline for the vulnerability I reported
on [date] is [deadline date], which is 10 days from now.

I have not received confirmation that a fix has been deployed.
If your team needs a short extension (up to 14 days), please
respond with a timeline and I will consider it.

If I do not hear from you by [deadline date], I will publish
my findings as described in my initial report.

Regards,
[Your name]

Publishing your writeup

Once disclosure is complete, whether the vendor fixed it or not, you will probably want to publish a writeup. Good writeups build your reputation and help the community learn.

Getting vendor permission

Some vendors require pre-approval of writeups through their bug bounty terms. Read the program policy before publishing. If there is no formal program, you do not need permission, but giving the vendor a courtesy heads-up about your publication date is professional.

Self-publishing guidelines

When writing your disclosure post:

For more on structuring technical writeups, see our report writing guide. The same principles apply, just with a public audience instead of a triager.

Disclosure without a bounty program

Most of your coordinated disclosures will be with organizations that have no bounty program. This changes the dynamic in a few ways.

There is no platform to mediate disputes. No guaranteed safe harbor. No payout. You are doing this because it is the right thing to do, and because the writeup builds your portfolio.

Protect yourself:

If a vendor responds with legal threats instead of a thank-you, stop all communication and consult an attorney. The EFF has resources for security researchers facing legal pressure.

Tricky scenarios

The vendor patches silently and does not credit you

This happens a lot. It is annoying but not the end of the world. You can still publish your writeup, reference the commit or changelog where the fix appeared, and note that the vendor did not coordinate or credit the report. The community will draw its own conclusions.

The vendor disputes the severity

Sometimes legitimately, sometimes to avoid paying a bounty or publishing an advisory. If you believe your severity assessment is correct, document your reasoning and publish it alongside the vendor’s response. Let readers decide.

Someone else finds the same issue during your disclosure window

Duplicates happen in coordinated disclosure just like on bounty platforms. If another researcher publishes before your deadline, your disclosure timeline effectively resets to zero, because the issue is now public. Coordinate with the other researcher if possible.

The vendor asks you to sign an NDA

I would decline this in almost all cases. An NDA prevents you from publishing your writeup, which removes the accountability mechanism that makes coordinated disclosure work. If a vendor wants confidentiality, the 90-day window is their confidentiality period.

Putting it together

Coordinated disclosure is unglamorous work. There are no leaderboard points, often no bounties, and sometimes active hostility from the organizations you are trying to help. But it is how the security community protects users when formal channels do not exist.

The process, summarized:

  1. Find the vulnerability and confirm it
  2. Locate the vendor’s security contact
  3. Send a clear initial disclosure with a stated deadline
  4. Follow up persistently but professionally
  5. Escalate through CERT/CC if the vendor is unresponsive
  6. Request a CVE
  7. Enforce your deadline, with a short grace period if warranted
  8. Publish a writeup that documents the full timeline

Start with the learn hub for more guides on every stage of this process, from writing reports to understanding CVSS scoring.