Cybersecurity leaders are concerned that attackers could further weaponize the Log4j security vulnerability by creating a “worm” that spreads automatically from one vulnerable device to another. 

Here’s what security leaders are saying about this scenario:

Yaniv Balmas, Vice President of Security Research at Salt Security, a Palo Alto, Calif.-based provider of API security:

 A wormable exploit is definitely a valid scenario here - we already see cases where the Log4Shell vulnerability is used by “common” cybercrime-related operations in order to spread ransomware and other common mischiefs. Judging from past experience, it is very likely someone will decide to embed this vulnerability into a worm which will be almost impossible to stop once it reaches a critical mass. You must remember that we still see artifacts from similar worms that were launched years ago, even today.

However, while not neglecting the impact of such a worm, that might not be the worst scenario because of the unbelievable easiness that this attack can be applied. Everyone with a basic computer and internet access could launch an attack against millions of online services within minutes. This achieves quite a similar impact as a worm - it is distributed and unpredictable, and the damage extent might even be greater than a worm since a worm works “blindly” in an automated manner. In this other scenario, there are actual humans behind the attacks, which may target specific entities or institutions and enable attackers to fine-tune their attacks as they progress.

Jake Williams, Co-Founder and CTO at BreachQuest, an Augusta, Georgia-based leader in incident response:

There’s no question that someone will create a worm that abuses the Log4Shell vulnerabilities. However, this won’t be like WannaCry, NotPetya, or many previous worms that abuse system-level processes. The vast majority of servers vulnerable to Log4Shell will be running the vulnerable process with very limited permissions. In most cases, a worm exploiting Log4Shell would probably not be able to achieve persistence across process restarts. Additionally, because the process probably doesn’t have filesystem permissions, we should worry less about ransomware payloads. A malicious process can’t encrypt what it can’t write in the first place. While we should absolutely expect a Log4Shell worm to be created, we shouldn’t conflate the expected damage of a worm with what has been seen in previous high-profile worms.

John Bambenek, Principal Threat Hunter at Netenrich, a San Jose, Calif.-based digital IT and security operations company:

This vulnerability certainly looks wormable; however, the good news is we’ve already had almost a week to start dealing with detection, mitigation, and patching. There will be lots of vulnerable machines out there, but by now, a good deal of the vulnerable machines have been handled, and many more are protected with WAF rules (for instance, Cloudflare deployed protection over the weekend). The worst case would have been a worm last week; we’re in a better place now.

Chris Morgan, Senior Cyber Threat Intelligence Analyst at Digital Shadows, a San Francisco-based provider of digital risk protection solutions:

When security teams think of the threat posed by worms, immediate thoughts will almost always go to the WannaCry incident of 2017, which caused absolute chaos amongst Windows’ operating systems across a broad spectrum of the security industry. While it’s possible that we could see a worm developed to spread among susceptible Log4j devices, there hasn’t been any evidence to suggest this is a priority for threat actors at this time. Developing malware of this nature takes a significant amount of time and effort.

This activity differs from the Wannacry incident, which saw a perfect storm of a highly exploitable vulnerability coinciding with an NSA-level exploit breach in EternalBlue. It’s still very much early days with regards to Log4j. While many threat actors will likely be at different stages of the kill chain, most actors will likely still be scanning for susceptible systems, attempting to establish a foothold, and identifying further opportunities, depending on their motivations. Efforts among actors at this stage are rushing to exploit before companies have a chance to patch, rather than spending time developing a worm.

Tim Wade, Technical Director, CTO Team at Vectra, a San Jose, Calif.-based AI cybersecurity company:

While worms may move and spread at scale, my own bias is that this is a vulnerability that is still mostly at risk from attack by creative and adaptive human adversaries that may leave fewer fingerprints behind them as they undertake less overt attacks – such as extracting cryptographic secrets or API keys for present or future campaigns. This isn’t to say that a worm enabling further immediate, mass exploitation is not problematic – just that some of these less direct attacks may introduce more lasting damage when they go undetected for great lengths of time.

Casey Ellis, Founder and CTO at Bugcrowd, a San Francisco, Calif.-based leader in crowdsourced cybersecurity:

Much of the R&D that is going into Log4Shell feels eerily similar to what we saw around the Microsoft vulnerabilities that turned into MS.BLAST, Sasser, and Nachi back in 2003. In particular, if a self-contained payload that executes reliably from the first-stage JDNI call can be constructed, this would be comparatively easier to turn into a worm than the current exploit chain. For an adversary, this would be an effective way to traverse around inside internal networks where inbound requests have been filtered, and outbound requests have been blocked.

While it can be argued that malicious attackers have more than ample opportunity to achieve their goals with Log4Shell without engineering a self-propagation mechanism, there is also a “hobbyist” motivation around worming the exploit. Historically, many of the worms that were most impactful on the internet were research projects which ended up being unexpectedly successful.