Log4Shell CVE-2021-44228 (Apache Log4j 2 JNDI lookup RCE, CVSS 10, CISA KEV) is still exploited years later. How do I find vulnerable log4j-core copies, including ones shaded inside other jars, and fix them?

What it is: CVE-2021-44228 (Log4Shell) is a flaw in Apache Log4j 2 where text that gets logged could trigger a JNDI lookup and load remote code. Follow-up issues CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832 needed further releases. CISA lists it in the Known Exploited Vulnerabilities catalog, and scanning for it never stopped: forgotten appliances, old internal Java apps and vendor products that bundle an old log4j-core are still being hit. Am I affected: - Any Java application with log4j-core 2.0-beta9 through 2.14.1 is vulnerable to the original bug; anything below 2.17.1 (Java 8+) still has the follow-up issues. Log4j 1.x is not affected by Log4Shell but is end-of-life with its own unfixed CVEs. - log4j-api alone is not the vulnerable part; log4j-core is. - Old copies often hide inside fat/uber jars, WAR/EAR files and vendor appliances, so a dependency file check alone can miss them. How to find it: - Maven: mvn dependency:tree | grep log4j-core. Gradle: gradle dependencies (or dependencyInsight --dependency log4j-core). - Scan built artifacts and servers, not just source: SBOM tools or scanners such as Syft/Grype, OWASP Dependency-Check, or your vendor's scanner look inside nested jars. A quick manual check: search jar/war/ear files for org/apache/logging/log4j/core/lookup/JndiLookup.class. - For third-party products, check the vendor's Log4j advisory; CISA kept a community list of affected vendors. Fix: 1. Upgrade log4j-core to the current 2.x release (at least 2.17.1 for Java 8+; 2.12.4 for Java 7, 2.3.2 for Java 6). Using the log4j-bom keeps log4j-core and log4j-api in step. 2. Rebuild and redeploy every artifact that bundles it, including shaded jars. 3. For vendor products, apply the vendor's patched release. Removing JndiLookup.class from the jar was Apache's emergency mitigation for systems that can't be upgraded yet; it is a stopgap, not a fix. The old formatMsgNoLookups flag is not enough on its own. 4. If a system was internet-facing and unpatched, treat it as possibly compromised: look for unexpected outbound LDAP/RMI/DNS traffic and web shells, and rotate credentials stored on it. Verify: rerun the artifact scan and confirm no log4j-core below the fixed version remains anywhere; add the check to CI so an old transitive dependency can't return. Sources: https://logging.apache.org/security.html https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance https://nvd.nist.gov/vuln/detail/CVE-2021-44228