[Kiboneu]

Several issues seem to be getting mixed up.

The first issue being raised is that replacing the configuration file shouldn't count as a vulnerability. Usually I'd agree, but the fact that it causes memory corruption from user input warrants at least a low severity report.

If we can't prove that a vulnerability is exploitable, we have to keep our assumptions minimal. If the memory corruption vuln is provably unexploitable, a future code change could surface it as a plausible exploit primitive. It can also point to a section of code that may have been under-speced, and may serve as an signal to pay more attention at these sections for related bugs. Also, it doesn't seem right to assume that the config files will always be under a privileged directory.

The second issue being discussed iun the mailing list is that it's LLM slop. While the reports do seem to be AI generated, I haven't seen any response about the PoC failing, but maybe there is a significant problem where a lot of PoCs are fake.

So many assumptions. As commander Data may have said today, "the most elementary and valuable statement in security, the beginning of wisdom, is 'I do not know.'"

[procaryote]

Assuming it's AI slop, considering that there's been an upswing of AI slop CVE reports seems pretty reasonable.

However, it doesn't necessarily matter if it's submitted by an incompetent human, a malicious human, or is AI slop. The end effect of wasting time on a non-vulnerability is the same

In a world where generating AI slop is cheap, the standard should probably be that the person submitting a vulnerability needs to prove it is a vulnerability, and probably that they're a person. Having the person receiving it prove it isn't won't scale