Coordinated Vulnerability Disclosure#

Overview#

In security research, vulnerabilities may be discovered in software, hardware, or even the design of some protocol or system. As researchers, we have the responsibility to act in a way to avoid harm affecting users. This is why in most cases when we find a vulnerability, we perform a Coordinated Vulnerability Disclosure (CVD) and help vendors to improve their systems.

If a publication reports vulnerabilities without following a CVD process, this can raise ethical concerns during review. In such cases, authors are typically expected to explain what steps were taken, or why coordinated disclosure was not possible.

Typical Steps#

1. Preparation: Before contacting any party, the vulnerability should be carefully validated. This includes confirming that the issue is real, documenting how it can be reproduced, and assessing its scope and impact. Researchers should also check whether the vulnerability is already known and identify the relevant vendors or stakeholders.

At this stage, it is important to identify appropriate contact channels (e.g., security contacts or disclosure programs) and prepare a clear technical summary. A reasonable disclosure timeline should be considered early on. In practice (¹ and ²), timelines often range from 30 to 90 days, depending on severity and complexity.

2. Notification: The responsible parties should be informed without unnecessary delay. The initial report should include enough technical detail for the vendor to understand and reproduce the issue, such as affected systems, versions, and a description of the impact. More information about notifications can be found in academic publications (³ and ⁴).

Communication should be clear and professional. Researchers typically propose a disclosure timeline and make their intentions transparent. This helps align expectations and reduces the risk of misunderstandings.

3. Response and Coordination: After notification, vendors may ask for clarification or additional information. Researchers are expected to respond in a timely and constructive manner, helping to verify fixes or test patches if needed.

This phase sometimes involves ongoing communication. Keeping records of communication and decisions can also be useful for later documentation.

4. Responsible Publication: Public disclosure usually takes place once a fix is available or the agreed timeline has passed. When publishing, researchers should balance transparency with the risk of misuse and public blaming. This may involve limiting certain technical details or carefully considering whether to release proof-of-concept code.

Example Template:

Subject: Security Vulnerability Report - [Product/System]

Dear [Vendor Contact],

my name is [Name], and I am a researcher at [Institute]. As part of our recent work on [Topic], we identified a potential security vulnerability affecting [Product/System] version [X.Y.Z].

Based on our analysis, this issue may allow [clear impact e.g., unauthorized access to X / leakage of Y / execution of Z].

To assist your team in reproducing and assessing the issue, we have included detailed steps below:

[Vulnerability Description / Reproduction Steps]

We are sharing this finding with you under a 90-day responsible disclosure period, aligned with common industry practices. After this period, we may include a description of the issue in a scientific publication.

Please let us know if you need any additional information.

Thank you for your attention to this matter.

Best regards,
[Your Name]
[Affiliation]
[Contact Information]

Challenges#

While in many cases a CVD is straight forward, there are cases that are challenging and require careful judgment and trade-offs. In such cases, we encourage you to discuss decisions with peers or within your research group. Additional perspectives on these dilemmas can be found in a publication about Computer Security Trolley Problems.

No response in critical cases#

A common challenge arises when a vendor does not respond to a vulnerability report. In such situations, researchers need to decide whether and when to proceed with public disclosure.

This decision should take into account the severity of the vulnerability, the likelihood of active exploitation, and the potential impact on users. Publishing may help raise awareness and prompt action, but it can also increase the risk of misuse if no fix is available.

There is no universally correct answer. What matters is that the decision is well thought through, balancing the interests of affected stakeholders, and that the reasoning can be clearly explained, for example, during review or to a REC.

The Dual-Use Dilemma#

Vulnerability research is inherently dual-use: the same knowledge that helps defenders can also be used by attackers. This creates a fundamental tension in disclosure decisions.

Making vulnerabilities public can support transparency, improve defenses, and enable independent verification. At the same time, it may lower the barrier for exploitation, especially if mitigations are incomplete or not widely deployed.

Researchers therefore need to consider how much information to disclose and when. This includes decisions about technical detail, proof-of-concept code, and timing. These choices should reflect a balance between advancing knowledge and minimizing harm, while acknowledging that different stakeholders (e.g., users, vendors, and the research community) may be affected differently.

An interesting example for a dial-use consideration is made in a recent publication about the Great Firewall of China⁵.

References#