Skip to content

Somebody Stops Replying

Sometimes one of the parties involved in a CVD effort will stop responding. Often, this is simply a reflection of priorities and attention shifting elsewhere rather than intentional behavior. It's usually best to give the benefit of the doubt and keep trying to reestablish contact if one of the CVD participants goes unresponsive. Even in cases where the vendor has stopped responding in the midst of a coordination effort, the CERT/CC recommends that reporters send the vendor a "heads up" message with some lead time before publishing, optionally including a draft of the document about to be published. This helps the vendor prepare its communication plan if necessary, and sometimes helps to identify any lingering misunderstandings on the technical aspects of the vulnerability.

Example: A 2015 Minecraft Vulnerability

Ammar Askar's blog post about a Minecraft vulnerability serves as an example where a quick heads up to the vendor could have avoided some confusion.

Update 2: The exact problem that caused this bug to go unpatched has been identified. Mojang attempted to implement a fix for this problem, however they did not test their fix against the proof of concept I provided, which still crashed the server perfectly fine. This, in combination with ignoring me when I asked for status updates twice led me to believe that Mojang had attempted no fix. In retrospect, a final warning before this full disclosure more recently was propbably in order. A combination of mis-communication and lack of testing led to this situation today, hopefully it can be a good learning experience.

Vendor stops responding

Role(s) affected: Reporter

Phase(s): Reporting, Validation and prioritization, Remediation, Public Awareness

Description:

  1. The reporter and vendor had already been in contact about the vulnerability.
  2. The reporter has repeatedly attempted to communicate with the vendor.
  3. The vendor has been non-responsive for at least two weeks
  4. Either of the following events has occurred:
    1. An already-agreed embargo date has passed, or
    2. No embargo date was set and at least six weeks have elapsed since the vendor's last response.
  • At this point, the CERT/CC would consider the vendor to be non-responsive.
  • Assuming the reporter chooses to continue pursuing the issue at all, their options include:
    • The reporter may publish the report on their own.
      • If so, the reporter should provide a courtesy copy of the report to the vendor with a few days' lead time to give the vendor one last chance to prepare for entering the Public Awareness phase.
    • The reporter may attempt to engage a coordinator
  • See Somebody Stops Replying

Reporter stops responding

Role(s) affected: Vendor

Phase(s): Reporting, Validation and prioritization, Remediation, Public Awareness

Description:

  1. The reporter and vendor had already been in contact about the vulnerability.
  2. The vendor has repeatedly attempted to communicate with the reporter.
  3. The reporter has not responded to the vendor.
  • The vendor is under no obligation to continue attempting to engage with a reporter who stops responding.
  • The vendor should continue through the Validation and prioritization, Remediation, and Public Awareness phases on their own as necessary.
  • If the report was received in the context of a bug bounty program, the vendor should apply their bug bounty policy as appropriate.
  • See Somebody Stops Replying.

Reporting a Vulnerability to CERT/CC

You can request the CERT/CC's assistance in coordinating a vulnerability disclosure process by submitting a report through the CERT/CC's Vulnerability Reporting Form (VRF).