The Past is Always Present in Vulnerability Disclosure

Here’s a fun mental exercise: Read this paragraph and try to guess what year it was written:

In recent weeks several zero-day vulnerabilities have been publicly disclosed. The details of these vulnerabilities were not shared with Microsoft prior to release, and the disclosures put our customers at unnecessary risk. 

Was it 1999? Or maybe 2003? Or even 2010? All valid guesses. But the correct answer is 2026, specifically May 27, 2026. Which was yesterday. Not yesteryear. Yesterday. 

That paragraph appears in a somewhat baffling and odd blog post from the Microsoft Security Response Center entitled “A shared responsibility: Protecting customers through Coordinated Vulnerability Disclosure”. Right from the jump you can sense the tension, and the rest of the piece delivers on that promise. The post is a response to a handful of serious vulnerabilities in Microsoft products–including three in Microsoft Defender–that were disclosed publicly by an actor known as Nightmare-Eclipse and later exploited before Microsoft knew about them or had a chance to develop patches for them. 

The Nightmare-Eclipse actor seems to be a security researcher who became disillusioned with the MSRC disclosure process and began making online threats against Microsoft and eventually publishing a series of six vulnerabilities in Microsoft products. The actor was banned from GitHub and GitLab subsequently and Microsoft had to scramble and issue a series of out-of-band patches for these vulnerabilities.

This practice of publishing bug details is as old as software itself and known by various names, depending upon your position and perspective. Researchers call it dropping 0-day and it’s been a regular feature at security conferences for 30-plus years. Software vendors like to call it irresponsible disclosure, or if they’re feeling generous, uncoordinated disclosure. 

Microsoft has led the charge for what it calls coordinated vulnerability disclosure, encouraging researchers to report their findings directly to the company rather than releasing the details publicly. The idea, of course, is to give the vendor the chance to vet the discovery, see if it’s a valid bug, and if so, develop a patch before adversaries have a chance to exploit it. It’s a logical and practical framework that most software vendors and the majority of security researchers work within, but it’s just that: a framework. 

Microsoft’s CVD stance, and later its bug bounty program, are the response to years of accumulated scar tissue from the pre-Trustworthy Computing days when worms such as Code Red and SQL Slammer ran amok and researchers were regularly publishing vulnerabilities on BugTraq and Full-Disclosure. Microsoft, like most vendors at the time, didn’t really have a security response function as such, and it took many years of hard work for the company to build up the relationships with researchers that would enable the CVD idea to work. 

"Proper coordination” sounds like a boarding school headmaster scolding a student for his poor discipline and slovenly appearance.

And it has for the most part. 

But an apparent lack of historical perspective and institutional knowledge is threatening to undo all of that work with a quickness. 

Independent researchers who find vulnerabilities can essentially do whatever they want with them. It's their work and how they handle it is up to them. We’d all like to have bugs reported, triaged, and patched before the details are published, but it’s never worked that way and it never will. There will always be researchers who opt to disclose their findings outside of the vendors’ frameworks, whether it’s out of malice, frustration with the vendor’s process, or a simple desire to do their own thing. The Nightmare-Eclipse episode is an outlier, but not completely unprecedented. Those disclosures can cause problems for vendors and open users up to attack, and this is what has caused all the consternation in Redmond.

“We remain firmly opposed to these actions, and any disclosure outside proper coordination that could harm our customers and the digital ecosystem. Uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable and have real-world consequences,” the MSRC post says. 

The word choices matter a lot here. “Proper coordination” sounds like a boarding school headmaster scolding a student for his poor discipline and slovenly appearance. It’s imperious. It’s not the way that peers communicate with each other. 

But it’s the second half of that paragraph that’s the real hammer.

“Our Digital Crimes Unit will continue bringing cases against these actors and those that enable their criminal activity – coordinating as needed with law enforcement around the world,” the post says. 

The phrase “those that enable their criminal activity” is unsubtle and heavy with portent. It’s broad and could encompass not just overtly criminal threat actors, but also researchers who disclose their findings outside the “proper” channels. It’s unseemly and unnecessary language that harkens back to the ugliest days of the disclosure debate. The frustration and anxiety inside MSRC as a result of the Nightmare-Eclipse disclosures is understandable, but this brings us no closer to protecting customers, which should be the shared goal for all concerned parties.