[ajross]

> Unless you're logging user input without proper validation, log4j doesn't really seem that bad.

Most systems do log user input though, and "proper validation" is an infamously squishy phrase that mostly acts as an excuse. The bottom line is that the natural/correct/idiomatic use of Log4j exposed the library directly to user-generated data. The similar use of Apache parquet (an obscure tool many of us are learning about for the first time) does not. That doesn't make it secure, but it makes the impact inarguably lower.

I mean, come on: the Log4j exploit was a global zero-day!

[jeroenhd]

> Most systems do log user input though, and "proper validation" is an infamously squishy phrase that mostly acts as an excuse

That's my point: if you start adding constraints to a vulnerability to reduce its scope, high CVE scores don't exist.

Any vulnerability that can be characterised as "pass contents through parser, full RCE" is a 10/10 vulnerability for me. I'd rather find out my application isn't vulnerable after my vulnerability scanner reports a critical issue than let it lurk with all the other 3/10 vulnerabilities about potential NULL pointers or complexity attacks in specific method calls.

[ajross]

> Any vulnerability that can be characterised as "pass contents through parser, full RCE" is a 10/10 vulnerability for me

And I think that's just wildly wrong sorry. I view something exploited in the wild to compromise real systems as a higher impact than something that isn't, and want to see a "score" value that reflects that (IMHO, critical) distinction. Agree to disagree, as it were.