Log4Shell (CVE-2021-44228) is a remote code execution vulnerability in Apache Log4j 2, the Java logging library used inside a huge share of enterprise and open-source software, disclosed in December 2021 with a maximum CVSS score of 10.0. An attacker sends a single crafted string — often just a request header or a search field — that Log4j logs and, through its JNDI lookup feature, resolves against an attacker-controlled server, loading and executing remote code with no authentication required. More than three years later, Log4j is still shipped inside legacy Java applications, vendor appliances, and forgotten internal tools across Indian enterprises, and unpatched instances are still found and exploited today — making Log4Shell less a closed incident and more a permanent lesson in dependency hygiene.
What Log4Shell Actually Is
Log4j 2 shipped a feature called message lookup substitution: if a logged string contained ${jndi:ldap://...}, the library would treat it as a live lookup instruction rather than plain text, reach out over the network to the specified server, and load a Java class from the response. This was intended for legitimate configuration lookups, but it meant any application logging user-controlled input — a username, a User-Agent header, a search query, an HTTP request path — handed an attacker a direct path from a single text string to arbitrary code execution on the server.
The vulnerability affected Log4j 2.0-beta9 through 2.14.1, a range that covers essentially every production deployment of Log4j 2 running in late 2021, as documented in the NVD entry for CVE-2021-44228. It was fixed in 2.15.0, but that fix was incomplete: follow-on CVE-2021-45046 addressed cases where the initial patch still allowed denial-of-service and, in some non-default configurations, remote code execution (fixed in 2.16.0), and CVE-2021-45105 addressed a separate uncontrolled recursion denial-of-service issue (fixed in 2.17.0). A further remote code execution issue, CVE-2021-44832, exploitable via a maliciously configured JDBC Appender, was fixed in 2.17.1 — the release generally considered the fully hardened patch level. Because the vulnerable code path required no authentication and no user interaction, and because Log4j is embedded three or four dependency layers deep inside countless applications that developers never audited directly, mass internet scanning for vulnerable endpoints began within hours of public disclosure.
Why It's Still Relevant in 2026
Most Indian security teams patched their obvious, internet-facing Log4j deployments in the weeks after the December 2021 disclosure. What didn't get patched — and often still hasn't — is Log4j buried inside dependencies of dependencies: a vendor-supplied monitoring agent, an internal admin tool built years ago and never touched since, a Java-based appliance whose vendor stopped issuing updates, or a transitive dependency pulled in by a build tool that nobody on the current team can name. Log4j's ubiquity inside the Java ecosystem is exactly what made it dangerous in 2021, and that same ubiquity is why residual instances keep surfacing in security assessments years later.
This pattern isn't unique to Log4j. It's the standard lifecycle of a critical, widely embedded open-source vulnerability: an intense wave of patching immediately after disclosure, followed by a long tail of forgotten, indirectly-included, or vendor-locked instances that persist for years. Attackers know this tail exists and continue to scan for it, because the cost of finding one more unpatched Log4Shell endpoint is near zero and the payoff — unauthenticated remote code execution — hasn't changed.
The Exploitation Path
The payload doesn't need to arrive through an obvious channel. Security researchers and incident responders documented the string appearing in HTTP headers, login form usernames, chat messages, device names broadcast over local networks, and even the names of files uploaded to a server — anywhere an application logged attacker-influenced text through a vulnerable Log4j instance. That breadth of entry points is a core reason the vulnerability spread so fast and remains hard to fully eradicate: fixing the obvious web-facing forms doesn't guarantee every logging call site across a large application has been located and checked.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanWhere Residual Exposure Hides
| Exposure source | Why it's missed | Typical fix |
|---|---|---|
| Transitive dependencies | Not in the direct import list; buried several layers deep | Full dependency tree scan, not just top-level manifest review |
| Vendor appliances and OEM software | Organisation doesn't control the update cycle | Vendor patch confirmation, network-level isolation if unpatched |
| Legacy internal tools | No active owner, rarely touched, easy to forget | Asset inventory sweep including internal-only systems |
| Old build artefacts and containers | Baked into an image built before December 2021, never rebuilt | Rebuild and redeploy from a current, patched dependency set |
| Backup and DR environments | Excluded from routine patch cycles since they're not "live" | Extend patch and scan scope to standby and backup systems |
SBOM and Dependency Inventory as the Real Fix
The structural lesson of Log4Shell is that you cannot patch what you don't know you're running. A Software Bill of Materials (SBOM) — a machine-readable inventory of every component and version inside an application, including transitive dependencies — is what turns "was I affected by Log4Shell" from a frantic, manual, days-long exercise into a query you can run in minutes. Organisations with a maintained SBOM in December 2021 were able to identify every affected system almost immediately; organisations without one spent weeks manually grepping filesystems and asking every team to self-report, and many are still finding stray instances today because that manual sweep was never actually complete.
Building an SBOM isn't a one-time exercise tied to a single incident. It needs to be generated automatically as part of the build pipeline, kept current as dependencies change, and queried whenever the next critical library vulnerability is disclosed — because there will be a next one. Log4Shell was severe precisely because Log4j was everywhere; the next critical vulnerability in a widely embedded library will spread through the same blind spots unless the dependency inventory problem is solved structurally rather than repeated ad hoc each time.
Component Exposure Breakdown
Based on documented post-disclosure incident response findings, the largest share of lingering exposure sits in components organisations don't directly control or actively maintain, rather than in code they wrote and own:
Virtual Patching When You Can't Upgrade Immediately
Not every vulnerable instance can be patched the moment a fix ships. A vendor appliance may not have an available update yet, a legacy application may be too fragile to touch without a full regression cycle, or a change freeze may be in effect. In those cases, a Web Application Firewall (WAF) configured to block the JNDI lookup patterns associated with Log4Shell — the ${jndi: prefix and its common obfuscated variants — provides virtual patching: it doesn't fix the underlying code, but it closes the exploitation path at the network edge until the real fix can be deployed. Virtual patching is a bridge, not a substitute for upgrading Log4j itself, and it should always be paired with a tracked remediation deadline rather than left as a permanent workaround.
Why Old CVEs Keep Biting Indian Organisations
Log4Shell isn't unusual in staying relevant this long — it's representative of how most critical open-source vulnerabilities actually behave over time. Indian organisations that treat vulnerability response as a one-time patching sprint tied to the news cycle, rather than an ongoing inventory and scanning discipline, end up rediscovering the same class of exposure every time a new critical CVE makes headlines, because the underlying gap — not knowing what's actually running in production — was never closed. A free VAPT scan against your live infrastructure will surface exactly this kind of lingering, unpatched component, including old library versions that predate a security team's current tenure.
Bachao.AI builds continuous dependency and vulnerability visibility into its VAPT platform specifically because incidents like Log4Shell keep proving that a single point-in-time audit isn't enough — new instances of old vulnerabilities keep surfacing as infrastructure changes, vendors ship new appliances, and teams inherit systems nobody currently on staff originally built. Dhisattva AI Pvt Ltd designed the platform around that reality: continuous scanning catches the residual Log4j instance that a one-off pentest three years ago never saw, because it didn't exist yet.
Next Steps
Log4Shell's technical fix has existed since December 2021, but the organisational fix — knowing what you're running, at every layer of the dependency tree, at all times — is still incomplete across much of Indian enterprise IT, and that gap is exactly what makes a four-year-old CVE still worth writing about. Build and maintain an SBOM, extend vulnerability scans to vendor appliances and backup environments as well as production servers, and treat virtual patching as a documented bridge with a deadline, not a permanent answer.
Want to know whether Log4Shell or another dependency-level vulnerability is still lurking in your infrastructure? Get a free VAPT scan, or browse the blog for more practical security guidance. If your systems process personal data under India's privacy law, also review our DPDP compliance guide.