ScreenshotNeo
Sign in Get a free key

BlogEngineering

Log4j Vulnerability: What It Is and How to Protect Your Applications

Log4Shell is a remote-code-execution flaw in Apache Log4j2. Learn how to identify affected software, remediate it safely, and investigate possible exploitation.

By the ScreenshotNeo team4 October 20269 min read

Log4Shell is the name commonly used for CVE-2021-44228, a remote-code-execution vulnerability in Apache Log4j2. The affected component is log4j-core; using log4j-api alone does not make an application vulnerable to this CVE. To protect an application, identify direct, transitive, and bundled Log4j components, follow the current Apache and software-vendor security notices for the exact product and runtime, update using supported packages, and investigate separately whether a potentially exposed system was exploited.

This is a remediation guide, not a current version-number prescription. The original emergency fixes and later Log4j disclosures occurred in stages. Check the live Apache Log4j security page and your product vendor’s advisory before choosing a release or mitigation.

What is the Log4j vulnerability?

Log4j is a Java logging library. Log4Shell describes a flaw in Log4j2’s handling of certain lookups: under affected conditions, attacker-controlled data written to a log could trigger JNDI-related lookup behavior and lead to remote code execution. NIST’s record describes affected Log4j2 releases beginning with 2.0-beta9 and extending through 2.15.0, subject to specified exclusions and conditions. Consult the CVE record for the precise scope; do not generalize this range to every Log4j release, other Apache logging projects, or every application that logs input.

The vulnerable code is in log4j-core. The API artifact alone is not affected by CVE-2021-44228. Applications can still be exposed through a core library included indirectly, shaded into another JAR, bundled in a product, or packaged inside a container or appliance. A product name or top-level dependency list may therefore be insufficient to establish whether it is affected.

How to protect an application from Log4Shell

  1. Build an asset inventory. List Java services, applications, containers, appliances, and vendor products that may include Log4j. Include development, test, staging, production, and externally managed systems where you can obtain vendor confirmation.
  2. Find direct, transitive, and bundled copies. Inspect dependency manifests, lockfiles, build outputs, packaged JAR/WAR/EAR files, container images, and software bills of materials when available. Ask vendors about components packaged inside products whose dependency details are not visible.
  3. Establish scope. Compare the actual component and configuration with the NIST CVE record, the current Apache security page, and the vendor notice for the product and runtime. Record evidence and uncertainty; an unknown bundled version should remain an open item until confirmed.
  4. Update affected software through its supported channel. Use the current vendor-supported package or release that addresses the applicable Log4j advisories. Updating Java alone does not replace updating the vulnerable Log4j library. Do not reuse a historical emergency version recommendation as universal current advice.
  5. If no supported update is available, use a vendor-provided mitigation only as a managed interim measure. Confirm applicability, operational impact, and how the mitigation will be removed or replaced. CISA’s December 2021 guidance treated workarounds as temporary and potentially incomplete or disruptive; consult current guidance for a present-day incident.
  6. Investigate possible exploitation. Patching closes or reduces exposure going forward; it does not determine whether an attacker accessed the system earlier. For systems exposed while potentially vulnerable, follow current incident-response guidance, inspect relevant logs and evidence, review unexpected accounts and configuration changes, and isolate known or suspected vulnerable assets as appropriate while they are mitigated and verified.
  7. Verify and track closure. Confirm the deployed artifact or vendor release, redeploy or rebuild affected images where necessary, check that old copies are no longer in service, and retain an owner, evidence, and status for each affected asset.

How to check whether an application uses Log4j

There is no single command that reliably finds every copy in every build and vendor product. Combine dependency analysis with inspection of packaged artifacts and vendor confirmation.

1. Check dependency declarations and resolved dependencies

Search project manifests and lockfiles for org.apache.logging.log4j, especially log4j-core. A declaration may be transitive, so inspect the resolved dependency graph rather than only direct declarations.

# Maven: show resolved dependencies related to Log4j
mvn dependency:tree -Dincludes=org.apache.logging.log4j

# Gradle: inspect the runtime classpath dependency graph
./gradlew dependencies --configuration runtimeClasspath

These commands help identify dependencies in those build systems; they do not prove that no copy is embedded, shaded, supplied by a container base image, or included by a vendor product. Review build plugins and packaging steps too.

2. Inspect packaged Java archives

For a JAR, WAR, or EAR you control, list archive entries and look for Log4j core artifacts or classes. For example:

jar tf application.jar | grep -Ei 'log4j-core|org/apache/logging/log4j/core'

# For nested JARs in a Spring Boot executable archive:
jar tf application.jar | grep -Ei 'BOOT-INF/lib/.*log4j|log4j-core'

Use an archive-aware scanner or unpack nested archives when needed. Shading can remove the original artifact name, so absence of a matching filename is not conclusive. Scan container image layers and deployed files as well as the source repository.

3. Check vendor products and deployment inventory

For appliances, SaaS-connected agents, commercial software, and products with opaque bundles, consult the vendor’s security notice and request confirmation of affected versions and remediation status. CISA’s joint guidance emphasizes comprehensive asset inventory and identification. Record product version, vendor response, exposure window, mitigation or update, and verification evidence.

Understanding the response choices

Situation Practical action What to verify
A supported vendor fix is available Prioritize the supported update and deploy it through the product’s normal change process. Installed product and Log4j component version, successful deployment, and removal of old instances.
No update is available yet Apply a vendor-approved temporary mitigation if applicable; assess service impact and set a follow-up date. Mitigation coverage, operational behavior, monitoring, and a plan to move to a supported fix.
An asset is known or suspected vulnerable and exposed Reduce exposure or isolate it as appropriate while mitigating and verifying; begin incident investigation based on exposure and evidence. Exposure period, relevant logs and accounts, unexpected changes, and incident-response findings.
Dependency visibility is incomplete Keep the asset unresolved, seek vendor confirmation, inspect deployed artifacts, and use available inventory or scanning resources. Evidence that the product’s bundled components and deployed versions are understood.

The right choice depends on whether a supported fix exists, operational criticality, service impact, and whether the action can be verified. A workaround is not equivalent to a confirmed update, and neither by itself proves that exploitation did or did not occur.

Investigation: remediation is not the same as incident response

Maintain two workstreams when exposure is plausible:

  • Vulnerability remediation: identify affected assets, update or mitigate them, and verify the deployed state.
  • Compromise investigation: determine whether suspicious activity occurred during the exposure window and whether credentials, systems, or data require further response.

Preserve relevant logs and evidence according to your incident procedures. Review unusual process execution, outbound connections, account creation or changes, and configuration changes in context; these are investigation leads, not proof of Log4Shell exploitation on their own. Escalate suspected compromise through your security incident process and use current CISA, Apache, and vendor guidance. Isolate assets when appropriate to contain risk while preserving the evidence needed for investigation.

Verification checklist

  • All potentially affected applications, containers, appliances, and vendor products have an owner and inventory record.
  • Direct, transitive, packaged, shaded, and vendor-bundled Log4j copies have been considered.
  • Applicability was checked against current Apache guidance and the relevant product-vendor advisory.
  • A supported update was deployed where available; temporary mitigations have owners and follow-up dates.
  • Deployed artifacts and images were checked, including old replicas and inactive-looking services that could be restarted.
  • Potentially exposed systems were assessed for exploitation separately from the patch work.
  • Open questions, vendor confirmations, exceptions, and verification evidence are documented.

Common errors and how to fix them

Problem Why it happens What to do
“Our application does not declare Log4j.” A transitive dependency or bundled product may include it. Inspect resolved dependencies and deployed packages; ask vendors about opaque bundles.
“We found log4j-api, so the application is vulnerable.” The API artifact is being confused with the affected core component. Check whether log4j-core is present and assess the exact CVE conditions and product advisory.
“We found no file named log4j-core, so we are clear.” Shaded classes, nested archives, containers, or vendor packaging can hide the original filename. Use artifact-aware inspection and vendor confirmation; treat incomplete visibility as unresolved.
“We upgraded Java, so Log4j is fixed.” The runtime and logging library are separate components. Update the affected application or Log4j package through its supported channel.
“The first emergency patch version is still the universal answer.” Log4j fixes were released in stages, and related disclosures followed. Use the current Apache security page and the vendor’s notice for the exact product and runtime.
“A patch proves no attacker got in.” Remediation addresses vulnerability state, not historical compromise. Investigate systems that were exposed or suspected vulnerable under current incident procedures.
“We can leave a workaround in place indefinitely.” Temporary mitigations can be incomplete, disruptive, or superseded. Track it as interim, verify its scope, and move to a supported update when available.

Performance, reliability, and cost considerations

Inventory and remediation have operational costs: dependency analysis, image rebuilds, vendor coordination, regression checks, service restarts, and incident investigation may take time or require maintenance windows. Prioritize by confirmed component presence, exposure, business criticality, and the availability of a supported fix. Coordinate changes with service owners and validate application behavior after deployment.

Scanning helps discover assets and dependencies, but results depend on what the scanner can inspect. It can miss opaque vendor bundles, shaded code, unmanaged deployments, or stale images outside the scan scope. Combine scanning with software inventories, build records, artifact inspection, and vendor notices; retain evidence so a clean scan is not mistaken for universal proof.

For a security investigation, preserve useful evidence before actions that might destroy it, where operationally safe. Balance containment with evidence collection and service continuity under your incident process. There is no single performance benchmark or cost figure that applies to every Java estate; estimate work against your own asset count, deployment model, and vendor response times.

Or skip the browser setup

For documenting a public security advisory or affected product page, you can capture a screenshot with ScreenshotNeo, a website screenshot API and MCP server. It is separate from vulnerability scanning and does not determine whether software contains Log4j or whether a host was compromised. One GET request returns an image or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://logging.apache.org/security.html -o shot.webp
import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://logging.apache.org/security.html"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://logging.apache.org/security.html'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, failed loads, and cache hits are not billed. Its response includes page-verdict and billing headers. An MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. These captures document webpages; they do not replace asset inventory, vendor updates, or incident response. Sign up for 1,000 free screenshots a month, no card required.

Frequently asked questions

Is Log4Shell the same as every Log4j vulnerability?

No. Log4Shell refers to CVE-2021-44228. Apache has published later related Log4j disclosures; assess each applicable advisory rather than treating this CVE as the whole security history.

Does every Java application use Log4j?

No. A Java application may use another logging library or none from Log4j. Check its resolved dependencies and packaged software, including vendor bundles.

Does a clean dependency scan prove an application was never exposed?

No. It only speaks to the assets and artifacts the scan could inspect at that time. Combine results with deployment inventory, vendor confirmation, and exposure history.

Should I investigate if the application has already been updated?

If it may have been exposed while vulnerable, evaluate the exposure window and available evidence under your incident-response process. Updating now does not answer whether earlier exploitation occurred.

Sources and current guidance

Keep reading