This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously.
At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is extremely difficult, both because of the number of people involved and because fixing the vulnerability sometimes requires advance changes to other public components.
On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial.
For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.
Maybe I don't understand the threat model here: what kind of public-facing services are you running that are simultaneously (1) not already access-limited, and (2) not load-bearing such that they need to be public-facing?
(And to be clear: I see the benefit here. But I'm talking principally about open source projects, not the vendors you're presumably paying.)
There really isn't a great solution here. The notice that a vulnerability has been discovered puts even more pressure on the fix to be deployed as close to instantly as possible, throughout the entire supply chain.
Why is this? Especially for smaller or more stable open-source projects, the number of commits in a 90-day period that have the possibility to be security-relevant are likely to be quite low, perhaps as low as single digits. So the specific commit that fixes the reported security issue is highly likely to be identified immediately, and now there's a race to develop and use an exploit.
As one example, a stable project that's been the target of significant security hardening and analysis is the libpng decoder. Over the past 3 months (May 1 - Jul 29), its main branch has seen 41 total commits. Of those, at least 25 were non-code changes, involving documentation updates, release engineering activities, and build system / cross-platform support. If Project Zero had announced a vulnerability in this project on May 1 with a disclosure embargo of today, there would be at most 16 commits to inspect over 3 months to find the bug. That's not a lot of work for a dedicated team.
So now, do we delay publishing security fixes to public repos and try and maintain private infrastructure and testing for all of this? And then try and get a release made, propagated to multiple layers of downstream vendors, have them make releases, etc... all within a day or two? That's pretty hard, just organizationally. No great answers here.
This seems like a good move. I do hope that slow moving consumers of the software in question can start anticipating an upcoming release and construct remediation plans instead of doing that after the release.
I love it; it's a big-company reformulation of the classic vulnerability researcher's "reporting transparency" process: post "Found a nasty vuln in XYZ: 6f0c848159d46104fba17e02906f52aef460ee17d1962f5ea05d2478600fce8a" (the SHA2 hash of a report artifact confirming the vuln).
> This data will make it easier for researchers and the public to track how long it takes for a fix to travel from the initial report, all the way to a user's device (which is especially important if the fix never arrives!)
This paragraph is very confusing: What data is meant by "this data"? If they mean the announcement of "there's something", isn't the timeline of disclosure made public already under current reporting policy once everything has been opened up?
In other words, the date of initial report is not new data? Sure the delay is reduced, but it's not new at all in contrast to what the paragraph suggests.
I find the stated goal of alerting downstream a bit odd. Most downstreams scan upstream web pages for releases and automatically open an issue after a new release.
Project zero could also open a mailing list for trusted downstreams and publish the newly found announcements there.
The real goal seems to be to increase pressure on upstream, which in our modern times ranks lowest on the open source ladder: Below distributors, corporations, security pundits (some of whom do not write software themselves and have never been upstream for anything) and demanding users.
Not sure what is the measurable metric here, and what will be considered a success in this trial period.
Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline.
It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are still working to fix it. The pressure from these companies will probably shut this policy change down.
Also, will this policy apply also to Google's own products?
The measure would probably be whether any of the reports led to examples of downstreams either syncing prior to release via security sharing they didn't already have established or any projects preparing to sync out of normal schedule ahead of time, regardless of if that's a small or large magnitude of change. How companies would prefer the public hear about a vulnerability has always been the lowest concern out of disclosures so I don't expect it to bring anything new here.
Google's products represent 3/6 of the initial vulnerabilities following this new reporting policy in the linked reporting page.
It is indeed a complex problem. But is Google now killing FOSS slowly? IMHO there is far too much emphasis on Foss security and far too little on closed sourced hardware, firmware and software. Too much blame and pressure will not solve the complex problems as stated in the blog.
Shoring up the security of FOSS is not "killing FOSS slowly".
Closed source software doesn't get to benefit from the goodwill of the open source software community, which includes independent security researchers as well as orgs like P0.
I guess our disagreement can be distilled down to one question:
Why would an emphasis on closed source products help FOSS, and why would an emphasis on FOSS help closed source?
Because this seems backwards to me. Maybe it makes sense in public relations where vibes are more important than substance and nobody thinks for more than 100 milliseconds?
It depends on the maintainer, some of them have indeed found themselves unwilling to continue their work in part because of Project Zero.
> I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again. It's even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.
I know it's hard to believe this given the circumstances --- that maintainer has a very good reason for stepping back, absolutely no shade to give there --- but GPZ is doing a service for these projects. The vulnerabilities they find are there whether or not Google or anybody else steps up on the implementation side. They are simple facts of the software, and it's difficult, expensive, and important to uncover those facts.
Both can be true at the same time, I think. It’s true that the vulnerabilities exist regardless of whether anyone’s reporting them, and that it’s better to know about them than not. It’s also true that almost any course of action that makes a project effectively stop existing does it a disservice, and that includes vulnerability reporting.
I’ve not really made up my mind about what happened with libxml2, to be clear. Perhaps in this world some projects really are vulnerable enough that they deserve to die. But as we see, this can entail essentially punishing people who decide to take up e.g. parsers as a hobby. And not doing that is something I feel I value higher than even security of the software ecosystem as a whole.
Some open source software becomes critical infrastructure for a large part of the Internet, and that comes with a lot of responsibility that the maintainer didn't necessarily want to sign up for. Especially when it's unpaid labor with the demands of a large tech company hammering down on them.
How can we better support the people that run these projects? How can we take pressure off of them if they don't want it?
There isn't a one-size-fits-all solution here, I don't think. But I'm sure some combination of fund open source development and fork load-bearing projects that do not wish to be encumbered is going to be necessary for a lot of the community.
If Google is adopting this, maybe rachelbythebay's vagueposting was ahead of the curve?
I jest; the vagueposting led to uninformed speculation, panic, reddit levels of baseless accusation, and harassment of the developers: https://news.ycombinator.com/item?id=43477057
I hope Google's experiment doesn't turn out the same.
> uninformed speculation, panic, reddit levels of baseless accusation, and harassment of the developers
To be fair, it seems like the only way of avoiding something like that is never saying anything publicly. The crowds of the internet eagerly jump into any drama, vague or not, and balloon it regardless.
I remember when heartbleed was the big thing. There were many people digging into the person who committed the bug. Looking for where they lived, worked, and traveled. Many people were so desperate to find something to prove he was a spy.
If you google his name, 80% of the results are articles about how he denying doing that on purpose.
Resurrecting a 4 month old issue that evaporated in a day or two seems like poor form to me.
Also I believe most of the responsibility for the negative behavior should be assigned to those actually engaging in it, not the initial post. I understand others reasonably disagree (notably about the accusation and harrassment).
Tbh, it sounds like you might have been personally affected? At any rate, I certainly don't condone a mob mentality.
I bring it up because of the unmissable parallels. Google are trialling a policy to see what will happen, but this incident shows already what can happen.
RbtB is a trusted blog by the HN crowd, and her vaguepost unexpectedly whipped up hysteria. It was only quelled by a post with more details the next day. Google Project Zero has enormous levels of trust, intends to vaguepost as policy, and not post more details the next day to satisfy the mob.
It does not look good for volunteer maintainers to suffer an entire world of talentless clowns rifling through every commit and asking "is this the bug Project Zero found?"
I think it's a fair illustration of what irresponsible disclosure looks like.
I expect Project Zero will be monitoring carefully; for all their good intentions, this policy trial has the potential to go as badly wrong as the atop disclosure did, for everything they announce.
You can reasonably expect massive, worldwide scrutiny in anything P0 announces has a vulnerability in it without also disclosing the vulnerability, and this extra attention has the potential to overwhelm FOSS maintainers, even if they have fixed the vulnerability and are waiting for coordinated disclosure.
Did you not see the panicked, stupid, wrong mob that the vaguepost whipped up, with your own eyes? It is very easy to whip up a mob: 1) be well regarded and trusted, and 2) post a vague statement about a specific target (e.g. "you might want to stop running atop") where a lot of people will see it. The mob will then form, start speculating, and a pile of them won't be able to help themselves and will start picking over every single thing in the repository. "Is this the bug?" "No." "Is this the bug?" "No." "This contributor is Jia Tan, isn't he?" "No they are not." and so on.
Maintainers always welcome genuine security reports, and especially love a working PoC. But they don't have time to deal with idiots, spammers, shysters and chancers who submit bullshit reports, or ask for hand-holding to submit what will turn out to be bullshit reports, and they definitely don't have time to engage in idle speculation. It wastes their time, and reduces the time they have to look at what could be genuine reports.
Imagine what would happen if Project Zero posted "you might want to stop running ffmpeg" with no further details. That's effectively what's being proposed. A million idiots descend upon the project with "Hey guys I heard Project Zero found a vulnerability in ffmpeg. How exciting! Is it this free(NULL)?"
There is nothing wrong with responsible and coordinated disclosures, even if vendors take liberties, and yes you should set an upper bound for disclosure. But if your policy is "I will disclose to the public that I found a bug in specific software, but not what the bug is", accept that you are likely to unleash chaos, especially if you are a well-regarded and trusted researcher.
We're going round in circles now, so let's just say we will see what happens.
Project Zero seems upbeat, but acknowledges this risk:
> We understand that for some vendors without a downstream ecosystem, this policy may create unwelcome noise and attention
> This is a trial, and we will be closely monitoring its effects.
They don't explicity spell out what they would consider a failure of this policy trial. I think failure would look like the example I have outlined, but at greater scale.
> Given the vagueness, we were curious if Bismuth's bug scanning capabilities could find the bug so we let it rip on the code base. 10 minutes later, we had it. Or at least we had a bug which looked and behaved exactly like Rachel described.
> As soon as we figured this out and had something reproducible we moved to responsibly disclose the issue and we emailed Gerlof at 8pm on the 26th.
> Seeing this bug and how it's triggered, I understand Rachel's initial reaction to write a vague "get rid of it" post without going into detail. [...] That said, the internet loves to run wild with speculation and there's a reason we have the responsible disclosure process. For something that's installed as often as Nvidia GPU drivers, it would be prudent to spend the extra few days and have a controlled disclosure. Posting something like that can start off an arms race to find the bug, and if someone malicious were to reproduce and exploit it first, they get free reign to take over affected systems until it's patched. Yes, sounding the alarm might cause people to uninstall it, but there's plenty of places where it will remain, giving malicious actors incentive to go for it. But with a coordinated disclosure, the arms race never starts, and systems are patched before anyone realizes there was an issue.
There has been nothing on Rachel's blog about this topic since the vaguepost and vaguepost followup.
The CVE (https://www.cve.org/CVERecord?id=CVE-2025-31160) is still incorrect, and there's no indication who requested it. It says that versions "0 - 2.11.0" are affected, this is untrue, because the atopgpud (and support in atop for reading from it) was introduced in version 2.4.0 ("The vulnerability is present since the introduction of 'atopgpud' in atop 2.4.0." per https://www.atoptool.nl/downloadatop.php)
This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously.
At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is extremely difficult, both because of the number of people involved and because fixing the vulnerability sometimes requires advance changes to other public components.
I'm not sure there's a great solution to this.
On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial.
For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.
Maybe I don't understand the threat model here: what kind of public-facing services are you running that are simultaneously (1) not already access-limited, and (2) not load-bearing such that they need to be public-facing?
(And to be clear: I see the benefit here. But I'm talking principally about open source projects, not the vendors you're presumably paying.)
Some companies might be willing to compromise functionality to avoid compromise of their networks.
There's always a usability / functionality vs security tradeoff
Unfortunately I think most of the products you use have 0-days in them, it's just that Project Zero hasn't found them yet.
Unless the 0day is in your firewall.
Fortinet strikes again...
There really isn't a great solution here. The notice that a vulnerability has been discovered puts even more pressure on the fix to be deployed as close to instantly as possible, throughout the entire supply chain.
Why is this? Especially for smaller or more stable open-source projects, the number of commits in a 90-day period that have the possibility to be security-relevant are likely to be quite low, perhaps as low as single digits. So the specific commit that fixes the reported security issue is highly likely to be identified immediately, and now there's a race to develop and use an exploit.
As one example, a stable project that's been the target of significant security hardening and analysis is the libpng decoder. Over the past 3 months (May 1 - Jul 29), its main branch has seen 41 total commits. Of those, at least 25 were non-code changes, involving documentation updates, release engineering activities, and build system / cross-platform support. If Project Zero had announced a vulnerability in this project on May 1 with a disclosure embargo of today, there would be at most 16 commits to inspect over 3 months to find the bug. That's not a lot of work for a dedicated team.
So now, do we delay publishing security fixes to public repos and try and maintain private infrastructure and testing for all of this? And then try and get a release made, propagated to multiple layers of downstream vendors, have them make releases, etc... all within a day or two? That's pretty hard, just organizationally. No great answers here.
This seems like a good move. I do hope that slow moving consumers of the software in question can start anticipating an upcoming release and construct remediation plans instead of doing that after the release.
I love it; it's a big-company reformulation of the classic vulnerability researcher's "reporting transparency" process: post "Found a nasty vuln in XYZ: 6f0c848159d46104fba17e02906f52aef460ee17d1962f5ea05d2478600fce8a" (the SHA2 hash of a report artifact confirming the vuln).
Related links:
- Vulnerability Disclosure FAQ ( https://googleprojectzero.blogspot.com/p/vulnerability-discl... )
- Reporting Transparency ( https://googleprojectzero.blogspot.com/p/reporting-transpare... )
> This data will make it easier for researchers and the public to track how long it takes for a fix to travel from the initial report, all the way to a user's device (which is especially important if the fix never arrives!)
This paragraph is very confusing: What data is meant by "this data"? If they mean the announcement of "there's something", isn't the timeline of disclosure made public already under current reporting policy once everything has been opened up?
In other words, the date of initial report is not new data? Sure the delay is reduced, but it's not new at all in contrast to what the paragraph suggests.
I find the stated goal of alerting downstream a bit odd. Most downstreams scan upstream web pages for releases and automatically open an issue after a new release.
Project zero could also open a mailing list for trusted downstreams and publish the newly found announcements there.
The real goal seems to be to increase pressure on upstream, which in our modern times ranks lowest on the open source ladder: Below distributors, corporations, security pundits (some of whom do not write software themselves and have never been upstream for anything) and demanding users.
Not sure what is the measurable metric here, and what will be considered a success in this trial period.
Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline.
It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are still working to fix it. The pressure from these companies will probably shut this policy change down.
Also, will this policy apply also to Google's own products?
The measure would probably be whether any of the reports led to examples of downstreams either syncing prior to release via security sharing they didn't already have established or any projects preparing to sync out of normal schedule ahead of time, regardless of if that's a small or large magnitude of change. How companies would prefer the public hear about a vulnerability has always been the lowest concern out of disclosures so I don't expect it to bring anything new here.
Google's products represent 3/6 of the initial vulnerabilities following this new reporting policy in the linked reporting page.
It also seems to disclosesinteresting internal products: what is Google Bigwave ?
Seems to be described a bit here https://www.androidauthority.com/how-google-built-tensor-g5-...
It is indeed a complex problem. But is Google now killing FOSS slowly? IMHO there is far too much emphasis on Foss security and far too little on closed sourced hardware, firmware and software. Too much blame and pressure will not solve the complex problems as stated in the blog.
Shoring up the security of FOSS is not "killing FOSS slowly".
Closed source software doesn't get to benefit from the goodwill of the open source software community, which includes independent security researchers as well as orgs like P0.
I guess our disagreement can be distilled down to one question:
Why would an emphasis on closed source products help FOSS, and why would an emphasis on FOSS help closed source?
Because this seems backwards to me. Maybe it makes sense in public relations where vibes are more important than substance and nobody thinks for more than 100 milliseconds?
It depends on the maintainer, some of them have indeed found themselves unwilling to continue their work in part because of Project Zero.
> I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again. It's even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.
https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
I know it's hard to believe this given the circumstances --- that maintainer has a very good reason for stepping back, absolutely no shade to give there --- but GPZ is doing a service for these projects. The vulnerabilities they find are there whether or not Google or anybody else steps up on the implementation side. They are simple facts of the software, and it's difficult, expensive, and important to uncover those facts.
Both can be true at the same time, I think. It’s true that the vulnerabilities exist regardless of whether anyone’s reporting them, and that it’s better to know about them than not. It’s also true that almost any course of action that makes a project effectively stop existing does it a disservice, and that includes vulnerability reporting.
I’ve not really made up my mind about what happened with libxml2, to be clear. Perhaps in this world some projects really are vulnerable enough that they deserve to die. But as we see, this can entail essentially punishing people who decide to take up e.g. parsers as a hobby. And not doing that is something I feel I value higher than even security of the software ecosystem as a whole.
There seems to be a missing component:
Some open source software becomes critical infrastructure for a large part of the Internet, and that comes with a lot of responsibility that the maintainer didn't necessarily want to sign up for. Especially when it's unpaid labor with the demands of a large tech company hammering down on them.
How can we better support the people that run these projects? How can we take pressure off of them if they don't want it?
There isn't a one-size-fits-all solution here, I don't think. But I'm sure some combination of fund open source development and fork load-bearing projects that do not wish to be encumbered is going to be necessary for a lot of the community.
All 6/6 of the initial reports are for proprietary software, most of which seemed to be related to hardware offloads.
If Google is adopting this, maybe rachelbythebay's vagueposting was ahead of the curve?
I jest; the vagueposting led to uninformed speculation, panic, reddit levels of baseless accusation, and harassment of the developers: https://news.ycombinator.com/item?id=43477057
I hope Google's experiment doesn't turn out the same.
> uninformed speculation, panic, reddit levels of baseless accusation, and harassment of the developers
To be fair, it seems like the only way of avoiding something like that is never saying anything publicly. The crowds of the internet eagerly jump into any drama, vague or not, and balloon it regardless.
I remember when heartbleed was the big thing. There were many people digging into the person who committed the bug. Looking for where they lived, worked, and traveled. Many people were so desperate to find something to prove he was a spy.
If you google his name, 80% of the results are articles about how he denying doing that on purpose.
> I jest; the vagueposting led to [...]
Resurrecting a 4 month old issue that evaporated in a day or two seems like poor form to me.
Also I believe most of the responsibility for the negative behavior should be assigned to those actually engaging in it, not the initial post. I understand others reasonably disagree (notably about the accusation and harrassment).
Tbh, it sounds like you might have been personally affected? At any rate, I certainly don't condone a mob mentality.
I stand by what I said at the time: https://news.ycombinator.com/item?id=43492940 - and if you only read one thing, read the harrassment an atop contributor was subjected to by "eslerm": https://github.com/Atoptool/atop/issues/330#issuecomment-275...
I bring it up because of the unmissable parallels. Google are trialling a policy to see what will happen, but this incident shows already what can happen.
RbtB is a trusted blog by the HN crowd, and her vaguepost unexpectedly whipped up hysteria. It was only quelled by a post with more details the next day. Google Project Zero has enormous levels of trust, intends to vaguepost as policy, and not post more details the next day to satisfy the mob.
It does not look good for volunteer maintainers to suffer an entire world of talentless clowns rifling through every commit and asking "is this the bug Project Zero found?"
The "Rachel By The Bay" blog and Google Project Zero are not reasonable comparands in matters of vulnerability disclosure.
I think it's a fair illustration of what irresponsible disclosure looks like.
I expect Project Zero will be monitoring carefully; for all their good intentions, this policy trial has the potential to go as badly wrong as the atop disclosure did, for everything they announce.
You can reasonably expect massive, worldwide scrutiny in anything P0 announces has a vulnerability in it without also disclosing the vulnerability, and this extra attention has the potential to overwhelm FOSS maintainers, even if they have fixed the vulnerability and are waiting for coordinated disclosure.
"Responsible disclosure" is an Orwellian term made up by vendors to coerce vulnerability researchers into working for and on vendor release schedules.
Did you not see the panicked, stupid, wrong mob that the vaguepost whipped up, with your own eyes? It is very easy to whip up a mob: 1) be well regarded and trusted, and 2) post a vague statement about a specific target (e.g. "you might want to stop running atop") where a lot of people will see it. The mob will then form, start speculating, and a pile of them won't be able to help themselves and will start picking over every single thing in the repository. "Is this the bug?" "No." "Is this the bug?" "No." "This contributor is Jia Tan, isn't he?" "No they are not." and so on.
Maintainers always welcome genuine security reports, and especially love a working PoC. But they don't have time to deal with idiots, spammers, shysters and chancers who submit bullshit reports, or ask for hand-holding to submit what will turn out to be bullshit reports, and they definitely don't have time to engage in idle speculation. It wastes their time, and reduces the time they have to look at what could be genuine reports.
Imagine what would happen if Project Zero posted "you might want to stop running ffmpeg" with no further details. That's effectively what's being proposed. A million idiots descend upon the project with "Hey guys I heard Project Zero found a vulnerability in ffmpeg. How exciting! Is it this free(NULL)?"
There is nothing wrong with responsible and coordinated disclosures, even if vendors take liberties, and yes you should set an upper bound for disclosure. But if your policy is "I will disclose to the public that I found a bug in specific software, but not what the bug is", accept that you are likely to unleash chaos, especially if you are a well-regarded and trusted researcher.
Again, simply not interested in comparisons between GPZ and the Rachel By the Bay blog.
We're going round in circles now, so let's just say we will see what happens.
Project Zero seems upbeat, but acknowledges this risk:
> We understand that for some vendors without a downstream ecosystem, this policy may create unwelcome noise and attention
> This is a trial, and we will be closely monitoring its effects.
They don't explicity spell out what they would consider a failure of this policy trial. I think failure would look like the example I have outlined, but at greater scale.
Speaking of, whatever came out of that? I don't see any related updates on that blog.
This was published the day after, with the title "Problems with the heap" but the URL makes the context clear: https://rachelbythebay.com/w/2025/03/26/atop/
Yeah, I meant since that one.
A bug matching the details of the vaguepost was found by a third party with no help from Rachel: https://blog.bismuth.sh/blog/bismuth-found-the-atop-bug
> Given the vagueness, we were curious if Bismuth's bug scanning capabilities could find the bug so we let it rip on the code base. 10 minutes later, we had it. Or at least we had a bug which looked and behaved exactly like Rachel described.
> As soon as we figured this out and had something reproducible we moved to responsibly disclose the issue and we emailed Gerlof at 8pm on the 26th.
> Seeing this bug and how it's triggered, I understand Rachel's initial reaction to write a vague "get rid of it" post without going into detail. [...] That said, the internet loves to run wild with speculation and there's a reason we have the responsible disclosure process. For something that's installed as often as Nvidia GPU drivers, it would be prudent to spend the extra few days and have a controlled disclosure. Posting something like that can start off an arms race to find the bug, and if someone malicious were to reproduce and exploit it first, they get free reign to take over affected systems until it's patched. Yes, sounding the alarm might cause people to uninstall it, but there's plenty of places where it will remain, giving malicious actors incentive to go for it. But with a coordinated disclosure, the arms race never starts, and systems are patched before anyone realizes there was an issue.
The atop maintainer fixed the bug on March 29th, and also changed the behaviour of atop to _not_ connect to its helper daemons by default: https://github.com/Atoptool/atop/commit/542b7f7ac52926ca2721... ... and released it as atop v2.11.1 on April 5th: https://github.com/Atoptool/atop/releases/tag/v2.11.1
There has been nothing on Rachel's blog about this topic since the vaguepost and vaguepost followup.
The CVE (https://www.cve.org/CVERecord?id=CVE-2025-31160) is still incorrect, and there's no indication who requested it. It says that versions "0 - 2.11.0" are affected, this is untrue, because the atopgpud (and support in atop for reading from it) was introduced in version 2.4.0 ("The vulnerability is present since the introduction of 'atopgpud' in atop 2.4.0." per https://www.atoptool.nl/downloadatop.php)