Microsoft faces backlash after a blog post implied criminal referral and legal action against security researcher Nightmare Eclipse over public bug disclosures
After a security researcher published a series of unpatched bugs in Microsoft products, along with code to exploit them …
TechCrunchLorenzo Franceschi-Bicchierai
Context & Ripple Effects
Microsoft’s dispute with Nightmare Eclipse follows a long-running tension in its coverage: the company has previously objected to public vulnerability disclosure before a patch, while researchers’ findings have also exposed actively exploited Windows flaws that required fixes.
The current backlash also lands as Microsoft is reshaping its security business around customer concern over AI-enabled attacks. Its security posture is therefore under greater scrutiny, including how it treats outside researchers who surface product weaknesses.
First-order effects
Microsoft faces immediate reputational pressure to clarify whether its blog language represents a legal-threat posture toward Nightmare Eclipse or a narrower response to publication of unpatched bugs and exploit code.
The researcher and other independent vulnerability finders face a less predictable disclosure environment for Microsoft products while the company’s response is contested publicly.
Second-order effects
A perceived move toward criminal or legal escalation can make coordinated disclosure harder: researchers may demand clearer safe-harbor terms, while Microsoft may face pressure to demonstrate faster, more transparent handling of reports.
Microsoft’s enterprise security customers may scrutinize not only the disclosed bugs but also the company’s vulnerability-response process, particularly as Microsoft positions security as a central business priority.
Third-order effects
If conflicts over unpatched public disclosures become more adversarial, the industry may further formalize disclosure rules, safe-harbor protections, and escalation paths rather than relying on informal researcher-vendor trust.
The episode highlights a persistent trade-off: vendors seek time to protect users before exploit details spread, while researchers use public disclosure to force action when they judge private processes insufficient; which side gains influence will depend on the credibility of vendors’ patching and communication.
The trend: This is one data point in the broader shift from informal vulnerability disclosure norms toward more explicit, contested rules governing researcher access, exploit publication, and vendor accountability.
Chat, I don't want to be that guy, but I think Microsoft has really pissed off security researchers and we're approaching the tipping point. This Eclipse guy has really rocked the boat for Microsoft. [image]
Last time I dealt with MSRC. Responsibly disclosed an issue with legacy auth that allowed me to spray passwords at <redacted endpoint> and avoid smart lockout. Receives email.. 5 months after initial case opening. “Doesn't meet the bar for servicing” Microsoft silently
...After the agreed-upon Patch Tuesday a few months later, I couldn't find any mention in the CVE list, so I reached out to MSRC to inquire. It turns out - they changed their minds, deciding it did not meet their bar for servicing, yet they patched it anyway. Since it didn't me…
Not that ‘responsible’ disclosure shit again 🙄 No vendor uses that term unless they want to call someone irresponsible. Even if someone drops 0day, patch & move on. Going after a researcher is a great way to turn 1 bad relationship into many terrible relationships.
Security research reporting is kinda the only situation where an individual has any power over a corporation. What goes unsaid: the researcher could easily sell exploits on the grey market and get rich. Most report out of morals, lowk a refusal to contribute to cyberwarfare.
Working at MSRC handling vuln reports has to be one of the most utterly thankless jobs in tech. You have to find incredibly important reports in a crush of crap while retroactively justifying the decisions of product teams on what to fix when using flawed servicing guidelines.
Since we're all sharing MSRC stories: Once at the CERT/CC I got the CVE ID for a public case and published the ID before Microsoft had an update released for it. MSRC was very mad at me because in their minds CVE IDs are used to identify Patch Tuesday updates, and are secret.
...This is because the unappreciated researcher released more zero-day vulnerabilities on his own and had those GitHub/Lab accounts banned. They were serious enough that Microsoft is scrambling to fix them but wasn't serious enough to be paid or recognized, instead was ridiculed…
This is important. MSRC is probably the loudest worst case but check any bug hunter and they will have a myriad of cases where vendors act in bad faith. Doing the righteous thing is good but unfortunately it does not pay the bills. We need to understand as a society that if we
Since everyone is sharing MSRC stories 🙃 I had a PrivEsc from User Admin, a role many give helpdesk or HR, to Global Admin MSRC: Not a vulnerability, requires a built-in Microsoft app in the tenant to exploit Also MSRC: It's a vulnerability when someone else submits it🤷♂️
Microsoft Security Response Center put out a blog post today about Eclipse Nightmare guy Basically they think he's super mean and totally not cool he's dropping zero days. They say you're a jerk if you do this stuff because it's dangerous and stuff https://www.microsoft.com/...
NEW: Microsoft is facing heavy criticism from the cybersecurity community for threatening to take legal action and call the cops on a security researcher who published unpatched bugs online. — Cybersecurity veterans warned that Microsoft's approach here could result in a chilli…
What's happening at MSRC now belatedly confirms the rumors from 1-2 years ago when a bunch of security researchers who left the department said the “bad corporate guys” had effectively taken over and the S in MSRC stopped standing for “security” [embedded post]