Ten days after the critical vulnerability called Log4Shell (CVE-2021-44228) first set the Internet ablaze, organizations are almost halfway through remediating the issue in their cloud environments. See the full technical details here.

Wiz and EY (Ernest & Young) analyzed more than 200 enterprise cloud environments with thousands of cloud accounts. The results were striking: While 93% of all cloud environments are at risk from Log4Shell, on average organizations have patched 45% of their vulnerable cloud resources by Day 10 (December 20, 2021). Note that while our data only accounts for Log4Shell in cloud environments, this vulnerability also affects on-premise networks.

To give organizations a benchmark for their own efforts, we calculated the average patch rate of organizations in each sector. We found that remediation rates vary considerably by industry. Financial services, where companies have patched 50% of vulnerable assets on average, led the pack, while manufacturing lagged (34% average rate).

When we took a closer look at the cloud assets that are vulnerable to Log4Shell, it’s clear why fixing them is so urgent. On average, 20% of an organization’s at-risk workloads have high privileges in the cloud account, which means attackers may be able to access sensitive databases and other information from these machines. 7% are exposed to the internet and are prone to be exploited by the active wide internet attack attempts.

Additionally, we found that 45% of vulnerable machines are not protected by endpoint protection agents. Agent-based security solutions have limited utility in detecting Log4Shell risks because they can only scan virtual machines and containers they’re installed on (typically under 60% coverage of a cloud environment), leaving organizations blind to the risks in other resources where they are not installed.

Why is remediation taking so long?

Log4Shell is like cleaning up an oil spill. It’s everywhere, so the process is messy and time-consuming

Most organizations have been hard at work trying to fix this vulnerability – and despite the challenges, they’re making steady progress. Six days after Log4Shell was first made public , the average patching rate per organization was only 30%.

To understand the magnitude of the problem just on cloud environments, consider that 5.7% of an average organization’s workloads are vulnerable (according to our data). That might not sound too bad – until you realize a large organization could have 20,000 workloads.

Imagine how daunting it is to patch thousands of applications. Many of them have code dependencies, others rely on vendors that haven't released new versions of their products yet. Some are virtual machines that no one has touched for years. Just getting access to them and testing the patch can take weeks.

Since the log4j library is used widely, teams first must identify which assets need to be updated. In order to detect Log4Shell in your environment, you need to scan all workloads, including VMs running with legacy apps, containers running on Kubernetes, and even serverless code running on cloud functions. To make matters even more complicated, log4j may be deployed as a package or embedded into the app itself, so any detection tool you use must include support for both.

Remediation efforts have also been complicated by new vulnerabilities that have been discovered since the first log4j patch was issued. Two additional log4j versions were released to fix less severe vulnerabilities (CVE-2021-40546, CVE-2021-45105) and workaround instructions were modified. In other words, remediation is a moving target and information is changing daily.

Wiz is one of the only products that can detect Log4Shell across your entire environment within minutes. If you’re not a Wiz customer, click here for a Log4Shell assessment of your cloud environment.

Once you’ve identified all the vulnerable resources, each one needs to be patched. But first your team has to check that updating won't break other parts of your code that rely on the log4j library. As a result of that, patching requires a joint effort from both security and developer teams.

Log4Shell also affects a huge number of popular apps, websites, and services that all need to be patched - which means waiting until each vendor releases their update. CISA maintains a list of vendors that haven't released their updates yet.

As security and developer teams continue to work hard over the holidays, this data is a reminder that nearly every organization is facing similar challenges. Log4shell casts a long shadow, but there’s light at the end of the tunnel.