Responsible disclosure in the age of Vulnpocalypse

New tools can find potential flaws faster than teams can assess and fix them. When a serious flaw is discovered, the central challenge is ensuring maintainers, distributors, and operators receive the clear information and time necessary to defend their users.

While AI-assisted research surfaces potential vulnerabilities at a scale that strains human defenders and empowers attackers, discovering flaws is merely the first step. Red Hat has described this ongoing Vulnpocalypse, starting with Mythos Preview in April 2026. Ultimately, dedicated experts must still validate these findings, evaluate their actual impact, craft reliable fixes, and guide operators toward effective protection.

That work takes coordination, and true coordination across an entire ecosystem requires human trust. Machine speed does not replace this human trust. Red Hat Product Security has handled vulnerability response since 2001. Today, our coordinated disclosure process connects reporters, upstream communities, engineers, and customers to turn findings into tested fixes and useful guidance.

Trust is the currency of disclosure

Open source security depends on a chain of people: researchers who report problems, maintainers who know the code, coordinators who connect affected parties, and defenders who must protect running systems. A coordinated disclosure process gives them a way to work through the same problem without creating avoidable surprises.

Each party needs something from the others. Finders need a timely response, honest assessment, and appropriate credit. Maintainers need enough context and time to reproduce the issue, develop a fix, and test for regressions. Coordinators need participants to honor agreed confidentiality and release plans. Downstream vendors and users need clear information and practical mitigations when the issue becomes public.

That is why an embargo can matter. It is a short, defined window for preparing defenses, not a claim that information should stay secret indefinitely. Red Hat’s guidance calls it a tactical head start for defenders. If a participant publishes exploit details before the agreed date or a public commit reveals the issue, that head start can disappear. So can the confidence needed for the next report.

An agreed disclosure plan can come under pressure. Researchers may grow frustrated by silence or fear losing credit. Companies may feel pressure to release an analysis or a fix. A misunderstanding can expose information early without anyone acting in bad faith. If that happens, alert affected parties and give users the information available. Active communication and realistic timelines help prevent avoidable surprises.

The cost lands on people

A broken disclosure plan moves work onto people who had no chance to prepare: the maintainer facing a flood of reports, the distributor assembling a safe update, and the on-call engineer trying to find every affected system. That work looks like midnight pages, cancelled weekends, urgent change windows, and the familiar call for #hugops. It is hard to measure on a dashboard, but it is part of the security cost.

Log4Shell showed how quickly a widely used dependency can turn into an ecosystem-wide response. Apache reported that exploitation began before the fixed release was published. Once the issue was public, teams still had to identify affected systems, test updates, and deploy them under pressure. A public advisory can tell you where to start; it cannot do those jobs for you.

The imbalance is sharper upstream. A large company may have dedicated security staff and advanced scanners. A small open source project may have a handful of maintainers, or one. The curl project recently described the strain of an avalanche of vulnerability reports and announced a change to how it will handle lower-severity findings. It is a reminder that more reports do not automatically create more capacity to validate and repair them.

AI can help with triage and patch review, but its output still needs human judgment. Some reports repeat a known issue, depend on unlikely conditions, or lack a meaningful exploit path. Reporting repeats or flaws lacking real merit wastes time, a resource that open source maintainers do not have, and increases risk of maintainer burnout. 

A real flaw still needs a fix that works across supported versions and does not create a new problem. That takes code review, testing, packaging, and sometimes negotiation among vendors with different release cycles. One organization can patch its own system and still depend on a database, service, or device whose provider is not ready. Skipping these steps can leave users with a fast answer and an unsafe result.

Coordination must fit the risk

Coordinated vulnerability disclosure is a process, not a promise to keep every report private. First, establish whether the issue is real and who is affected. Then agree with the finder and relevant upstream and downstream parties on mitigation, a reasonable public date, and what each group can say. If circumstances change, update the plan and tell the affected parties. A participant who believes the release plan must change should bring the new risk to the reporter, coordinator, and affected parties, then work through a revised plan and notice. Coordination is work, not a calendar invite. 

Different risks call for different handling. The curl project’s plan to discuss lower-severity reports in public is one example of a community adapting its process. A serious flaw with an exploit path may need limited sharing while a fix is prepared. If details are already public, defenders need prompt notice even if a fix is not ready. Red Hat’s disclosure policy makes that last point explicit.

History also counsels against easy victory stories. Spectre and Meltdown demanded work across hardware, operating systems, and cloud services. Heartbleed required upstream repair and downstream action across a huge installed base. These cases show the value of coordination and its limits: A fix at the source does not instantly protect every running system.

Support upstream without adding to the load

Enterprise users depend on open source projects, and many contribute to them. When a report affects an upstream project, our job is to engage through its established channels, share useful technical context, help validate the issue, and contribute repair and testing where the project wants that help. We should agree on a disclosure plan with the people doing the work, keep affected users informed under that plan, and avoid turning a maintainer’s inbox into another incident. That means contributing engineering time and review, not just asking for a patch date.

At Red Hat, our published reporting and coordination procedures put this work into practice: reporters can reach Product Security securely, embargoed details are only shared with those who need them, and release plans are coordinated with affected parties - start to finish. Our participation in Akrites extends support for vulnerability response to critical open source projects. These commitments help communities prepare and respond without dictating their timelines.

AI will keep changing how quickly we find flaws. Our response must change too: better triage, clearer contacts, shared engineering capacity, and disclosure plans that fit the risk. The part to preserve is the human agreement underneath it all. Security leadership is not a race to publish first. It is the work that helps the whole ecosystem move forward safely, preserving the trust along the way.