Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer
Noname Security Logo

Log4j Vulnerabilities Explained: What They Are and How to Fix

Aner Morag
Share this article

Security teams around the globe are scrambling to address the Apache Log4J2 vulnerability (CVE-2021-44228), dubbed “Log4Shell”, which can be easily exploited to take control of system vulnerabilities remotely. At the same time, hackers are actively scanning the internet for affected systems. The United States Cybersecurity and Infrastructure Security Agency issued an alert about the vulnerability on Friday, as did Australia’s CERT. 

In this post, we will provide a quick overview of Log4Shell and recommendations for cyber security teams. For Noname Security customers, our API Security Platform detects and blocks cyber attacks caused by Log4j vulnerabilities.. The Noname research team has also confirmed that the API Security Platform is not impacted by Log4Shell. 

Summary of the Log4Shell Vulnerability

Thousands of applications and third-party services are exposed to a serious vulnerability (CVE-2021-44228) from a popular open source logging library called Apache Log4j. Due to a bug in the Log4j library, attackers can remotely execute arbitrary code to gain access to systems. Threat actors are actively scanning for environments that are affected.

Challenges in Addressing “Log4Shell” Vulnerability

The Log4Shell vulnerability is making headlines because of how pervasive the Log4j library is and how easy it is to exploit. And, given how Java packing works, it is often very difficult to even identify which applications are impacted. For example, Java archive (JAR) files contain all the dependencies, including the Log4j library. However, a JAR file can also contain another JAR file (which could also contain another JAR file) — essentially nesting this vulnerability several layers deep.

This is a very pervasive problem, and it is going to be very difficult for cyber security teams to find.

Log4Shell Vulnerability in APIs

APIs act as an intermediary between multiple applications and systems, and Log4Shell creates two significant issues with APIs.

The first is that API servers that are vulnerable to Log4Shell now expose a new attack surface for attackers. Most organizations have limited visibility into their API inventory and the behavior of their APIs, making APIs a preferred target for threat actors.

Second, if an attacker exploits the Log4Shell vulnerability to gain access to a system, APIs are capable of extending the attacker’s reach and the damage they can inflict. For example, many businesses have trusted third party APIs that may be exposed to the Log4Shell Vulnerability. Even if a business itself doesn’t use the Log4j framework for logging, third party APIs could increase risk exposure.

It is critical for businesses to have more granular visibility and observability of their APIs to understand their trust risk exposure.

Can Noname Security Detect Log4Shell Risks in APIs?

Yes. Noname Security is the only company to analyze API traffic, configuration, and code to provide full visibility of all APIs in their environment, as well as API behavior. Noname does give you the ability to detect anomalous behavior and block attacks in real-time — even if it is from a new or unknown threat, like Log4Shell.

Is the Noname API Security Platform Affected?

No, the Noname API Security Platform doesn’t use any Java code. 

What Else Should You Do — PATCH!

The Apache Software Foundation recently released an emergency patch for the vulnerability. Affected organizations should upgrade to Log4j 2.15.0 as soon as possible or apply the appropriate mitigations if upgrading is not possible. 

If you have additional questions contact us at or book a demo to learn more about the Noname API Security Platform.