When Researchers Go Public: The Cost of Botched Disclosure

Security researchers choose full disclosure over responsible disclosure when they lose trust in the vendor’s process, not because they want to cause harm. The trigger is almost always operational: a report that sat unacknowledged for weeks, a fix that shipped silently with no credit, or a severity rating quietly downgraded to “no impact.” When a researcher concludes that coordinating with you is a waste of their time, they publish. The bug was never the problem. Your disclosure process was.

This is the day-2 problem most teams ignore. Setting up a vulnerability disclosure program is the easy part: a security.txt file, a scope statement, an inbox. Running it so that real researchers keep reporting to you instead of about you is the hard part. And in 2026, the cost of getting it wrong has been on full public display.

The github.dev disclosure that skipped Microsoft entirely

On June 2, 2026, security researcher Ammar Askar published a complete proof-of-concept for a one-click GitHub OAuth token theft in github.dev, the browser-based VS Code editor. The exploit chained VS Code’s webview keydown-event bubbling to silently install a local extension and exfiltrate the user’s token. The stolen token was not scoped to a single repository; it granted access to every repo the victim could reach, including private ones (sources: BleepingComputer, CSO Online).

The technical severity was high. But the part every program owner should study is the disclosure itself.

Askar gave GitHub only one hour of notice before going public, and he explicitly skipped Microsoft’s Security Response Center (MSRC) entirely. His stated reason: a prior VS Code bug he had reported was silently fixed without credit and marked as having no security impact. He concluded the process would not treat his work fairly, so he stopped participating in it. A cooperative researcher became a zero-day dropper because of how a previous report had been handled.

That is the entire lesson in one sentence. The disclosure failure converted an ally into an adversary, and no amount of technical excellence on Microsoft’s side could undo it after the fact. Microsoft shipped a stopgap fix (a confirmation prompt for web notebooks and a block on the publisher-trust skip), but the trust was already gone, and the unpatched exploit was already public.

Responsible disclosure vs full disclosure, and why the line moves

Responsible disclosure (also called coordinated vulnerability disclosure) is when a researcher reports privately and gives the vendor time to fix the issue before any public detail appears. Full disclosure is when the researcher publishes the vulnerability, often with a working exploit, before a patch exists. The line between them is not a personality trait. It is a function of whether the researcher believes the vendor will hold up their end.

The industry has well-known reference clocks for what “fair time to fix” means:

• Google Project Zero uses a 90-day disclosure deadline, dropping to 7 days for bugs being actively exploited.
• CERT/CC discloses 45 days after the initial report, regardless of whether a patch is available.

(Sources: CERT/CC Guide to Coordinated Vulnerability Disclosure, Wikipedia: Coordinated vulnerability disclosure.)

These windows exist because researchers needed a neutral standard to point to when vendors stalled indefinitely. They are the benchmark a frustrated researcher measures you against.

What responsible disclosure actually asks of a vendor

Responsible disclosure is a two-way deal. The researcher agrees to wait and stay quiet. In exchange, the vendor agrees to acknowledge the report quickly, communicate honestly about severity and timeline, fix the issue, and give credit. Most published disclosure policies frame it exactly this way: cooperation in return for good-faith handling. When one side keeps its promise and the other does not, the deal collapses.

When researchers decide it’s not worth it

Researchers are not paid to wait. Many do this work in their spare time, and their reputation is built on public attribution. When a vendor treats a report as a chore, ignores it, or strips the credit that justifies the unpaid effort, the rational move is to stop coordinating. Going public restores the one thing the broken process took away: visible proof of the work.

Why researchers go public: the five trust-killers

Across the github.dev incident and the broader research on disclosure programs, the same five operational failures show up again and again. None of them are technical. Each is a process decision you control.

1. Slow or silent acknowledgment. A report that sits unanswered signals the researcher’s time doesn’t matter.
2. Unjustified severity downgrades. Marking a real bug “no impact” or “low severity” reads as bad faith, especially when the researcher can’t see the reasoning.
3. Silent fixes with no credit. Shipping the patch but erasing the researcher’s name removes their entire incentive to report privately.
4. Late or missing payment. When a bounty is promised, delays and disputes corrode trust as fast as a downgrade.
5. Communication blackout. Going dark during the fix window leaves the researcher guessing whether anything is happening at all.

(Sources: OWASP Vulnerability Disclosure Cheat Sheet, HelpNetSecurity interview with Roy Davis, Zoom.)

Slow or silent acknowledgment

Acknowledgment is the cheapest trust signal you have, and the easiest to fail. A researcher who emails your inbox and hears nothing for two weeks has no way to tell whether you’re working the issue or ignoring it. The honest move is fast confirmation that a human received the report and owns it. Government programs treat this as table stakes: the U.S. Department of Commerce and the Department of the Interior both commit to acknowledging reports within 3 business days, and Silicon Labs commits to the same. If federal agencies can hit a 3-day bar, a startup can too.

Unjustified severity downgrades

Severity disputes are the second most common flashpoint, and they’re avoidable. The problem isn’t the rating itself; it’s that the rating arrives as a black-box verdict the researcher can’t inspect or contest. A downgrade that looks like a way to dodge a payout or minimize embarrassment reads as bad faith even when it isn’t. The fix is to base severity on a transparent, standard framework (CVSS) and show your work, so the researcher sees the same inputs you did.

Silent fixes with no credit

This is the failure that triggered the github.dev disclosure. The researcher reported a bug, the vendor quietly patched it, and the researcher’s name appeared nowhere. For someone who builds a career on public attribution, a silent fix is worse than a rejection. It takes the work and the recognition. Credit, whether a CVE acknowledgment or a hall-of-fame entry, costs you nothing and is the single most reliable way to keep a researcher reporting to you next time.

Late or missing payment

If you run a paid program, the bounty is a promise. Researchers consistently cite inconsistent or delayed payment as a reason they abandon programs. A predictable, auditable payout process matters more than a large headline reward. Ambiguity about when and whether they’ll be paid does more damage than a modest but reliable bounty.

Communication blackout

Even when you’re doing the work, silence reads as neglect. OWASP’s guidance is explicit: send periodic status updates even when there’s no progress to report, because the update itself is the signal that the report hasn’t been forgotten. A one-line “still working on it, here’s where we are” every couple of weeks is often the difference between a researcher who waits and one who publishes.

This isn’t rare: the 2026 wave of public zero-day drops

The github.dev incident was not an outlier. The same April–June 2026 window saw a researcher known as “Chaotic Eclipse” publicly drop six unpatched Windows zero-days, three of which were already being exploited in the wild. The stated reasons were a familiar list: ignored reports, a reporting account that had been deleted, zero compensation, and a feeling of being defamed by how a CVE advisory described their work (sources: SecurityAffairs, The Hacker News).

Microsoft publicly condemned the “uncoordinated” disclosures as putting customers at unnecessary risk, then reached for an olive branch after the backlash. The sequence is instructive: blaming the researcher did not fix the process, and it did not stop the next disclosure. When the same failure pattern produces multiple public drops in a single quarter against one of the most resourced security organizations on earth, it stops being a researcher problem and starts being a program-design problem.

What a trustworthy VDP does differently

A trustworthy program turns every one of the five trust-killers into a commitment the researcher can rely on. The mechanics are not exotic; they’re operational discipline applied consistently.

The thread running through all of this is respect for the researcher’s time and work. Get that right and the disclosure clock stays private. Get it wrong and the researcher reaches for Project Zero’s 90 days or CERT/CC’s 45 as the standard you failed to meet.

How Kit operationalizes researcher trust

Kit’s security module (Csirt) was built around exactly these failure modes. Educating yourself on the operating model matters more than any tool, but the value of a tool is that it makes the right behavior the default instead of something you have to remember under pressure. Here is how each trust-killer maps to a concrete setting.

To be clear about what Kit can and can’t claim: Kit has nothing to do with the github.dev bug, and no tool would have “prevented” it. That was Microsoft’s product. What Kit fixes is the disclosure-process failure that pushed the researcher to full disclosure. If your company received a report like that one, Kit’s acknowledgment SLA, transparent CVSS severity, default credit, and predictable payout are what keep the researcher coordinating with you instead of publishing an unpatched exploit.

Your disclosure process is your security posture

The takeaway from 2026’s public zero-day drops is uncomfortable but simple: researchers don’t go public because they’re hostile. They go public because the process disrespected their time and their work. Slow acknowledgment, opaque severity downgrades, silent fixes, late payment, and communication blackouts are not minor administrative lapses. They are the direct cause of unpatched exploits landing on Hacker News with your name attached.

Every one of those failures is a decision you control, and every one of them maps to a setting you can fix today. If you already have a VDP, the next step isn’t more policy; it’s the day-2 operations that keep researchers on your side. Start with the setup guide if you’re not there yet, then turn your intake into an SLA-backed, credited, paid workflow. When you’re ready to run it properly, you can start a free trial and have the whole thing operational in an afternoon.