37 ms·

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit w

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.

shimman 5mo ago
Expecting people to do the right thing is a fundamental issue here. Why would you ever expect for all of vulnerabilities to be disclosed privately? There's very little actual incentive to do this. I'm honestly unaware of what systems could be put in place to prevent this but expecting people to always do the right thing is fantasy level thinking. I mean I bet the disclosers thought they were doing the right thing, hence why it's a bad thing to rely on. edit: spelling/grammer.
- baggy_trough 5mo ago
  Why wouldn't the linux security team notify the main linux distributions?
  - deleted 5mo ago
    [deleted]
  - bonzini 5mo ago
    Partly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't. Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).
    - baggy_trough 5mo ago
      Seems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).
      - seanhunter 5mo ago
        You know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.
        baggy_trough 5mo ago
        Thank you very much, seanhunter. You hit the nail on the head there.
        bonzini 5mo ago
        Not really, because they made Linux a CNA specifically to own the process and distort it the way they want it to be.
    - staticassertion 5mo ago
      This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
      - bonzini 5mo ago
        > they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.
  - bluepuma77 5mo ago
    Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?
    - baggy_trough 5mo ago
      Isn't there already a distro security list for this purpose?
      - staticassertion 5mo ago
        Yes.
    - throw0101a 5mo ago
      > Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining? For a first approximation: Ubuntu, Debian, RHEL(-derived) to begin with, and SuSE which is in EU/server space (AIUI): * https://commandlinux.com/statistics/most-popular-linux-distributions-market-share/ https://commandlinux.com/statistics/most-popular-linux-distr... * https://commandlinux.com/statistics/linux-server-market-share/ https://commandlinux.com/statistics/linux-server-market-shar... Seems like Gentoo, Arch, Mint, and Slackware could also be as well: * https://distrowatch.com/dwres.php?resource=major https://distrowatch.com/dwres.php?resource=major U/Deb/RHEL are 'upstream' of a lot of other projects, and fixes would trickle down to Rocky, Alma, etc. Perhaps VM OS in cloud (AWS, Azure) could be a usage gauge as well.
  - shimman 5mo ago
    Because one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.
  - staticassertion 5mo ago
    Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.
    - baggy_trough 5mo ago
      That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.
      - staticassertion 5mo ago
        I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
        baggy_trough 5mo ago
        What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?
        staticassertion 5mo ago
        Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
        baggy_trough 5mo ago
        If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?
- holowoodman 5mo ago
  I can accept (and welcome) disclosure before there are patches. But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal. And no, the proposed mitigations don't help with half of the distributions out there...
  - semiquaver 5mo ago
    Patches were available for nearly a month.
    - ori_b 5mo ago
      Basic care would involve making sure the patches had made it into the wild before ending the embargo, and nagging the relevant parties if not. Edit: As of this writing, most distros including Redhat, Fedora, Debian Stable, do not have patches available in the package repos, though they're being actively worked on.
      - semiquaver 5mo ago
        “Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready?
        ori_b 5mo ago
        Patches are still in the process of landing in most major distros as of the time of this writing. Most users are not able to get an update through their distro's packaging mechanisms.
        SoftTalker 5mo ago
        It's a local vulnerability at least. How many people do you let log in to your router? With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that? Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway...
- skywhopper 5mo ago
  I think it’s reasonable to expect folks in the security community who go to the trouble of creating a website detailing security vulnerabilities in specific listed software to pre-notify the security teams of that software. The CopyFail website calls out Ubuntu and Red Hat specifically, but apparently the author of the site did not inform them of the issue? But even if you think making unethical decisions in personal self interest is something no one should be criticized for, surely the Linux kernel team ought to have some process for notifying the top distributions of an upcoming LPE, just out of practicality.
  - semiquaver 5mo ago
    In what sense do you believe that the reporter did not notify the security team of the relevant software? The vulnerability is in the kernel. Reporter responsibly disclosed using the kernel’s security report mechanism and waited until a patch was ready. Distros are downstream of kernel, that doesn’t entitle them to expect to be contacted directly by every security reporter. That’s not on them. Distros that are big enough should be plugged into the linux security team for notifications. Security researchers cannot be held responsible for broken lines of communication within the org charts of projects that they study. They’re providing a valuable public service already, how much more do you want?
    - ragall 5mo ago
      > that doesn’t entitle them to expect to be contacted directly by the reporter Yes it does. That's how it's always been done and distros can ship a fix well before it ends up in a kernel release.
    - michaelmrose 5mo ago
      It is suggested that they out of an abundance of caution and 5 or 6 emails. If this is entirely to much to expect we can always help them by mandating that they spend 6 figures annually meeting a much more robust set of requirements that will include notifying all possible affected parties down to Hannah Montana Linux devs if any still exist. Any strategy that assumes that the rest of the world is functional or makes you personally responsible for fixing all of it is equally broken but there is a reasonable middle ground and sending a few more emails lies within it
- dwedge 5mo ago
  When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look
  - dgellow 5mo ago
    The worst thing would be to exploit or sell it for profit. Instead of that, publicizing the exploit is closer to neutral–good in my books, that did trigger a really quick reaction from the different actors to patch their kernels and systems
    - ori_b 5mo ago
      Imagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.
      - x4132 5mo ago
        to which distros? how do you ensure fairness? Do you report this to the maintainer of Red Star OS (north korea)? The kernel security team was given the heads up a month ago. At that point it is their decision.
        manquer 5mo ago
        There are channels like the distro security mailing list https://oss-security.openwall.org/wiki/mailing-lists/distros https://oss-security.openwall.org/wiki/mailing-lists/distros for this purpose.
- egonschiele 5mo ago
  Why don't all these distro maintainers add their own back doors, and mine crypto off our machines without our knowledge? Surely, there is some legal fine print they can add that would let them do that. There is very little incentive for them to maintain these systems, given how thankless and underpaid the work is.
  - hsbauauvhabzb 5mo ago
    Most distros are maintained by commercial companies.
- bossyTeacher 5mo ago
  > expecting people to always do the right thing is fantasy level thinking. Most people in tech think like the techie in this comic strip. https://xkcd.com/538/ https://xkcd.com/538/
zamalek 5mo ago
The disclosure was more about marketing than security. From the disclosure page: > 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.
- esseph 5mo ago
  Your advertising for them on HN would help them too, I bet.
  - jasonmp85 5mo ago
    Does it? Now that I see their name again in this context they're blacklisted for life.
    - CSSer 5mo ago
      Yes, exactly. Name and shame.
    - true_religion 5mo ago
      Same. I did not know who they were, but now they have been named and shamed. Not every publicity is good.
      - Scharkenberg 5mo ago
        It is the opposite for me. I did not know who they are and now I have a positive opinion of them.
    - selectively 5mo ago
      Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.
      - 5mo ago
deng 5mo ago
> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Yes, this was clearly a marketing stunt to promote Xint code. I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.
- deleted 5mo ago
  [deleted]
- psifertex 5mo ago
  I doubt it will and I hope it doesn't. External security research happens for one of only a few reasons typically: 1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.
akerl_ 5mo ago
Who knows how many attackers had found this vulnerability and had already been using it prior to this research finding it?
- Quarrelsome 5mo ago
  well now everyone does, so the irresponsible disclosure makes it significantly worse.
  - akerl_ 5mo ago
    It’s your opinion that it’s irresponsible and that it makes something worse.
    - Quarrelsome 5mo ago
      and its your opinion that it doesn't. Shall we continue stating the obvious? We are communicating using glyphs. This language is English. We are on Hacker News. This branch of the conversation is extremely unproductive.
      - akerl_ 5mo ago
        I asked a question and you replied with a statement. Your statement didn’t frame itself as an opinion but as fact. The hilarious bit is that the idea that they needed to coordinate is clearly broken even in just this example. They did give prior notice to the Linux developers, who issued a patch. And they’re still getting raked over the coals in this comment page by armchair quarterbacks who have decided they needed to coordinate with specific distros. If they’d coordinated with those distros, somebody would have a pet distro that didn’t make the cut and they’d be pissed about that. There are risks no matter how they do it, and there will be people who are pissed no matter how they do it. Security researchers don’t owe anybody a specific methodology.
        Quarrelsome 5mo ago
        you seemed to suggest with your initial statement that any disclosure was acceptable as people would have been using the exploit prior to the disclosure. I don't think that's a strong argument given now the initial people who were using the exploit prior to disclosure are now joined by people who have learned of the exploit as a consequence of the disclosure happening before all the distribtions were ready. So I feel like the argument reduces into "why is it a problem that now anyone could exploit it, if some people were exploiting it already". Which imho isn't a sensible argument because the issue is clearly the amount of people capable of using the exploit for nefarious purposes, which has increased.
999900000999 5mo ago
Counterpoint. End users have a right to mitigate this issue on their systems. It is a really really bad look for Linux, puts a bit of water on all hype around switching from Windows.
- jasonmp85 5mo ago
  [dead]
- roxolotl 5mo ago
  It does? The disclosure even says the concern for single user systems is very low. If someone has access to your single user system, remote or otherwise, you’ve already lost on the sort of device people would be switching from windows to Linux on.
  - 999900000999 5mo ago
    Someone like an AI coding agent perhaps ? This is the type of thing Prompt injection was made for. No OS is perfect. The awkward rollout for this bug fix is proof of that.
    - Filligree 5mo ago
      Root access does not typically add anything interesting, for a desktop system. All the valuable stuff is already owned by the single user.
  - m3047 5mo ago
    > The disclosure even says the concern for single user systems is very low. For single user systems (not rigorously defined, I presume it's the intersection of our two definitions which we might be talking about) the nature of the exploit is local privilege escalation, of which there could be many possible, and many mitigations / countermeasures against. This could have suddenly appeared from the ether of "unknown unknowns" for some people. Those people farther up the food chain still potentially have service accounts, maybe even user accounts for some purposes, perhaps "trusted" services which deliver them code which they deserialize and run once. (Have a pickle.) severity * impact * likelihood Not everyone looking to migrate from Windows 95 plans to run everything as root afterward. On the copy.fail site: echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true Not everybody needs or wants to wait for their distro, or plans to patch their IC firmware when a config change will do.
lifis 5mo ago
The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations succeeded (https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...)
- dawnerd 5mo ago
  A LOT of websites are tenants on WHM/CPanel hosts. Not to mention how many agencies use it for their clients Wordpress sites.
  - deleted 5mo ago
    [deleted]
  - hsbauauvhabzb 5mo ago
    They built it wrong.
- watermelon0 5mo ago
  I'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.
  - staticassertion 5mo ago
    In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word. LPEs on Linux are obscenely commonplace.
- morpheuskafka 5mo ago
  I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.
johnbarron 5mo ago
>> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Maybe a decade of corporations with revenue in the billions, paying peanuts and coffee money, for critical vulnerability disclosures made it....
Lammy 5mo ago
> It was extremely irresponsible As a user and admin I disagree. Makes one appreciate what a masterful bit of lexical-engineering “Responsible” Disclosure is, kinda like “Secure” (from me, not forme) Boot — “Responsible” Disclosure is 100% about reputation-management for the various corporation/foundation middleman entities sitting between me and my computer. Those groups don't care that my individual computer is vulnerable but about nobody being able to say “RHEL is vulnerable” or “Ubuntu is vulnerable”. The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk than to be surprised by the fix and hope nothing bad happened in that meantime. Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.
- eschaton 5mo ago
  “The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.” That’s what you’re saying here.
  - tptacek 5mo ago
    They're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.
    - 0x0 5mo ago
      The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids. https://x.com/spendergrsec/status/2049566830771970483 https://x.com/spendergrsec/status/2049566830771970483 https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/ https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time? I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.
tptacek 5mo ago
Without taking a position on the disclosure mechanics: any hosting provider hacked with this was already playing to lose. It is not OK to run competing untrusted tenant workloads under a single shared kernel. Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity.
- jcalvinowens 5mo ago
  > Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity. I absolutely 100% agree with this and I'm glad to see somebody saying it. Any system that is one LPE away from being compromised is already insecure.
- deleted 5mo ago
  [deleted]
deleted 5mo ago
[deleted]
mschuster91 5mo ago
> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. Maybe it is irresponsible how little attention we pay to software security. Maybe, software developers of all kind should spend an entire year not developing any features at all, but fix all the tech debt of 30 years instead. Yes, that sounds revolutionary, but I do not see an alternative in an age where all you need to find kernel bugs of this scale with AI agents.
bombcar 5mo ago
The title on this post was changed to imply that only the Gentoo developer was left out - which I could believe.
- bombcar 5mo ago
  And now it was changed back. I'm goin' insane.
  - Sophira 5mo ago
    And now it's changed to be a generic "For Linux kernel vulnerabilities" rather than specifically about Copy-Fail.
IshKebab 5mo ago
> Who knows how many shared hosting providers were hacked with this. None? Because nobody* does hosting using Linux users as a security boundary. It's not the 90s. * Standard HN disclaimer for people that think that some retro shell box with 10 users disproves "nobody": nobody does not literally mean exactly 0 people in this context.
john_strinlai 5mo ago
i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.html https://projectzero.google/vulnerability-disclosure-policy.h...) the real problem is: >It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. what should be happening, as you allude to, is a communication channel between the kernel security team and distribution maintainers. they are in a much better position to coordinate and communicate with the maintainers than random reporters are. the minute the patch landed in the kernel, a notification should have gone out from the kernel team to a curated list of distro security folk that communicated the importance of the patch, and that the public disclosure would be in 30 days.
- ori_b 5mo ago
  If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.
  - john_strinlai 5mo ago
    its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.
CodesInChaos 5mo ago
> Who knows how many shared hosting providers were hacked with this. I'd consider a shared hoster which allows users to run their own (native) code and doesn't use VMs for tenant isolation extremely irresponsible in 2026.
- saysjonathan 5mo ago
  This is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively
  - CodesInChaos 5mo ago
    Modern VMs, e.g. using Firecracker shouldn't be that expensive. I think it's crazy that Kubernetes doesn't use a VM per pod model, especially since it was started by security conscious google.
PunchyHamster 5mo ago
At least thankfully workaround is one line in a file.
ebiederm 5mo ago
The notification happen when the fix was shipped. That people would prefer to been spoon fed only serious security issues is understandable, but not realistic. A large percentage of kernel fixes have the potential to be similarly bad. For some the potential isn't even realized until after the fix has shipped. Ever stable release GregKH says you must upgrade now, because there is something security relevant in there. This happens at least once a week. As for shared hosting providers it is my sense that there is always at least one local privilege escalation available to miscreants. Making shared hosting only safe if there is a certain amount of trust. I remember bugs that were similarly bad from my university days 30+ years ago. Has anything substantially changed?
TacticalCoder 5mo ago
> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. It's a total arsehole'y move to not share with open-source projects (like Debian) but for commercial vendors like Microsoft I don't give a crap. Now let's not get carried away either: that's a privilege escalation, so it already requires access to a local account. We're not exactly in Jia Tan "I backdoor every SSH out there if your Linux distro is using systemd" territory either.
bethekidyouwant 5mo ago
“Shared hosting providers” These haven’t been a thing since VMs … basically for this reason. There’s always a local privilege exploit.
- sgbeal 5mo ago
  > “Shared hosting providers” These haven’t been a thing since VMs That is unfortunately not true. i left my last one only a few years ago and they're still going strong without me.
bitexploder 5mo ago
There is no such thing as irresponsible disclosure. Thanks though.
krzyk 5mo ago
There are so many distributions that it is not possible to notify each one, unless there is some single distribution list for all. And if you disclose to just a handful, why ignore the rest?
porridgeraisin 5mo ago
Fundamentally. The disclosure is private. Meaning neither the commit messages nor any public info can leak too much information about the bug. It's usually kept rather discrete. It is impractical for the kernel to broadcast to all its users privately. Meaning that either a) distro maintainers should be privy to it, but where does this end?[1] or b) we have the current situation [1] probably the top 5 distros security teams can just be copied into the private mail. Maybe the kernel security private list can forward the emails to them as well. Problem is, every other type of communication between distros and kernel is implicit. In commit messages, patches and release notes. So it's an exceptional case. BTW, with LLMs there's a new issue. It is now cheap to scan the kernel commit log maybe in _next and ask it to identify what could be a patch for a private disclosure. And then immediately RE the patch and exploit it on deployed kernels.
ExoticPearTree 5mo ago
> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. I disagree. Exploits should pe published as soon as they are written and found vulnerabilities to have as much details as possible, because if the researchers cannot write an exploit, someone else could. - this has the advantage of forcing upgrades as soon as possible. No more “we need to see and schedule patching” - publishing it as soon as possible makes everyne aware of the threat - it is a learning experience for everyone - “responsible disclosure” was invented by lazy companies that have zero interest in fixing a problem quickly
franktankbank 5mo ago
> but apparently it's the responsibility of whoever finds the vulnerability Aka a white hat professional which should be a prized function richly rewarded. Do you really want these things to be calcified into a government function?

shimman 5mo ago

Expecting people to do the right thing is a fundamental issue here. Why would you ever expect for all of vulnerabilities to be disclosed privately? There's very little actual incentive to do this. I'm honestly unaware of what systems could be put in place to prevent this but expecting people to always do the right thing is fantasy level thinking. I mean I bet the disclosers thought they were doing the right thing, hence why it's a bad thing to rely on. edit: spelling/grammer.

baggy_trough 5mo ago
Why wouldn't the linux security team notify the main linux distributions?
- deleted 5mo ago
  [deleted]
- bonzini 5mo ago
  Partly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't. Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).
  - baggy_trough 5mo ago
    Seems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).
    - seanhunter 5mo ago
      You know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.
      - baggy_trough 5mo ago
        Thank you very much, seanhunter. You hit the nail on the head there.
        bonzini 5mo ago
        Not really, because they made Linux a CNA specifically to own the process and distort it the way they want it to be.
  - staticassertion 5mo ago
    This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
    - bonzini 5mo ago
      > they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.
- bluepuma77 5mo ago
  Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining?
  - baggy_trough 5mo ago
    Isn't there already a distro security list for this purpose?
    - staticassertion 5mo ago
      Yes.
  - throw0101a 5mo ago
    > Well, how do you define main Linux distros? Isn’t the next smaller one not receiving the info always complaining? For a first approximation: Ubuntu, Debian, RHEL(-derived) to begin with, and SuSE which is in EU/server space (AIUI): * https://commandlinux.com/statistics/most-popular-linux-distributions-market-share/ https://commandlinux.com/statistics/most-popular-linux-distr... * https://commandlinux.com/statistics/linux-server-market-share/ https://commandlinux.com/statistics/linux-server-market-shar... Seems like Gentoo, Arch, Mint, and Slackware could also be as well: * https://distrowatch.com/dwres.php?resource=major https://distrowatch.com/dwres.php?resource=major U/Deb/RHEL are 'upstream' of a lot of other projects, and fixes would trickle down to Rocky, Alma, etc. Perhaps VM OS in cloud (AWS, Azure) could be a usage gauge as well.
- shimman 5mo ago
  Because one of them might have an incentive to not do so. In this case it's because they want to advertise their own company.
- staticassertion 5mo ago
  Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.
  - baggy_trough 5mo ago
    That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.
    - staticassertion 5mo ago
      I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?
      - baggy_trough 5mo ago
        What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?
        staticassertion 5mo ago
        Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.
        baggy_trough 5mo ago
        If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?
holowoodman 5mo ago
I can accept (and welcome) disclosure before there are patches. But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal. And no, the proposed mitigations don't help with half of the distributions out there...
- semiquaver 5mo ago
  Patches were available for nearly a month.
  - ori_b 5mo ago
    Basic care would involve making sure the patches had made it into the wild before ending the embargo, and nagging the relevant parties if not. Edit: As of this writing, most distros including Redhat, Fedora, Debian Stable, do not have patches available in the package repos, though they're being actively worked on.
    - semiquaver 5mo ago
      “Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready?
      - ori_b 5mo ago
        Patches are still in the process of landing in most major distros as of the time of this writing. Most users are not able to get an update through their distro's packaging mechanisms.
      - SoftTalker 5mo ago
        It's a local vulnerability at least. How many people do you let log in to your router? With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that? Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway...
skywhopper 5mo ago
I think it’s reasonable to expect folks in the security community who go to the trouble of creating a website detailing security vulnerabilities in specific listed software to pre-notify the security teams of that software. The CopyFail website calls out Ubuntu and Red Hat specifically, but apparently the author of the site did not inform them of the issue? But even if you think making unethical decisions in personal self interest is something no one should be criticized for, surely the Linux kernel team ought to have some process for notifying the top distributions of an upcoming LPE, just out of practicality.
- semiquaver 5mo ago
  In what sense do you believe that the reporter did not notify the security team of the relevant software? The vulnerability is in the kernel. Reporter responsibly disclosed using the kernel’s security report mechanism and waited until a patch was ready. Distros are downstream of kernel, that doesn’t entitle them to expect to be contacted directly by every security reporter. That’s not on them. Distros that are big enough should be plugged into the linux security team for notifications. Security researchers cannot be held responsible for broken lines of communication within the org charts of projects that they study. They’re providing a valuable public service already, how much more do you want?
  - ragall 5mo ago
    > that doesn’t entitle them to expect to be contacted directly by the reporter Yes it does. That's how it's always been done and distros can ship a fix well before it ends up in a kernel release.
  - michaelmrose 5mo ago
    It is suggested that they out of an abundance of caution and 5 or 6 emails. If this is entirely to much to expect we can always help them by mandating that they spend 6 figures annually meeting a much more robust set of requirements that will include notifying all possible affected parties down to Hannah Montana Linux devs if any still exist. Any strategy that assumes that the rest of the world is functional or makes you personally responsible for fixing all of it is equally broken but there is a reasonable middle ground and sending a few more emails lies within it
dwedge 5mo ago
When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look
- dgellow 5mo ago
  The worst thing would be to exploit or sell it for profit. Instead of that, publicizing the exploit is closer to neutral–good in my books, that did trigger a really quick reaction from the different actors to patch their kernels and systems
  - ori_b 5mo ago
    Imagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.
    - x4132 5mo ago
      to which distros? how do you ensure fairness? Do you report this to the maintainer of Red Star OS (north korea)? The kernel security team was given the heads up a month ago. At that point it is their decision.
      - manquer 5mo ago
        There are channels like the distro security mailing list https://oss-security.openwall.org/wiki/mailing-lists/distros https://oss-security.openwall.org/wiki/mailing-lists/distros for this purpose.
egonschiele 5mo ago
Why don't all these distro maintainers add their own back doors, and mine crypto off our machines without our knowledge? Surely, there is some legal fine print they can add that would let them do that. There is very little incentive for them to maintain these systems, given how thankless and underpaid the work is.
- hsbauauvhabzb 5mo ago
  Most distros are maintained by commercial companies.
bossyTeacher 5mo ago
> expecting people to always do the right thing is fantasy level thinking. Most people in tech think like the techie in this comic strip. https://xkcd.com/538/ https://xkcd.com/538/

zamalek 5mo ago

The disclosure was more about marketing than security. From the disclosure page: > 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.

esseph 5mo ago
Your advertising for them on HN would help them too, I bet.
- jasonmp85 5mo ago
  Does it? Now that I see their name again in this context they're blacklisted for life.
  - CSSer 5mo ago
    Yes, exactly. Name and shame.
  - true_religion 5mo ago
    Same. I did not know who they were, but now they have been named and shamed. Not every publicity is good.
    - Scharkenberg 5mo ago
      It is the opposite for me. I did not know who they are and now I have a positive opinion of them.
  - selectively 5mo ago
    Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit. Just fyi. Be glad it was disclosed at all. Be glad a patch was available prior to release.
    - 5mo ago

deng 5mo ago

> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Yes, this was clearly a marketing stunt to promote Xint code. I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.

deleted 5mo ago
[deleted]
psifertex 5mo ago
I doubt it will and I hope it doesn't. External security research happens for one of only a few reasons typically: 1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.

akerl_ 5mo ago

Who knows how many attackers had found this vulnerability and had already been using it prior to this research finding it?

Quarrelsome 5mo ago
well now everyone does, so the irresponsible disclosure makes it significantly worse.
- akerl_ 5mo ago
  It’s your opinion that it’s irresponsible and that it makes something worse.
  - Quarrelsome 5mo ago
    and its your opinion that it doesn't. Shall we continue stating the obvious? We are communicating using glyphs. This language is English. We are on Hacker News. This branch of the conversation is extremely unproductive.
    - akerl_ 5mo ago
      I asked a question and you replied with a statement. Your statement didn’t frame itself as an opinion but as fact. The hilarious bit is that the idea that they needed to coordinate is clearly broken even in just this example. They did give prior notice to the Linux developers, who issued a patch. And they’re still getting raked over the coals in this comment page by armchair quarterbacks who have decided they needed to coordinate with specific distros. If they’d coordinated with those distros, somebody would have a pet distro that didn’t make the cut and they’d be pissed about that. There are risks no matter how they do it, and there will be people who are pissed no matter how they do it. Security researchers don’t owe anybody a specific methodology.
      - Quarrelsome 5mo ago
        you seemed to suggest with your initial statement that any disclosure was acceptable as people would have been using the exploit prior to the disclosure. I don't think that's a strong argument given now the initial people who were using the exploit prior to disclosure are now joined by people who have learned of the exploit as a consequence of the disclosure happening before all the distribtions were ready. So I feel like the argument reduces into "why is it a problem that now anyone could exploit it, if some people were exploiting it already". Which imho isn't a sensible argument because the issue is clearly the amount of people capable of using the exploit for nefarious purposes, which has increased.

999900000999 5mo ago

Counterpoint. End users have a right to mitigate this issue on their systems. It is a really really bad look for Linux, puts a bit of water on all hype around switching from Windows.

jasonmp85 5mo ago
[dead]
roxolotl 5mo ago
It does? The disclosure even says the concern for single user systems is very low. If someone has access to your single user system, remote or otherwise, you’ve already lost on the sort of device people would be switching from windows to Linux on.
- 999900000999 5mo ago
  Someone like an AI coding agent perhaps ? This is the type of thing Prompt injection was made for. No OS is perfect. The awkward rollout for this bug fix is proof of that.
  - Filligree 5mo ago
    Root access does not typically add anything interesting, for a desktop system. All the valuable stuff is already owned by the single user.
- m3047 5mo ago
  > The disclosure even says the concern for single user systems is very low. For single user systems (not rigorously defined, I presume it's the intersection of our two definitions which we might be talking about) the nature of the exploit is local privilege escalation, of which there could be many possible, and many mitigations / countermeasures against. This could have suddenly appeared from the ether of "unknown unknowns" for some people. Those people farther up the food chain still potentially have service accounts, maybe even user accounts for some purposes, perhaps "trusted" services which deliver them code which they deserialize and run once. (Have a pickle.) severity * impact * likelihood Not everyone looking to migrate from Windows 95 plans to run everything as root afterward. On the copy.fail site: echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true Not everybody needs or wants to wait for their distro, or plans to patch their IC firmware when a config change will do.

lifis 5mo ago

The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations succeeded (https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...)

dawnerd 5mo ago
A LOT of websites are tenants on WHM/CPanel hosts. Not to mention how many agencies use it for their clients Wordpress sites.
- deleted 5mo ago
  [deleted]
- hsbauauvhabzb 5mo ago
  They built it wrong.
watermelon0 5mo ago
I'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.
- staticassertion 5mo ago
  In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word. LPEs on Linux are obscenely commonplace.
morpheuskafka 5mo ago
I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.

johnbarron 5mo ago

>> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Maybe a decade of corporations with revenue in the billions, paying peanuts and coffee money, for critical vulnerability disclosures made it....

Lammy 5mo ago

> It was extremely irresponsible As a user and admin I disagree. Makes one appreciate what a masterful bit of lexical-engineering “Responsible” Disclosure is, kinda like “Secure” (from me, not forme) Boot — “Responsible” Disclosure is 100% about reputation-management for the various corporation/foundation middleman entities sitting between me and my computer. Those groups don't care that my individual computer is vulnerable but about nobody being able to say “RHEL is vulnerable” or “Ubuntu is vulnerable”. The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk than to be surprised by the fix and hope nothing bad happened in that meantime. Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.

eschaton 5mo ago
“The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.” That’s what you’re saying here.
- tptacek 5mo ago
  They're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.
  - 0x0 5mo ago
    The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids. https://x.com/spendergrsec/status/2049566830771970483 https://x.com/spendergrsec/status/2049566830771970483 https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/ https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time? I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.

tptacek 5mo ago

Without taking a position on the disclosure mechanics: any hosting provider hacked with this was already playing to lose. It is not OK to run competing untrusted tenant workloads under a single shared kernel. Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity.

jcalvinowens 5mo ago
> Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity. I absolutely 100% agree with this and I'm glad to see somebody saying it. Any system that is one LPE away from being compromised is already insecure.
deleted 5mo ago
[deleted]

deleted 5mo ago

[deleted]

mschuster91 5mo ago

> Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. Maybe it is irresponsible how little attention we pay to software security. Maybe, software developers of all kind should spend an entire year not developing any features at all, but fix all the tech debt of 30 years instead. Yes, that sounds revolutionary, but I do not see an alternative in an age where all you need to find kernel bugs of this scale with AI agents.

bombcar 5mo ago

The title on this post was changed to imply that only the Gentoo developer was left out - which I could believe.

bombcar 5mo ago
And now it was changed back. I'm goin' insane.
- Sophira 5mo ago
  And now it's changed to be a generic "For Linux kernel vulnerabilities" rather than specifically about Copy-Fail.

IshKebab 5mo ago

> Who knows how many shared hosting providers were hacked with this. None? Because nobody* does hosting using Linux users as a security boundary. It's not the 90s. * Standard HN disclaimer for people that think that some retro shell box with 10 users disproves "nobody": nobody does not literally mean exactly 0 people in this context.

john_strinlai 5mo ago

i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.html https://projectzero.google/vulnerability-disclosure-policy.h...) the real problem is: >It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in. what should be happening, as you allude to, is a communication channel between the kernel security team and distribution maintainers. they are in a much better position to coordinate and communicate with the maintainers than random reporters are. the minute the patch landed in the kernel, a notification should have gone out from the kernel team to a curated list of distro security folk that communicated the importance of the patch, and that the public disclosure would be in 30 days.

ori_b 5mo ago
If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.
- john_strinlai 5mo ago
  its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.

CodesInChaos 5mo ago

> Who knows how many shared hosting providers were hacked with this. I'd consider a shared hoster which allows users to run their own (native) code and doesn't use VMs for tenant isolation extremely irresponsible in 2026.

saysjonathan 5mo ago
This is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively
- CodesInChaos 5mo ago
  Modern VMs, e.g. using Firecracker shouldn't be that expensive. I think it's crazy that Kubernetes doesn't use a VM per pod model, especially since it was started by security conscious google.

PunchyHamster 5mo ago

At least thankfully workaround is one line in a file.

ebiederm 5mo ago

The notification happen when the fix was shipped. That people would prefer to been spoon fed only serious security issues is understandable, but not realistic. A large percentage of kernel fixes have the potential to be similarly bad. For some the potential isn't even realized until after the fix has shipped. Ever stable release GregKH says you must upgrade now, because there is something security relevant in there. This happens at least once a week. As for shared hosting providers it is my sense that there is always at least one local privilege escalation available to miscreants. Making shared hosting only safe if there is a certain amount of trust. I remember bugs that were similarly bad from my university days 30+ years ago. Has anything substantially changed?

TacticalCoder 5mo ago

> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. It's a total arsehole'y move to not share with open-source projects (like Debian) but for commercial vendors like Microsoft I don't give a crap. Now let's not get carried away either: that's a privilege escalation, so it already requires access to a local account. We're not exactly in Jia Tan "I backdoor every SSH out there if your Linux distro is using systemd" territory either.

bethekidyouwant 5mo ago

“Shared hosting providers” These haven’t been a thing since VMs … basically for this reason. There’s always a local privilege exploit.

sgbeal 5mo ago
> “Shared hosting providers” These haven’t been a thing since VMs That is unfortunately not true. i left my last one only a few years ago and they're still going strong without me.

bitexploder 5mo ago

There is no such thing as irresponsible disclosure. Thanks though.

krzyk 5mo ago

There are so many distributions that it is not possible to notify each one, unless there is some single distribution list for all. And if you disclose to just a handful, why ignore the rest?

porridgeraisin 5mo ago

Fundamentally. The disclosure is private. Meaning neither the commit messages nor any public info can leak too much information about the bug. It's usually kept rather discrete. It is impractical for the kernel to broadcast to all its users privately. Meaning that either a) distro maintainers should be privy to it, but where does this end?[1] or b) we have the current situation [1] probably the top 5 distros security teams can just be copied into the private mail. Maybe the kernel security private list can forward the emails to them as well. Problem is, every other type of communication between distros and kernel is implicit. In commit messages, patches and release notes. So it's an exceptional case. BTW, with LLMs there's a new issue. It is now cheap to scan the kernel commit log maybe in _next and ask it to identify what could be a patch for a private disclosure. And then immediately RE the patch and exploit it on deployed kernels.

ExoticPearTree 5mo ago

> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. I disagree. Exploits should pe published as soon as they are written and found vulnerabilities to have as much details as possible, because if the researchers cannot write an exploit, someone else could. - this has the advantage of forcing upgrades as soon as possible. No more “we need to see and schedule patching” - publishing it as soon as possible makes everyne aware of the threat - it is a learning experience for everyone - “responsible disclosure” was invented by lazy companies that have zero interest in fixing a problem quickly

franktankbank 5mo ago

> but apparently it's the responsibility of whoever finds the vulnerability Aka a white hat professional which should be a prized function richly rewarded. Do you really want these things to be calcified into a government function?