100 CVEs published: Behind responsible vulnerability disclosure

100 vulnerabilities identified. 100 responsible disclosures. Countless organisations made more secure.

The Missing Link has published its 100th CVE.

It's a milestone worth marking because every published CVE represents far more than a vulnerability. Each one is the product of meticulous research, careful validation and close collaboration with software vendors. Together, one hundred published CVEs represent countless hours of investigation and coordinated disclosure. It's work that often happens quietly behind the scenes, but it has helped strengthen the security of software used by organisations around the world.

Fittingly, the 100th is a clean example of the whole process working exactly as intended. CVE-2026-15928 was discovered by Security Consultant Andrew Bick: a reflected cross-site scripting (XSS) vulnerability in the XMLRPC-C Library's error page component, which could allow an attacker to hijack a user's session under specific conditions. The vulnerability was identified, disclosed responsibly, remediated by the vendor, and ultimately published through the CVE Program.

The CVEs The Missing Link has permission to publish are available through our Security Advisories page, providing a publicly verifiable record of the team's contribution to vulnerability research and responsible disclosure. As an authorised CVE Numbering Authority since 2022, The Missing Link is one of the few organisations in Australia trusted to identify, validate and publish vulnerabilities within our scope, coordinating disclosure directly rather than through a third party.

What does publishing a CVE involve?

The published CVE is the only part of the process most people ever see. In reality, publication is the final stage of a coordinated effort between security researchers and software vendors that can take weeks or months to complete. Every disclosure required researchers to investigate, validate, document, and reproduce the issue before working alongside software vendors until the vulnerability could be safely resolved.

A common misconception is that vulnerability research ends once a security issue has been identified. Discovery is often the shortest part of the process, and much of the work begins after the vulnerability has been confirmed. A typical

disclosure follows several stages:  

• • Research – Testing software, applications, or devices to identify potential security weaknesses.

  • Validation – Confirming the issue is genuine, reproducible, and not the result of a false positive or environmental configuration.

  • Documentation – Recording the technical details and reproduction steps required for the vendor to independently verify the vulnerability.

  • Responsible disclosure – Privately notifying the software vendor and providing sufficient information to investigate the issue.

  • Vendor collaboration – Working with the vendor as they assess the impact, reproduce the issue, and develop a remediation strategy.

  • Remediation – The vendor develops and releases a security update or patch.

  • Publication – Once the vulnerability has been addressed, or an agreed disclosure timeframe has elapsed, the CVE record is published.

The timeline varies depending on the complexity of the software, the number of affected products, release schedules, and the potential impact on users.

Publishing technical details before organisations have had an opportunity to protect themselves can create unnecessary exposure, so the timing of publication is carefully considered throughout the process.

Why don't all vulnerabilities become CVEs?

Not every vulnerability qualifies for a CVE, and not every qualifying vulnerability is published immediately. There are a few reasons why.

Some issues fall outside the scope of the CVE Program. Configuration errors, deployment issues, or environment-specific weaknesses may present genuine security risks without representing a software vulnerability that meets the criteria for CVE assignment.

In other cases, disclosure may be intentionally delayed. If a vendor needs additional time to develop and distribute a patch, publishing technical details prematurely could increase the likelihood of exploitation before organisations have had the opportunity to update their systems.

There are also situations where the level of technical detail published is deliberately limited. Publicly documenting exploitation techniques before remediation has been widely adopted can unintentionally provide attackers with valuable information.

The objective isn't to publish vulnerabilities as quickly as possible but to reduce risk by ensuring software vendors and users can remediate vulnerabilities before technical details become public.

Why 100 published CVEs matters

Publishing one hundred CVEs represents sustained contribution to the security community. It reflects hundreds of hours of research across a broad range of technologies, products and software vendors, from open-source libraries to enterprise platforms like Microsoft Power BI. Every published CVE represents research that stood up to technical validation and vendor scrutiny before being responsibly disclosed, remediated and published.

Every case is different. Investigating one issue can uncover additional vulnerabilities that also require remediation before the disclosure process is complete.

Responsible disclosure depends on collaboration. Researchers identify and validate vulnerabilities, vendors investigate and remediate them, and organisations use published CVEs to understand their exposure and prioritise remediation. Publishing 100 CVEs has only been possible because of the trust built with software vendors throughout that process.

The publication of a CVE represents the successful completion of a responsible disclosure process, not simply the discovery of a vulnerability.

As Jack Misiura, Application Security Manager at The Missing Link, reflects:

"Reaching one hundred published CVEs is something we're incredibly proud of because every one represents research that helped protect organisations from real-world vulnerabilities. Some vulnerabilities took an afternoon to validate. Others took months of collaboration with engineering teams before everyone was confident the issue had been fully resolved. That's what responsible disclosure looks like. That's why this milestone matters to us."

The next 100

We're proud of this milestone: 100 vulnerabilities identified, disclosed, and remediated through years of dedicated research and collaboration. But it's far from the finish line.

Software keeps changing, attackers keep adapting, and new vulnerabilities continue to emerge. We'll keep working with software vendors to identify, validate, and responsibly disclose vulnerabilities while applying what we learn across penetration testing, secure code reviews, and application security testing. That's the same real-world experience our Application Security team brings to every customer engagement.

Reaching 100 published CVEs is an important milestone, but our commitment to responsible vulnerability disclosure continues.

The full list of CVEs we've published is available on The Missing Link's Security Advisories page.