Best of VulnCon 2026

What is VulnCon?

VulnCon is an annual event co-organized by FIRST and the CVE Program. Its first edition took place in March 2024 and was created as a space to bring together the various stakeholders involved in the global vulnerability ecosystem: from CNAs (CVE Numbering Authorities) and PSIRTs (Product Security Incident Response Teams) to vendors, researchers, and consumers of this information.

VulnCon focuses on discussing how vulnerabilities are identified, documented, prioritized, shared, and consumed within the industry. In other words, it does not revolve solely around the technical aspects of finding vulnerabilities, but also around all the processes and standards that make this information useful to the community.

For Fluid Attacks, attending these conferences is very important because we are a CNA — we were accepted on June 2, 2021 (we were the first CNA in Latin America; at the time of writing this post, we are already three). We have more than 160 public CVEs and more than 15 in progress, all of them found or coordinated by us. Of these, 13% are critical-severity, 43% are high-severity, and 44% are medium-severity; we must publish and properly maintain all of them. For this reason, we want to understand what other CNAs are doing, what problems they face, and how we can optimize our processes.

Introduction to VulnCon 2026

VulnCon26 took place from April 13 to 16 at the DoubleTree Resort by Hilton Hotel Paradise Valley in Scottsdale, Arizona, USA. On Monday, April 13, the pre-conference workshops were held, followed by three days of engaging talks on vulnerability management and emerging trends. This year, there were around 130 in-person attendees and 100 remote attendees from different organizations in the vulnerability management field.

Scottsdale, AZ (image taken from afar.com)

The main topics this year focused on how artificial intelligence is affecting the vulnerability ecosystem, both positively and negatively. This included talks on automation, pipelines for the entire responsible disclosure process, how AI has increased both the number of reports and the noise around reports, as well as early ideas about how AI-built software should be identified, using, for example, PURL and treating models and datasets as libraries and configuration files, and how to assign vulnerabilities to AI software. There were also discussions about standards and frameworks such as VEX and CSAF for vulnerability management. Last but not least, some talks presented research with constructive criticism of the CVE ecosystem to understand what is wrong and how it could be improved.

Before the talks

On the first day of the event, although there were no talks, several open workshops were available for attendees to join. So, after checking in and receiving the event swag—a T-shirt, a notebook, stickers, and a tote bag—I looked over the workshops I wanted to attend. The decision did not take long, since there was a workshop called "Coordinated Vulnerability Disclosure (CVD) Table Top Exercise," which I believed could be very useful for Fluid Attacks.

This workshop turned out to be especially interesting because it presented, in a very practical way, how coordinated vulnerability disclosure unfolds from the perspective of the different stakeholders involved: users, coordinators, disclosers, and vendors. One of the most valuable ideas was understanding that the coordinator's role is not limited to serving as a bridge between the parties. Often, it also involves requesting additional evidence, facilitating communication between the discloser and the vendor, and even supporting the manufacturer in its public response.

During the session, complex scenarios were also discussed, such as cases in which the vendor does not confirm the vulnerability, cases in which there are already signs of exploitation in the wild, or cases in which the question arises of whether a vulnerability can be made public without the vendor's consent. I also found it interesting to see how some CNAs already have internal pipelines and tools to manage the entire vulnerability disclosure flow, from the initial report to publication, and how they use tools like Vulnogram to automate parts of the process, such as generating CPEs. Overall, the workshop left one clear idea: in disclosure, there is no single correct way to do things, but many decisions about coordination, timing, and communication ultimately define the quality of the response.

Some talks

This year, there were six workshops and around 60 talks and working group meetings delivered by 81 speakers of different nationalities. All of these conferences were spread across three days. There were talks lasting either half an hour or one hour, and there were always three or more taking place simultaneously, so attendees had to choose which ones to attend. In any case, most of the talks were recorded, and you can find them on YouTube after May 31.

Below, I briefly describe the talks I found most relevant and my favorites.

CISA-ENISA Joint Messaging

This image and the others related to the talks were taken from first.org

This was the event's welcome talk, delivered by Lindsey Cerkovnik and Nuno Rodrigues Carvalho. It showed how agencies such as CISA in the United States and ENISA in Europe are currently supporting the CVE ecosystem.

On one hand, CISA remains one of the program's main drivers: it sponsors the program, participates in its evolution, and also contributes operational capabilities through vulnerability management initiatives, disclosure coordination, and catalogs such as KEV, which help prioritize actively exploited vulnerabilities.

On the other hand, ENISA has been strengthening its role in the European environment by promoting Coordinated Vulnerability Disclosure policies, serving as a CNA for certain cases reported by European CSIRTs, and developing the EU Vulnerability Database (EUVD) as a curated source of actionable information.

In that sense, the joint effort between both regions is not limited to "supporting" the CVE program in the abstract; it also strengthens coordination, improves the quality of vulnerability information, and creates more useful mechanisms for vendors, coordinators, and end users.

A Paradigm Shift in Vulnerability Identity: Why Vulnerability Databases Struggle

In this talk, Art Manion and Jay Jacobs offered constructive criticism of how the vulnerability registration ecosystem works and why they believe it is broken — that is, why it is difficult to define and name software and reach agreements. They also relied on philosophical ideas to justify, to some extent, the principles that would guide the reform of the entire system.

From the beginning, they made it clear that this was not a framework or a criticism of the creators, but rather a set of new principles from which everything else could be built. This was because they had realized that the quality problem in databases is less about the data itself and more about the architecture and the principles that govern them.

Specifically, the speakers pointed out that vulnerability databases suffer from several underlying complications: first, central concepts such as "vulnerability" are not always defined precisely enough; second, names and identifiers do not always consistently represent the real object they point to; and third, records are often treated as static entries, when in reality they should be understood as living artifacts that need to be updated and enriched over time.

CVD and CVE for Researchers: Meet the Researcher Working Group

This was more of a presentation of the CNA Researcher Working Group (RWG) than a talk. In this context, various groups aim to bring together CNAs around common topics and scopes. During this session, a protocol called CVE-DIBS was mentioned. It consists of a mechanism to coordinate which CNA takes on an urgent case involving a vulnerability that has already been publicly disclosed, with the goal of quickly assigning it a CVE and avoiding duplicates or conflicts between CNAs.

Information was also shared about how each CNA operates within its own scope. VulnCheck, for example, focuses on assigning CVEs to public vulnerabilities that still lack an identifier, to cases reported by third parties, and to its own findings, even in uncommon or atypical scenarios. HeroDevs focuses its work on vulnerabilities affecting EOL software, flaws its team finds in the libraries it uses, and reports it receives through bug bounty programs.

GitHub, for its part, assigns CVEs mainly to vulnerabilities in projects hosted on its platform when the maintainer requests one, as well as to cases discovered by its research team or submitted by researchers already familiar with the process. Finally, Trend Micro ZDI assigns CVEs to vulnerabilities discovered, acquired, or investigated by the Zero Day Initiative, relying on its internal research team and fuzzing infrastructure. In many cases, it identifies the vulnerability before the vendor does, provides the vendor with a high-quality report that includes a proof of concept, and then assigns the CVE.

Deriving CVSS from Multi-Scenario Attack Graphs: A Reproducible, Auditable Scoring Method

In this talk, Karel Knibbe and Ruben Bos from Volerion showed that sometimes, when people try to assign a single CVSS score that accounts for multiple possibilities, they end up mixing metrics from several scenarios and produce a score that does not actually represent any of them. As an alternative, they proposed a method called Multi-Scenario Attack Graphs, which uses attack graphs in which all metrics and impacts are represented as questions. Each path represents an attack scenario with its own score, and the highest is ultimately selected.

AI Systems Are Software Systems

In this interesting talk, Jonathan Spring from CISA discussed how AI systems are software systems and, therefore, that the rules applied to CVEs should apply there as well. Many existing rules for CNAs would apply to AI systems, but others would need to be modified, and some new ones would also have to be created. Spring also mentioned how we could identify products and how models and datasets are like libraries and configuration files. In the end, he invited those of us working in cybersecurity to educate AI engineers and help them understand why security is important and what the consequences would be if it were not taken into account.

Conclusions

VulnCon26 confirmed that the vulnerability ecosystem is undergoing a significant period of change. Between new discussions about artificial intelligence, problems identified in its current state, and proposals to improve processes and standards, the conference showed that the future will depend on both technical innovation and the ability of all stakeholders to collaborate. In that sense, VulnCon feels like an increasingly relevant space for understanding where the industry is heading.

After attending this event, one of the most natural questions is: would I go back? The short answer is yes. Beyond being a niche conference, it is one of the few spaces where the real problems in the vulnerability ecosystem are discussed in depth: from how vulnerabilities are defined and documented to how they are coordinated and used at scale by researchers, customers, and users. That level of specialization, combined with the quality of the conversations, makes this event highly valuable for those of us who work in vulnerability management.

Likewise, when comparing VulnCon 2026 with what we are currently doing at Fluid Attacks, it is clear that, as an organization, we should return. Not only because we are a CNA and the event is highly relevant to our work, but also because we are already building exactly the kind of things discussed there. For example, we are currently discovering vulnerabilities in open-source projects using AI, publishing real advisories with CVEs derived from that process, and exploring models to prioritize projects based on their impact on the ecosystem.

In that sense, I believe we would not only have material to present but also a clear opportunity to contribute value to the ecosystem. Topics such as the use of AI to identify vulnerabilities in open-source software, strategies to reduce false positives and validate findings, prioritization based on real impact beyond severity, and the evolution of that process all the way to CVE assignment are lines of work that we could develop into articles, publications, and even future presentations. Ultimately, it is clear that VulnCon is an event where all of us who are building the future of vulnerability management should share how we are doing it.