> Is your software AI-era safe?
> Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...]
> [Try Xint Code]
More chaos makes their product seem even more attractive.
I get put into a read-only dashboard with ZERO info. is this live? is this static? how do I use it? the API button just leads me to a swagger doc.
Sure, they have no legal obligation to disclose, but we all also have no legal obligation to buy their services. Blacklisting bad actors like this is the right move to discourage this kind of behavior.
I just don't see the point in complaining about how shirking the norms of your industry will make you look irresponsible. I don't really care that they could have decided to sell the vulnerability instead. It isn't material.
Tavis Ormandy dropped Zenbleed right onto Twitter. He's doing fine. You can blacklist him if you want; I imagine he's not going to notice.
There is actually no way to give them a friendly heads up, and then do your own thing. The only way not to be bound is by not sending them any notification at all...
I couldn't find a public copy of that.
The best starting point I found for reporting vulnerabilities was: https://github.com/microsoft/MSRC-Security-Research/security...
You can email without agreeing to anything. But for a serious issue Microsoft would obviously try and track down who you are and what jurisdiction you are in.
> MICROSOFT BOUNTY TERMS & CONDITIONS
> Last updated: July 23, 2025
> The Microsoft Bug Bounty Programs Terms and Conditions ("Terms") cover your participation in the Microsoft Bug Bounty Program (the "Program"). These Terms are between you and Microsoft Corporation ("Microsoft," "us" or "we"). By submitting any vulnerabilities to Microsoft or otherwise participating in the Program in any manner, you accept these Terms.
Who knows if its enforceable.
You said "There is actually no way to give them a friendly heads up, and then do your own thing. The only way not to be bound is by not sending them any notification at all..."
So what you said is wrong, right.
Obviously they can write whatever they want in their policy documents. The thing is, sometimes this is about larger sums of money, or someones reputation, which may or may not actually lead to steps. That is in contrast with whatever TOS/EULA in account signups for some service or whatever, this feels more serious. I've seen some people getting harried after publishing something that fell _outside_ the servicing boundaries. Getting tangled up in whatever is already a loss in my book, even if you "win" in the end.
Note that that policy is also where they set out the safe-harbor conditions, which, according to my read, is tied to the bounty policy and not RD/CVD policy. The RD/CVD page itself specifies no such thing, so I relate them.
Those private actors aren't planning to sit around and hold onto these exploits they've horded forevermore, they're obviously paying for them so they can one day use them.
they did a proper coordinated disclosure, following the industry standard 90+30 process. that is why the exploit dropped 30 days after the patch landed.
the kernel team should have communicated with their downstream about the importance of the patch. that is the kernel security team's responsibility -- and they are much better positioned to do that than crossing your fingers and hoping every reporter will contact every distro every single time there is a vulnerability.
there are very good reasons disclosure works this way, backed by a couple of decades of debate about it.
If it won’t be handled through criminal law then it’ll be handled through civil litigation: Anyone who was exploited as a result of this disclosure should sue the discloser for contributing to the damage they’ve suffered.
And they absolutely have a moral obligation to do things in a way to minimize damage and impact to other people's systems. (I'm not saying "responsible disclosure" is the correct way to do that, but hoarding vulnerabilities and exploits and selling them to the highest bidder certainly isn't.)
This is how society needs to work.
it wasn't sold for profit, it was openly disclosed.
> And they absolutely have a moral obligation to do things in a way to minimize damage and impact to other people's systems.
All that "responsible disclosure" does is keep people from demanding better.
You'll learn who the buyers are if you routinely have the really good stuff to sell! If you are offering iOS zero click on a semi-regular basis, the buyer is going to want to try to deal with you directly and preferably offer you a more regular form of employment, if you are interested. Some national governments may offer certain benefits to you, depending on your situation.
All depends on what you have to offer. If you were able to offer this https://arstechnica.com/security/2025/09/microsofts-entra-id... or something of that magnitude, a lot of problems in your life would just go away. The buyers would all be Five Eyes and the intelligence gain of having that kind of access even briefly is priceless.
In a more Western-centric context, imagine if you had a flaw like that, same 'no logs are generated' and 'every single customer account is accessible' but the impacted vendor was Alibaba Cloud. The researcher would get to name their price. That's the real world, that's the world we share. We shouldn't be blind to that.
Or at least went dark ..
Uh... no? If you mean legally, some people might, depending on jurisdiction. But also, ethically? yes, researchers are ethically obligated to disclose responsibly.
> Just fyi.
...
> Be glad it was disclosed at all. Be glad a patch was available prior to release.
I am glad that a patch was available. Equally I can be glad that the linux community is strong enough to respond quickly, while also being angry that this person behaves unethically.
Likewise, when people in my industry behave poorly, or unethically; I'm now the person ethically obligated to both point it out, and condemn it. Not to become an apologist demanding I should be happy watching bad things happen, when much of the fallout could have been prevented with a bit less incompetence and ignorance.
This is not true in many jurisdictions.
We need an anonymous bounty system.
If so, that's a bit naive. In the actual world, that buyer wants to buy more stuff from me, not penalize me.
We must get public funds to reward ethical disclosure of big impact vulns like this.
Mostly cover citizens within a very limited set of jurisdictions.
Otherwise there's a chance at extradition.
I'm so glad these so called "researchers" aren't totally evil, I'm so grateful they're only half evil, give them a lollipop.
Whatever, the way they disclosed it isn't much different from no disclosure at all - the exploit would have been identified in the wild and fixed soon thereafter.
"Researchers"...
non-security people always seem to get up in arms about it, but there is very good reasons why the industry has landed on the process it has, which has been hashed out over a few decades.
1. Status quo. Researchers are free to disclose to a vendor, free to sell vulns to legitimate companies, free to do full disclosure if they want. This situation benefits security. Researchers are able to pay their bills while also doing meaningful research into OSS projects that are unable to fund the kind of security audit they need. Harm reduction, of sorts.
2. Everyone is a bad actor. No one is going to do this work for free/for a bounty. Horrible flaws will be found and shared with ransomware gangs and the like. 0day will sell for a percentage of the ransom winnings. Researchers will live like kings, everyone else will suffer.
Which do you prefer?
Hell, Crowdstrike is still purchased.
this was a failure of the kernel security team, and their stance on communicating security issues with their downstreams.
In that world, the vulnerability has more value to those who seek to exploit it for their own motives, regardless of the consequences. They hope that no one else stumbles on it and fixes it, preventing them from continuing to use it to do bad things.
In the world where it is disclosed, there is more value in fixing the vulnerability as the maintainer’s reputation is at risk (and potentially monetary loss or legal liability if they are shown to be negligent).
> In computer security, coordinated vulnerability disclosure (CVD, sometimes known as responsible disclosure)
I guess you can learn something new after 36 years.
If you are referring to what you quoted, your pedantry and sharpshooting would result in an incomplete English sentence: "that's why we have the responsible disclosure" is missing a noun. Now that we are firmly in worthless pedantry:
Protocol (n):
1.a. a system of rules that explain the correct conduct and procedures to be followed in formal situations
1.b. a set of conventions governing the treatment and especially the formatting of data in an electronic communications system
If you don't like what I said or disagree, poke holes in factual inaccuracies. However, in the reality that I am pretty sure we all share, responsible disclosure is a well established protocol that is followed by many security researchers, and was imperfectly followed here.
These researchers found a vulnerability in the Linux kernel. They could have just written a blog post and put it online, or not told anybody, or sold it. But instead they decided to tell the Linux kernel devs, and give them time to act before publishing.
And your beef is that you’ve decided they needed to also inform individual downstream projects that use the Linux kernel? Why? Which ones?
No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc...
I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in that "don't update fast enough group" (which is fine, which is human, but is said imperfection).
Major distros should at least have gotten a few days of notice for something this catastrophic. It doesn't help that the kernel is fixed if "normies" aren't able to access it on day 0. For reference, the standard is 30 for the developer to fix and 90 for it to land on machines. Even 30+7 would have been a substantial improvement.
Ethical security research involves ethics, and maybe they aren't referenced in university/college any more - but here's what I was taught: https://www.acm.org/code-of-ethics .
> 1.1 Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.
> [...] Computing professionals should consider whether the results of their efforts will [...] and will be broadly accessible.
> 1.2 Avoid harm.
> (Honestly, all of it)
> 2.3 Know and respect existing rules pertaining to professional work.
> 3.1 Ensure that the public good is the central concern during all professional computing work.
> People—including users, customers, colleagues, and others affected directly or indirectly—should always be the central concern in computing.
Maybe other code of ethics for CS exist; I'd like to know which ethics these ethical researchers were following.
Please don't put words in my mouth when I have clearly stated the contrary. I used the word "disclosure," that is very different to keeping things secret.
> For reference, the standard is 30 for the developer to fix and 90 for it to land on machines.
I’ve never seen that as a standard anywhere.
Are you thinking of this? https://projectzero.google/vulnerability-disclosure-policy.h...
Nobody, for what it's worth, is arguing that major distros shouldn't have gotten some kind of notice. The problem is that the entity responsible for doing that isn't the vulnerability research lab. In fact, as a general procedural point, researchers can't go contact downstreams. They might be able to do so in the specific case of Linux, but you've tried to spin that possibility into a binding obligation derived from established practices, which: no. That's not a real thing.
I never said "binding obligation," that is the first time "binding" has appeared in this discussion and was introduced by you. Once again claiming things I have never said. Doing what you are free to do can still be a shitty thing to do.
I am a bluffing moron who knows nothing, you win.
no, the standard is 90 days from notification or 30 days from the patch date, typically whichever is sooner.
e.g.
> If a vendor patches a security issue 47 days after Project Zero notified
> the vendor about the vulnerability, details would be made public on day 77.
> If a vendor patches a security issue 83 days after Project Zero notified
> the vendor about the vulnerability, details would be made public on day 113.
> There is no such thing as "the responsible disclosure protocol".
And yes, I admit I got dragged down to their level and beat myself with a dumb stick in the process.
Or do you rely on the OpenSSL project to work their established process?
> You: No, I wouldn't, because my own preferences are towards immediate disclosure.
And there it is. You could have said "I don't think responsible disclosure is a good idea" and moved on, but now we have whatever the fuck this is.
Bluffing sure as hell beats incapable of being wrong. I'll take it.