Summary
Log4Shell demonstrated that log data is still untrusted input. When an application passed attacker-controlled strings to an affected Log4j 2 release, message lookup behavior could initiate JNDI access and, under the necessary runtime conditions, lead to remote code execution.
Why cleanup is difficult
Log4j is frequently present as an indirect dependency in large Java applications, commercial products, device firmware, and legacy deployments. Searching only the application root for JAR files can miss nested archives, container layers, old images, offline nodes, and vendor-packaged components.
Remediation guidance
- Begin with asset and dependency inventories rather than treating internet scanning as a substitute for internal discovery.
- Install a vendor-supported safe version and verify the classpath that the application actually loads.
- Remove old container images, build caches, and rollback packages so vulnerable releases cannot return to production.
- Retain detection for unusual outbound DNS, LDAP, and RMI connections.
- Turn component discovery into a continuous software supply-chain control instead of a one-time incident script.