Skip to main content

Vulnerable Log4j issue types

Mark Glinski
  • Updated

This article addresses two informational issue types related to the Log4j vulnerability. The issue types differ according to:

  • What specifically we detected
  • How we detected it

The remediation and resolution steps are identical for both. 

Vulnerable Log4j version detected

No severity: Informational
Factor: Application Security
Factor weight: Medium

We detected evidence that a version of the Apache Log4j logging library that is vulnerable to remote code execution (RCE) exploits is running on your network.

How we discover this issue

We identify the presence of Log4j in an HTTP response and the HTML raw body. Log4j is not an application, but a library that many applications depend on. So, the detection is not as straightforward as product or service identification. Because Log4j is a static library linked to applications through configuration files, it is not always known if the application uses it. Instead, we detect through metadata whether it is present and exposed.

Product running vulnerable Log4j version

No severity: Informational
Factor: Network Security
Factor weight: Medium

We detected evidence that a product installed on your network may be running a vulnerable version of Log4j.

How we discover this issue

We identify products on your network that have been confirmed to be running vulnerable versions of Log4j, according to vendor advisories that we monitor.

Why these matter

An RCE vulnerability was discovered on Apache Log4j, a popular Java-based logging library.  Malicious parties can exploit RCE to gain unauthorized access to systems and applications and cause considerable damage to your data or business operations. The risk associated with this high-severity Log4j exposure is compounded by the high, and growing, frequency of reported exploit attempts.

Learn more about the Log4j vulnerability and what you can to about it.

How you can remediate these issues

Tip: In addition to the following remediation steps, see this FAQ: What action should I take now?
  1. Check if your organization is impacted.
    Any asset is probably impacted if it runs a version of Log4j later than 2.0 and earlier than 2.17.1, the fixed version release. Review your most recent vulnerability scan results, which likely contain the location of any Log4j installations active within the environment. You can also query cloud application logs for strings matching the syntax jndi.ldap. This will identify any instances of scanning or active exploitation attempts.
    Note: A system is only potentially compromised if the request was processed by a vulnerable version of Log4j. Otherwise, the activity should not be considered suspicious.
  2. Update to Log4j version 2.17.1 immediately.
    Find the latest version on the Log4j download page. Version 2.17.1 requires Java 8 or later, so make sure Java is running this version.
    Important: Verify that multiple Log4j installations are not present on an impacted machine, as this can mean that multiple configuration files exist. Each of these can contain a vulnerable version of Log4j. You will need to remediate each independently.

How you can resolve these issues in SecurityScorecard

When submitting a Resolution request, ensure you include supporting evidence where necessary. This will greatly assist us in ensuring your issue is resolved in a timely manner. See the following options for resolving [Issue-type-name] findings:

I have fixed this

  • Indicate that you have updated all instances of Log4j to Version 2.17.1 or later.

I have a compensating control

  • There are no compensating controls for this issue.

This is not my IP or domain

  • Indicate which the affected IP addresses are not part of your Digital Footprint. 

I cannot reproduce this issue and I think it is incorrect

  • Provide any context for why the findings for this issue type are incorrect.

Related articles