Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time




This tool provides you with the ability to scan internal (only) subnets for vulnerable log4j web services. It will attempt to send a JNDI payload to each discovered web service (via the methods outlined below) to a list of common HTTP/S ports. For every response it receives, it will log the responding host IP so we can get a list of the vulnerable servers.

If there is a "SUCCESS", this means that some web service has received the request, was vulnerable to the log4j exploit and sent a request to our TCP server.

The tool does not send any exploits to the vulnerable hosts, and is designed to be as passive as possible.

Latest Release

Platform Binary Checksum
Windows SHA256
Linux SHA256
MacOS SHA256


version 0.3.3

  • added an option to scan a custom list of ports --ports=1555,3030,8000,8080,9003
  • added a --connect-timeout flag to control the time to wait for a response from each port while scanning
  • various bug fixes



In this example we run the tool against the subnet (which contains a vulnerable server).

The tools does the following:

  1. Open a server on the default address (the local IP at port 5555)
  2. POssibly, add the flag --ports=top100 to adjust the scan to include the top 100 ports
  3. The tool then tries all ports on each of the IP addresses in the subnet. If a remote server responds at one of the ports, the request is sent to it.
  4. If the server is vulnerable, a callback is made to our server (created on step 1) and the IP address of the remote is logged
  5. After all IP addresses in the subnet are scanned, the server waits for a default duration of 10s for any lingering connections and closes down
  6. The tools displays the summary of the connections made:
    1. Requests sent to responding remote servers (and the status code they responded with)
    2. Any callback address made to our server

Important Note about Assumptions

  • If a callback happened, this means that a vulnerable server exists, the exploit worked and it initiated a callback. However.
  • A good rule of thumb, if the callback IP address is not in the subnet scanned, the vulnerable server is behind a NAT (e.g. a docker container responds with its own IP address, not the host running the docker)
  • The network traffic created by the tool might be classified as malicious by security products, or cause a lot of noise for monitoring services
  • The server created by the tool assumes that it is open to receive inbound traffic. That means that opening a FW inbound rule on the host running the scan is needed.

Basic usage

Download the tool for your specific platform (Windows, Linux or Mac), to run the tool, make sure port 5555 on the host is available (or change it via configuration), and specify the subnet to scan (it is possible to configure a separate server:port combination using the --server flag):

log4jScanner.exe scan --cidr

This will test the top 10 HTTP\S ports on the hosts in the subnet, print any vulnerable hosts to the screen, and generate a log + summary CSV in the same location as the binary including all the attempts (both vulnerable and non-vulnerable).

In order to identify which hosts are vulnerable just look up the word SUCCESS in the log, you can grep the log for the keywork SUCCESS to get just the results. Also, the tool generates a CSV file containing all the results, filter on vulnerable to get the vulnerable hosts.

Additional usage options

You can use the tool to test for the top 100 HTTP\S ports, insert a single custom port, a range of ports, or a list of custom ports (limited up to 1024 ports).

log4jscanner.exe scan --cidr --ports=top100
log4jscanner.exe scan --cidr --ports=9000
log4jscanner.exe scan --cidr --ports=9000:9005
log4jscanner.exe scan --cidr --ports=1555,3030,8000,8080,9003

it is possible to use a non-default configuration for the callback server

log4jscanner.exe scan --cidr --server=

if you wish to disable the callback server, use --noserver

Available flags

  • --nocolor provide output without color
  • --ports either top10 (default), top100 (list of the 100 most common web ports), a custom single port, a range of ports, or a list of custom ports
  • --noserver only scan, do not use a local callback server
  • --timeout=10 set the server shutdown timeout to 10 seconds
  • --connect-timeout=2000 set the response timeout for each scanned port to 2000 milliseconds

Methods Used

Currently, the tool uses the following areas to try and send an exploit:

  • Various X-* headers (we plan to enlarge these in the future)
  • URL parameter encoding
  • User-Agent

Test setup

In order to test your environment, you can use the included docker images to launch vulnerable applications.

Run the docker compose in here:

docker-compose up -d

This will provide you with a container vulnerable on port 8080 for HTTP and port 8443 for HTTPS.

Alternatively, you can also run this:

  1. Vuln. target:
    1. docker run --rm --name vulnerable-app -p 8080:8080
  2. spin a server for incoming requests
    1. log4jScanner scanip --cidr DOCKER-SUBNET
  3. send a request to the target, with the server details
    1. sends a request to the vuln. target, with the callback details of the sever
    2. once gets a callback, logs the ip of the calling request


We welcome contributions, please submit a PR or contact us via


log4jScanner provides the ability to scan internal subnets for vulnerable log4j web services







No packages published