Apache Log4j JNDI Injection is a Java application attack path where attacker-controlled log data causes Log4j to make a JNDI lookup. That lookup can retrieve remote resources or objects, turning a logging function into a code execution or data access path when unsafe input reaches a vulnerable logging configuration.
How Log4j JNDI Injection Works
Apache Log4j jndi injection is not a standalone bug class so much as an unsafe interaction between attacker-controlled log input and a lookup mechanism. The danger comes from trusting data that should have remained inert text.
When Log4j evaluates a crafted lookup, it may resolve remote references instead of treating the value as a plain string. That turns routine logging into a potential execution, retrieval, or deserialization path, which is why this issue became such a widely abused Java application weakness.
Why It Is Dangerous in Java Applications
Logging often sits deep in request handling, error handling, and diagnostic code, so the vulnerable path can be reachable without an obvious user-facing feature. If untrusted input reaches the logger, the application may process it long before security controls or business logic have a chance to inspect it.
The main security problem is trust inversion: a component designed to record data starts interpreting that data as instructions or references. In practice, that can expose code execution, server-side request activity, credential disclosure, or internal resource access depending on the environment and what the lookup can reach.
For broader context on injection families and how they are typically abused in web applications, see the Web Application Attacks Guide.
How Organisations Check Exposure and Reduce Blast Radius
Exposure checks start with inventory, because organisations need to know where Log4j is present and which applications still accept attacker-controlled text into logs. Internet-facing services, public forms, headers, chat inputs, error messages, and integration endpoints deserve particular attention because those paths are easy to probe remotely.
Security teams also need to confirm whether the vulnerable component is directly reachable from untrusted traffic or only used internally. Even when patching is delayed, compensating controls such as egress filtering, network segmentation, temporary lookup restrictions, and strict input handling can reduce the chance that a log entry becomes an outbound lookup or code retrieval path.
Authoritative risk baseline guidance for web application attack patterns is captured in the OWASP Top 10.
Detection, Remediation, and Post-Exploitation Review
Detection should look for both attempted exploitation and signs that a lookup reached beyond normal logging behaviour. Suspicious log strings, unusual outbound LDAP or related directory traffic, unexpected DNS lookups, and process activity that follows a malformed request are all useful signals.
After remediation, organisations should not stop at removing the vulnerable component or configuration. They should review logs, process creation telemetry, outbound connections, and application runtime state for evidence of follow-on compromise, because exploitation may have occurred before the fix was applied.
If the attack path exposed application secrets, session material, or service credentials, those values should be treated as potentially compromised and rotated or invalidated as part of the recovery process.
Risk and Threat Considerations
This issue is dangerous because logging is often high-volume, highly trusted, and deeply embedded, which gives an attacker many opportunities to smuggle payloads into a path that defenders rarely watch closely. Once the application interprets log content as a lookup, the attacker may be able to trigger external retrieval or execute downstream code in the application’s trust boundary.
Failure mechanism: The application accepts attacker-controlled text, passes it into Log4j, and allows the logging layer to resolve a JNDI reference or equivalent external object path instead of preserving the input as inert data.
Impact: That failure can lead to remote code execution, internal resource access, secret exposure, service disruption, or persistent compromise of the affected Java application and adjacent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | Log4j JNDI injection exploits unsafe logging behaviour and log handling paths. |
| V15 — Secure Coding and Architecture | The issue is enabled by insecure assumptions in application design and input handling. | |
| Recommendation — Harden logging so untrusted input is recorded as data, not evaluated as executable context. Remove dangerous lookup behaviour from application design and treat log data as untrusted. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | The attack path uses crafted input to trigger code execution in the target application. |
| T1059 — Command and Scripting Interpreter | Successful exploitation can lead to command execution on the affected host. | |
| Recommendation — Map observed exploitation attempts to T1203 and hunt for execution after malicious input reaches the logger. Investigate post-exploitation command execution and correlate it with suspicious log input. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application security controls should prevent unsafe evaluation of externally supplied input. |
| Recommendation — Review application code and libraries for unsafe log lookups and remove exposed vulnerable components. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org