Coordinated Vulnerability Disclosure: From Finding to Fix

Someone finds a serious flaw in software that millions of people run. What happens next decides whether the flaw gets quietly fixed or turns into a headline breach. That sequence of steps, from a researcher's discovery to a public advisory, is what coordinated vulnerability disclosure governs.

Coordinated vulnerability disclosure, sometimes called responsible disclosure, is the practice of reporting a vulnerability privately to the party who can fix it, giving them a reasonable window to ship a patch, and then publishing the details so defenders can protect themselves. Done well, it gets flaws fixed before attackers pile in. Done badly, users stay exposed while a report gathers dust or details leak too early.

The core tension

Every disclosure decision balances two harms.

Publish too early, before a patch exists, and you hand attackers a roadmap while users have no way to defend themselves. Publish too late, or never, and a flaw the vendor knows about sits unfixed while the same users stay exposed to anyone who independently finds it. Attackers are not the only people who discover vulnerabilities, and secrecy protects no one once a flaw is being exploited quietly.

Coordinated disclosure is the negotiated middle. Report privately, fix quietly, publish once users can act. The whole framework is machinery for holding that balance under pressure from both sides.

The standard flow

A coordinated disclosure typically moves through these stages.

Stage	What happens
Discovery	A researcher finds and confirms the vulnerability
Private report	The flaw is reported to the vendor through a security contact
Triage	The vendor validates the report and assesses severity
CVE reservation	A CVE ID is reserved, often held quiet during the embargo
Remediation	The vendor develops and tests a fix
Coordinated publication	Patch ships and details are published together

The report needs somewhere to land. Mature vendors publish a security contact or a security.txt file, and many run a formal program. When there is no obvious contact, national coordinators such as a CERT can act as a neutral go-between, relaying the report and mediating the timeline.

Getting the CVE reserved early matters because it gives everyone a shared reference before anything is public. The CVE record sits in a reserved state, an ID with no details, until the embargo lifts.

Timelines and embargoes

An embargo is the agreement to keep details private until an agreed moment, normally when the patch is available. During the embargo the researcher holds their findings, the vendor builds the fix, and the reserved CVE stays blank.

Timelines exist to keep an embargo from becoming indefinite. A common industry norm is a window of around 90 days from report to publication, with the understanding that a vendor making genuine progress can negotiate an extension, and that a fix which ships early can move publication up. The deadline is the lever that stops a report from being ignored. Without one, a vendor could keep a flaw embargoed forever while users stay at risk.

The full-disclosure debate

Not everyone agrees on how much patience vendors deserve. The disagreement has a long history and two poles.

Full disclosure means publishing complete details, sometimes including working exploit code, immediately and publicly, with little or no private notice. Its advocates argue that it maximises pressure on vendors to fix fast, that it lets defenders take action at once, and that a flaw the researcher found can be found by attackers too, so secrecy offers false comfort. The cost is real: full disclosure can hand attackers a ready weapon before any patch exists.

Coordinated disclosure accepts a delay in exchange for a patch being ready when details land. Its critics point out that it depends on vendors acting in good faith, and that a slow or dismissive vendor can drag out the window while users wait.

Most of the industry has settled near coordinated disclosure with a firm deadline, which borrows the discipline of full disclosure's clock while keeping the safety of a patch-first release. A vulnerability that ends up exploited before any fix exists is a zero-day, which is exactly the outcome coordinated disclosure tries to avoid.

Where bug bounties fit

Bug bounty programs formalise the front of this process. A vendor publishes a scope, a set of rules, and a reward schedule, and researchers submit findings through a managed channel, often run on a dedicated platform.

Bounties do a few useful things at once. They give researchers a clear, safe, and paid route to report, which pulls findings into a coordinated process instead of the open web. They provide legal comfort through safe-harbour language, so good-faith research is not treated as an attack. And by attaching a reward, they raise the volume and quality of reports a vendor receives. The broader economics of who pays for vulnerabilities, and how that market shapes disclosure, is its own topic, covered in The Bug Bounty Economy and The Exploit Market.

A bounty is one funnel into coordinated disclosure, not a replacement for it. The triage, the CVE, the embargo, and the coordinated publication still follow the same path once a valid report arrives.

How to handle disclosure well

For anyone reporting a flaw:

1. Find the right channel first. Look for a security contact, a security.txt, or a bounty program before anything else. Use a CERT coordinator when no contact exists.
2. Report clearly and privately. A reproducible write-up with impact and steps helps the vendor fix faster and keeps the process coordinated.
3. Agree a timeline in writing. Set an expected disclosure date up front so both sides share the same clock.
4. Hold the embargo, but keep the deadline. Give a good-faith vendor room to extend when a fix is real, and publish when the window closes if it is not.

For vendors and defenders:

1. Publish a way to be reached. A missing security contact is the most common reason disclosure goes wrong.
2. Triage fast and communicate. Silence is what pushes researchers toward full disclosure.
3. Ship the patch and the advisory together, with the CVE, so users can act the moment details go public.

A walkthrough of a disclosure from both sides

The process is easier to hold in mind as a story told from two chairs at once, the researcher's and the vendor's, because the friction usually comes from a mismatch between them.

A researcher finds a flaw while testing a product. Their first job is to confirm it is real and to understand its impact, because a vague or unreproducible report wastes everyone's time and may be dismissed. They write up the steps to reproduce, the conditions required, and what an attacker gains. Then they look for somewhere to send it.

On the vendor's side, the report lands in an inbox or a program queue. The first task is triage: is this real, is it in scope, how severe is it, and does it duplicate something already known. A good triage reply within a day or two tells the researcher they were heard, which is the single most effective thing a vendor can do to keep the process cooperative. Silence, by contrast, is what pushes a frustrated researcher toward publishing early.

Once the vendor confirms the flaw, both sides agree on a timeline. The vendor reserves a CVE identifier so there is a shared reference, and it stays in a reserved state with no details while the fix is built. The researcher holds their write-up during this embargo. If the fix is complex, the vendor may ask for an extension, and a researcher acting in good faith usually grants it when real progress is visible.

The fix ships. Ideally the patch, the advisory, and the now-populated CVE record all become public together, so defenders learn about the flaw at the same moment they gain the means to close it. The researcher publishes their write-up, often with credit, and the record moves from reserved to fully described. When the sequence works, the first time most users hear of the flaw is when a patch is already waiting for them.

Detection and coordination signals

Coordinated disclosure leaves observable traces, and knowing how to read them helps a defender act on the right timing rather than the loudest one.

The first signal is a reserved CVE with no details. This is the embargo working as intended. An identifier exists so everyone can reference the coming fix, while the specifics stay private until a patch is available. A blank record during an active disclosure is a sign of coordination, not an error to report.

The second signal is a vendor advisory published alongside a patch. This is the payoff moment, and it is the cue to prioritise patching. An advisory that arrives with a fix, a CVE, and a clear severity rating gives you everything needed to act.

The third signal is a public proof-of-concept or exploit appearing shortly after disclosure. Once details are out, working exploit code often follows within days, which compresses the time you have to patch. Watching for exploit availability, not just the advisory, tells you how urgent a given flaw has become.

The fourth signal is a flaw disclosed with no patch available, sometimes because a deadline expired on an unresponsive vendor. This is the case that demands compensating controls, since patching is not yet an option and attackers now have the same information you do.

Coordinated disclosure compared to the alternatives

Coordinated disclosure is one point on a spectrum of how a finding can reach the public. Seeing the options side by side clarifies the trade-offs each one makes.

Approach	When details go public	Pressure on vendor	Risk to users
Private disclosure only	Never, or only to the vendor	Low	Flaw may sit unfixed indefinitely
Coordinated disclosure	After a patch, on an agreed timeline	Moderate, backed by a deadline	Low when the process holds
Coordinated with a firm deadline	At the deadline whether or not a fix ships	High	Low to moderate, users may briefly lack a patch
Full disclosure	Immediately, often with exploit code	Maximum	High, attackers get a weapon before a patch

Most of the industry has settled near coordinated disclosure with a firm deadline, because it borrows the discipline of full disclosure's clock while keeping the safety of a patch-first release. Pure private disclosure with no deadline gives a vendor no reason to hurry, and pure full disclosure hands attackers a working exploit before users can protect themselves. The deadline is the mechanism that keeps the middle ground honest.

Common misconceptions

Several beliefs about disclosure lead people to misread the process or behave badly within it.

The first is that responsible disclosure means the researcher must stay quiet forever if the vendor asks. It does not. The whole point of a deadline is that the embargo has an end. A vendor cannot demand indefinite silence, because that would leave users exposed to a known flaw with no resolution.

The second is that a deadline is an act of hostility toward the vendor. The deadline exists to protect users, not to punish anyone. The alternative, an open-ended embargo, means a stalled or dismissive vendor can keep a flaw quiet while the risk to users continues. The clock keeps remediation moving.

The third is that a CVE identifier means a flaw is confirmed and serious. A reserved CVE is only a placeholder. It becomes meaningful when the record is populated with details and a severity assessment. An identifier by itself says nothing about whether the flaw is real or how bad it is.

The fourth is that a bug bounty replaces coordinated disclosure. A bounty is a funnel into the process, a managed and paid channel that raises report quality, and the triage, the CVE, the embargo, and the coordinated publication still follow the same path once a valid report arrives.

The fifth is that finding no exploit in the wild means a disclosed flaw is not urgent. Exploitation often follows disclosure rather than preceding it, because public details and proof-of-concept code lower the bar for attackers. A freshly disclosed flaw can move from theoretical to actively exploited quickly, which is why the window right after publication matters.

Harder cases: multi-party and supply-chain disclosure

The clean story of one researcher and one vendor describes the simple case. Many real disclosures are harder because the flaw does not belong to a single party.

A vulnerability in a widely used open-source library affects every product that ships it, sometimes hundreds of downstream vendors who each need time to pull the fix, rebuild, and release. Disclosing to the library maintainer alone is not enough, because the fix has to propagate through a long chain before users are protected. Coordinating this is a real logistical problem, and it is where a neutral coordinator such as a CERT earns its place, quietly notifying affected downstream vendors under embargo so they can prepare updates in parallel and ship close together.

Hardware and firmware flaws stretch the timeline further. A flaw in a processor or a networking chip can take many months to fix, because mitigations may require microcode changes, firmware updates from multiple manufacturers, and in some cases changes to operating systems that run on the affected hardware. Embargo periods for this class run far longer than the usual software window, precisely because the fix has to move through many hands before a user can apply it.

These cases sharpen why coordination exists at all. With a single vendor, a researcher could in principle just wait or just publish. With a supply chain of dozens of dependent products, uncoordinated disclosure would leave most of them exposed while a few patched, and attackers would target the laggards. The coordinator's job is to synchronise the release so the whole ecosystem moves at once rather than in a ragged line that attackers can pick apart.

Frequently asked questions

What is the difference between responsible disclosure and coordinated disclosure?

They describe the same practice, and coordinated disclosure is the preferred term. Reporting privately, giving the vendor time to fix, and publishing once users can act is the core of both. Some people avoid responsible disclosure because the word responsible implies that any other choice is irresponsible, which is a value judgment the neutral term coordinated disclosure sidesteps.

Why reserve a CVE before the details are public?

So everyone shares a single reference for the flaw before it is described. During the embargo the identifier exists in a reserved state with no details, which lets vendors, researchers, and coordinators discuss the coming fix without leaking specifics. When the patch ships, the record is populated and the identifier already means the same thing to everyone.

What happens when a vendor ignores a report?

The disclosure deadline is the answer. If a vendor does not respond or does not fix the flaw within the agreed window, the researcher may publish anyway, on the principle that users deserve to know about a risk that affects them. A national coordinator such as a CERT can also step in to mediate when a vendor is unresponsive or has no security contact.

Is full disclosure ever justified?

Advocates argue it is, particularly when a vendor is unresponsive, when a flaw is already being exploited, or when users need to take immediate defensive action. The cost is that full disclosure can hand attackers a working exploit before a patch exists. Most practitioners reserve it for cases where coordination has failed, rather than as a first move.

How long is a typical disclosure window?

A common industry norm is around 90 days from report to publication, with extensions negotiated when a fix is genuinely in progress and early publication when a patch ships sooner. The exact window varies by coordinator and by the severity and complexity of the flaw. The principle is a fixed, agreed target rather than an open-ended wait.

How do bug bounties change the process?

They formalise the front of it. A vendor publishes a scope, rules, and rewards, and researchers submit through a managed channel with safe-harbour language that protects good-faith research. This pulls findings into a coordinated process instead of the open web, raises report quality, and gives researchers a clear and paid route to report. The rest of the process, triage through coordinated publication, still applies.

What should a defender do the moment a flaw affecting them is disclosed?

Determine whether a patch exists and apply it if so, prioritising by severity and by whether exploitation is likely or already observed. If no patch is available, apply compensating controls such as restricting access, adding detection, or disabling the affected feature. Watch for public exploit code, since its appearance sharply raises urgency, and treat the period right after disclosure as the window attackers are most likely to use. Record the decision and the timeline you followed, so a later review can see why a given flaw was patched when it was.

Coordinated disclosure is a quiet process that only makes news when it fails. When it works, a researcher and a vendor cooperate under a shared clock, a patch and an advisory land together, and defenders learn about a flaw at the same moment they gain the means to close it. That orderly handoff, from finding to fix to publication, is what keeps the discovery of a serious flaw from becoming the next breach.

Related guides

• The CVE System Explained
• Zero-Day Vulnerabilities
• The Bug Bounty Economy Explained
• The Exploit Market Explained
• The KEV Catalog Explained