> According to a translated technical blog post , JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP.
As for JDK 8, numerous outlets are reporting that it is actually Java 8u121 that protects against JNDI remote class loading by default (see release notes https://www.oracle.com/java/technologies/javase/8u121-relnot...). That was released in 2017-01, which was just about five years ago. I think that should save a lot of peoples' bacon, should it not?
This post claims the history of which releases closed which holes is a bit more complicated and that 8u191 really is the first release to prevent this particular exploit. However it also points out that it’s still possible to achieve RCE via log4j template expansion in certain Tomcat and Websphere configurations:
The remote class loading is the most severe part of this but even without that this vulnerability still does things like leak environment variables to arbitrary remote endpoints.
As for JDK 8, numerous outlets are reporting that it is actually Java 8u121 that protects against JNDI remote class loading by default (see release notes https://www.oracle.com/java/technologies/javase/8u121-relnot...). That was released in 2017-01, which was just about five years ago. I think that should save a lot of peoples' bacon, should it not?
Java 8u191 fixed something about an LDAPS timeout in JDNI lookups: https://www.oracle.com/java/technologies/javase/8u191-relnot...