Test a Website for the Log4j Vulnerability

Log4Shell is unique among modern vulnerabilities because the attack surface is almost entirely defined by logging behaviour rather than explicit user-facing functionality. The Apache Log4j 2 library, used by a vast number of Java-based applications, performs JNDI (Java Naming and Directory Interface) lookups when it encounters a ${jndi:...} pattern in a logged string. Because virtually every application logs HTTP headers like User-Agent and X-Forwarded-For, an attacker only needs to include the lookup string in a standard HTTP request — no authentication, no account, and no knowledge of the application's business logic required. The lookup causes the server to contact an attacker-controlled LDAP or DNS server and, on vulnerable Log4j versions, load and execute a Java class from that remote location.

The impact of a successful Log4Shell exploit is immediate remote code execution on the server. Attackers exploiting this vulnerability in the wild have used it to install cryptominers, ransomware, and persistent backdoors; to pivot into internal networks via compromised cloud instances; and to exfiltrate credentials from environment variables and configuration files. Because Log4j is embedded as a transitive dependency in a large number of Java frameworks — including Apache Solr, Elasticsearch, VMware vCenter, Cisco products, and many others — organizations often discover they are running vulnerable versions through third-party software rather than their own code.

Patching Log4Shell requires upgrading to Log4j 2.17.1 or later (for Java 8), 2.12.4 or later (for Java 7), or 2.3.2 or later (for Java 6). If an immediate upgrade is not possible, the official mitigations for Log4j 2.10.0 to 2.14.1 include setting the system property log4j2.formatMsgNoLookups=true or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true, which disables JNDI lookups in log message bodies. Note that this mitigation does not fully protect versions below 2.10.0 or scenarios where the ${jndi:...} string appears in a thread context map (MDC) value rather than the message body itself.

Many organisations patched their directly-controlled applications quickly after Log4Shell's disclosure, but the vulnerability persists in unexpected places in 2026. Third-party SaaS integrations, vendor appliances, legacy back-office systems, and internal tooling may still run vulnerable Log4j versions that were never updated. Network appliances, monitoring dashboards, and build-pipeline tools are common examples. Vuln0x's Log4j scanner probes the externally reachable surface of your application — not just the homepage, but API endpoints, authentication flows, file upload handlers, and webhook receivers — to identify which surfaces process user input and whether any of them trigger a JNDI callback.

Beyond the immediate Log4j patch, the Log4Shell incident highlighted broader risks in the Java dependency ecosystem. Many teams were unaware that Log4j was present in their dependency tree as a transitive dependency — included automatically by a framework or library rather than declared explicitly. An effective software composition analysis (SCA) practice, integrated into the CI/CD pipeline, alerts teams when a new vulnerability affects any dependency at any depth of the tree. Vuln0x's full scan complements SCA by testing the live application surface rather than the dependency manifest, catching cases where a vulnerable library is present but the vulnerable code path was not obvious from a static analysis. Running both gives the most complete picture of Log4j exposure.