The concept of responsible disclosure is a simple one. If you find a vulnerability, you let the affected organization or software vendor know before making the information public. This gives them time to patch the vulnerability before it can be exploited. It also helps maintain trust and fosters a collaborative environment between security researchers and companies.

As a cybersecurity vendor, do we want our researchers to be credited when they discover vulnerabilities? Of course. But this should never be prioritized over protecting businesses and users from cyber-attacks. Otherwise a Wild West free-for-all can be created, where attackers rush in to exploit the vulnerability before it can be fixed in a patch.

Unfortunately, this is exactly what happened over the past weeks, when we discovered a serious vulnerability (CVE-2025-31161) related to CrushFTP.

The CVE-2025-31161 disclosure dispute   

Back on March 13^th of this year, our researchers contacted MITRE to request a CVE number regarding the vulnerability. We also got in touch with CrushFTP and agreed to give them 90 days to make sure users were able to safely patch. During this process, another vendor (VulnCheck), rushed to report the vulnerability under their own CVE (since replaced by ours). VulnCheck didn’t contact CrushFTP until March 26^th, so were unaware the issue was already being dealt with.

This led to a public war of words between VulnCheck and CrushfTP. A recent statement from a CrushFTP spokesperson said: “The vulnerability was responsibly disclosed by Outpost24. Someone else looking for some fame, it seems, managed to reverse engineer our changes that we had bundled up and published a public disclosure detailing the exploit method and taking credit for the vulnerability.”

And while all this was happening, users were being exploited by hackers who taken the chance to exploit the vulnerability. Attacks are still ongoing. All in all, this created a needlessly chaotic situation that could perhaps have been avoided with a proper disclosure process. If you’re interested in full details of how the CrushFTP vulnerability works as well as a detailed timeline of events, check out our original response to the incident here.

Why Mitre replaced VulnCheck’s CVE with Outpost24’s CVE

Mitre have since made their position clear in a response to Dark Reading: “CVE is a voluntary program governed by a set of program rules. These rules are designed, in part, to support coordinated vulnerability disclosure. In this case, the researcher who initially discovered the vulnerability was already coordinating with the vendor and the MITRE CNA of Last Resort (CNA-LR) to assign a CVE ID and publish a CVE Record, when VulnCheck assigned a CVE ID and published a CVE Record without coordinating with the above parties.”

What’s going on with MITRE’s vulnerability program?

While no definitive outcome has been announced, the Common Vulnerabilities and Exposures (CVE) program, operated by MITRE since 1999, is set to lose its U.S. government funding on Wednesday, April 16, 2025. This program is a cornerstone of global cybersecurity, providing standardized identifiers for publicly disclosed vulnerabilities, and is widely used by major tech companies and government agencies. Some believe this could disrupt coordination among vendors and analysts, potentially weakening global cybersecurity defenses.

From our perspective, the Outpost24 vulnerability database is enriched by data from MITRE, NVD, and hundreds of additional sources. A disruption in CVE operations would require adjustments in our data collection flow, but would not halt our ability to detect or report vulnerabilities. Our products use internally assigned vulnerability identifiers, allowing us to track, detect, and report on vulnerabilities independently of the CVE system. You can read our full company statement here.

Our position on responsible disclosure

Everyone has their own code of ethics. But as an organization, we believe it’s important to work with companies that prioritize the security and well-being of their users. By choosing to work with companies that have a strong commitment to responsible disclosure, you can help ensure that your data and systems are better protected, and you can maintain a higher level of trust and security.

While there’s no universal legal obligation for organizations to follow responsible disclosure practices, there are several factors that ought to make it a de facto requirement:

• Legal and regulatory requirements: In some industries and jurisdictions, there are specific laws and regulations that require organizations to handle and disclose vulnerabilities in a responsible manner. For example, the General Data Protection Regulation (GDPR) in the European Union mandates that organizations report data breaches within 72 hours, which often involves disclosing vulnerabilities.
• Industry standards: Many established best practices and standards encourage or require responsible disclosure e.g. National Institute of Standards and Technology (NIST) in the United States provides guidelines for vulnerability management.
• Ethical responsibility: Many organizations recognize the ethical responsibility to protect their users and the broader community from potential harm caused by unpatched vulnerabilities. While not always legally mandated, responsible disclosure is widely recognized as a best practice and is crucial for maintaining security, trust, and compliance.

The risks around irresponsible disclosure

Security researchers (like all individuals) come with a varied range of ethics and moral code, from those working for the best of the community to others who are heavily conflicted. Irresponsible disclosure gives hackers and malicious actors the opportunity to quickly exploit vulnerabilities, putting users at risk before a fix is available. This can lead to panic and disruption for the affected organization, damaging the company’s reputation and eroding user trust.

These are some of the signs that irresponsible disclosure of a cybersecurity vulnerability might have taken place:

• Public announcement before a fix: The vulnerability is announced publicly before the affected company has had a chance to release a fix or patch.
• Lack of coordination: There is no evidence of coordination with the affected organization to ensure a timely and effective resolution.
• Detailed exploitation information: The disclosure includes detailed instructions on how to exploit the vulnerability, which can be used by malicious actors.
• No warning or notification: The affected organization was not given any warning or notification before the vulnerability was made public.
• Immediate exploitation: There is a rapid increase in attacks or exploitation attempts following the disclosure, indicating that the information was used maliciously.
• Media hype: The disclosure is accompanied by sensational media coverage, often without providing context or solutions.
• Lack of process around reporting: The person or group disclosing the vulnerability does not follow established responsible disclosure guidelines or best practices.

The Meltdown and Spectre disclosure leaks in 2018 emphasized the importance of including the researchers who discovered the vulnerabilities in the ongoing response. This would have improved communication and collaboration among stakeholders, and helped manage the number of informed parties to minimize leaks. Early communication was limited, leading to delays, but a face-to-face meeting significantly enhanced collaboration. Lessons learned from this incident helped improve industry communication and collaboration for handling new vulnerabilities.

How can organizations help facilitate responsible disclosure?

If a security researcher finds a serious flaw within your IT infrastructure, it’s in your best interests that they’re able to speak to you quickly and easily. We believe a responsible organization’s policy for handling security vulnerabilities typically includes the following key elements:

1. Clear reporting channels: Organization should have a clear and accessible methods for security researchers to report vulnerabilities, such as a dedicated email address or a bug bounty program.
2. Acknowledgment and communication: The organization acknowledges receipt of the report and maintains open communication with the reporter, providing updates on the status of the issue.
3. Confidentiality: The organization ensures that the details of the vulnerability are kept confidential until a fix is implemented and released.
4. Timely response: The organization commits to responding to reports in a timely manner, often within a specified timeframe.
5. Coordination and collaboration: The organization works collaboratively with the reporter to understand the issue and develop a fix, sometimes involving the reporter in the testing process.
6. Transparency: Once the vulnerability is fixed, the organization may provide a public disclosure, detailing the issue, the fix, and the timeline, to maintain transparency and build trust.
7. Legal protections: The organization ensures that security researchers are not penalized for reporting vulnerabilities in good faith, often including legal protections in their policy.

If you were to have a vulnerability discovered, following this kind of process means you can effectively manage security issues, protect your users, and foster a positive relationship with the security community. Interested in working with our team of expert vulnerability researchers? Reach out here.