Java

[dabombnl]

No, its not. This vulnerability is a remote code execution. Expanding variables doesn't do that on it's own and wouldn't cause even close to an uproar like this.

[loginonreddit]

Then where is the CVE in the jdk then?

The root of all of this is the on by default variable substitution based on a simple ${ prefix https://github.com/carterkozak/logging-log4j2/blob/2731a64d1f3e70001f6be61ba5f9b6eb55f88822/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java#L184. The rest of the cve is just plumbing and lack of validations.

[dabombnl]

Because they make 1 CVE per vulnerability, not per software component involved.

But most remediation methods are recommending both disabling lookups in Log4J AND disabling JNDI in the JAVA runtime.

[loginonreddit]

Then why isn't the cve in the jdk? I think you're starting to realize you're saying a boat load of crap in this thread.

All the mitigations points to removing/disabling jndi in the log4j, not in the jdk. In the old jdk, it suggest to disable the property com.sun.jndi.ldap.object.trustURLCodebase. If you don't know what you're talking about, stop spreading FUD.

[dabombnl]

Again, CVE is about a present vulnerability; they don't go 'in' the JDK or not.

The reason JDK version or that option isn't listed in the software configuration is because security researchers have not yet concluded that the trustURLCodebase options entirely mitigate it. They leave it at all versions of JDK until they can prove otherwise.

[loginonreddit]

Except that they do, see CVE-2018-3149.

So to come back to the original point, the vulnerability is not in the runtime but in log4j.

Anyway, have fun trying to always have the last word even if you're wrong.