On Jan 30, 2026, at 11:37 PM, Amit via austin-group-l at The Open Group <[email protected]> wrote:
> In my opinion, around 90% of all software vulnerabilities can be traced back > to > some input(s) (of some function(s)) not being validated. > > I have researched this and have seen some CVEs and all the CVEs that I > saw, they happened because the inputs were not validated. "Validated" for what definitions of validity? If I look at the list of 2026 vulnerabilities, I see: https://nvd.nist.gov/vuln/detail/CVE-2026-25211 - I read that as being that a logging function logs a password to a log file, exposing the password. https://nvd.nist.gov/vuln/detail/CVE-2026-25210 - appears to be an undetected integer overflow, which I guess counts as a lack of validation, but the validation that the fix adds isn't a validation of arguments to the function. https://nvd.nist.gov/vuln/detail/CVE-2026-25156 - it doesn't look like a simple argument validation. https://nvd.nist.gov/vuln/detail/CVE-2026-25154 - the fix HTML-escapes a file name, so not a simple argument validation. And some of the ones after that didn't look like obvious cases of function inputs not being validated. If I switch to looking at CVEs for software with which I'm directly familiar, I see: https://nvd.nist.gov/vuln/detail/CVE-2019-1010220 - that's not a lack of validating of function arguments, it's a lack of validating that you're not running past the end of the packet being dissected when extracting an IP address prefix. So which CVEs did *you* see that were due to inputs not validated? And what fraction of all CVEs were in that category?
