On Jan 31, 2026, at 4:24 AM, Amit <[email protected]> wrote: > > On Sat, 31 Jan 2026 at 17:11, Guy Harris <[email protected]> wrote: >> >> 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? > > I looked at the list here: > https://nvd.nist.gov/vuln/search#/nvd/home?sortOrder=3&sortDirection=2&resultType=records > > I am not listing the complete detail and I am listing only those CVEs > that occurred due to no input validation. > > https://nvd.nist.gov/vuln/detail/CVE-2026-1251: Missing validation on > a user controlled key.
That's an input validation issue, but it does not appear to be a "make sure the string isn't too long" issue. > https://nvd.nist.gov/vuln/detail/CVE-2026-0683: Not validating the > user supplied operand value. That's an SQL injection error, not a "make sure the string isn't too long" issue. > https://nvd.nist.gov/vuln/detail/CVE-2020-37057: Contents of 'fid' > field not validated (it is an input from the user which some function > is not validating). That's *another* SQL injection error. If you're trying to promote the idea of applying arbitrary limits to the lengths of strings, CVEs that are the result of failing to validate the *contents* of strings, or of making sure those contents are not used in an unsafe manner (which may not be doable simply by picking some validation criterion) aren't useful. > Actually, in my opinion, PHP/Javascript rarely do any validation of > input, The languages, or the libraries? > https://nvd.nist.gov/vuln/detail/CVE-2020-37056: Input header requests > not validated. That refers to https://cwe.mitre.org/data/definitions/290.html which lists some issues such as "Reliance on IP Address for Authentication" and "Using Referer Field for Authentication". Those aren't "properly validate the input", it's "don't use certain parts of the input for authentication, as there's no way to validate them". > https://nvd.nist.gov/vuln/detail/CVE-2020-37053: Manipulating the > 'sidx' parameter in comments, so here, 'sidx' parameter is not > validated. Another SQL injection issue. > I am listing the CVEs that are related to XSS attacks because they > happen because of inputs not being properly validated or sanitized. Yes, but those again have nothing to do with the size of the input, just as SQL injections have nothing to do with the size of the input. A lot of those are due to naively inserting user input into SQL statements, and can be fixed either by checking the input to make sure it's safe to add to an SQL statement or adding it to whatever you send to the SQL server in such a way that it's not ever going to be interpreted as SQL. > There are many more CVEs that happen because some inputs are not being > validated. Yes, the *very broad* category of "input not validated" is a cause of many issues. Unfortunately, it's *so* broad that there is not one "magic bullet" solution. "Be careful when generating SQL" helps for SQL injection attacks but doesn't help if your code *doesn't generate SQL*. Input size limits might help with *some* buffer overflow problems, but not all.
