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.
https://nvd.nist.gov/vuln/detail/CVE-2026-0683: Not validating the
user supplied operand value.
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).

Actually, in my opinion, PHP/Javascript rarely do any validation of
input, so most of the CVEs involving PHP/Javascript can be categorized
as "input not validated".

https://nvd.nist.gov/vuln/detail/CVE-2020-37056: Input header requests
not validated.

Basically, all inputs from the user should be validated but they are
not and many CVEs are related to this.

https://nvd.nist.gov/vuln/detail/CVE-2020-37053: Manipulating the
'sidx' parameter in comments, so here, 'sidx' parameter is not
validated.
https://nvd.nist.gov/vuln/detail/CVE-2020-37049: Buffer overflow (no
limit put on the length of contents of the Command Line input field).

I am listing the CVEs that are related to XSS attacks because they
happen because of inputs not being properly validated or sanitized.

>From google AI: Yes, cross-site scripting (XSS) attacks are directly
related to inputs not being properly validated or sanitized. The lack
of input validation is the fundamental security flaw that enables XSS
attacks.

These CVEs are: https://nvd.nist.gov/vuln/detail/CVE-2020-37054,
https://nvd.nist.gov/vuln/detail/CVE-2020-37046,
https://nvd.nist.gov/vuln/detail/CVE-2020-37044.

https://nvd.nist.gov/vuln/detail/CVE-2020-37043: Application's
registration key input not being validated.

There are many more CVEs that happen because some inputs are not being
validated.

I can't go through the whole database, so I am stopping here.

I will also give a simple logic as to why a majority of CVEs are
related to input not being validated: If you let an application run,
then it is not going to get hacked if it gets no input. It gets hacked
only when some input arrives. You can keep your browser open for days
and it won't get hacked if you are not browsing any site (assuming
that the browser itself is also not doing anything).

Amit

  • Will the Open Group ... Amit via austin-group-l at The Open Group
    • Re: Will the Op... Amit via austin-group-l at The Open Group
    • Re: Will the Op... Guy Harris via austin-group-l at The Open Group
      • Re: Will th... Amit via austin-group-l at The Open Group
        • Re: Wil... Jonathan Wakely via austin-group-l at The Open Group
          • Re:... Amit via austin-group-l at The Open Group
        • Re: Wil... Guy Harris via austin-group-l at The Open Group
          • Re:... Amit via austin-group-l at The Open Group
    • Re: Will the Op... David A. Wheeler via austin-group-l at The Open Group
      • Re: Will th... Amit via austin-group-l at The Open Group
        • Re: Wil... David A. Wheeler via austin-group-l at The Open Group
          • Re:... Guy Harris via austin-group-l at The Open Group
          • Re:... Amit via austin-group-l at The Open Group
            • ... Niu Danny via austin-group-l at The Open Group

Reply via email to