This scanner will recursively scan paths including archives for spring libraries and classes that are vulnerable to CVE-2022-22965 and CVE-2022-22963.

  • By null
  • Last update: Nov 9, 2022
  • Comments: 3


This scanner will recursively scan paths including archives for spring libraries and classes that are vulnerable to CVE-2022-22965 and CVE-2022-22963.

Currently the allow list defines non exploitable versions, in this case spring-beans 5.3.18 and 5.2.20 and spring cloud function context 3.2.3

Scanning multi layered archives


  • scans recursively through all archives in archives in archives in archives etc
  • scan for known spring libraries (sha256 hash)
  • scan for CachedIntrospectionResults.class files
  • fast
  • show related CVE's found by version
  • detects class files with different extensions (eg .ezclass)
  • scans through all layers of local- and remote docker images
  • binary versions available for Windows, Linux and MacOS


CVE References





$ spring4shell-scanner.exe {target-path}

Linux / OSX / FreeBSD

$ spring4shell-scanner {target-path}

Docker containers

Using the tool you can now also scan containers:

$ ./spring4shell-scanner scan-image logstash:7.16.1

or local images:

$ ./spring4shell-scanner scan-image --local {sha256|pattern}
$ ./spring4shell-scanner scan-image --local log4shell:latest
$ ./spring4shell-scanner scan-image --local 4949add9e671

# scan all local images
$ ./spring4shell-scanner scan-image --local 



$ spring4shell-scanner.exe patch {target-path}

Linux / OSX / FreeBSD

spring4shell-scanner patch {target-path}

Build from source


For development

$ git clone ""
$ go build -o ./.builds/spring4shell-scanner ./main.go

Copyright and license

Code and documentation copyright 2022 Remco Verhoef (DTACT).

Code released under the MIT license.



  • 1

    Included matching for CVE-2022-22963

    DISCLAIMER: I have not done enough research to claim that this will include all vulnerable versions of Spring Cloud Functions.

    Working assumptions have been:

    • The file RoutingFunction.class is the culprit that was patched recently [1]. It shows that a change + test was added to mitigate access to the Java runtime via HTTP headers

    • I pulled all versions from Maven central and scanned for .jar files that have the above file packaged.

      • This does not take into account that some versions might have been not vulnerable
      • It does not take into account that in the past (due to refactoring) a similar bug was present in a different file


  • 2

    Scan works, but output unworkable

    The scanner seems to work just fine. However, the output this tool produces isn't really suitable for further processing:

    1. There's no built-in feature for logging to a file, which seems like it should be one of the primary use-cases.
    2. There doesn't seem to be a way to log only the vulnerable stuff. I.e. there's no --quiet parameter. It outputs thousands of lines, one for each file scanned. But I think most people are only interested in the actual vulnerable files. Of course you can pipe the output to a filter (i.e. filter on "[!]"), but then there's still the problem mentioned at point 4 below.
    3. The --json parameter doesn't seem to work. I still get the regular output.
    4. The output text contains all kinds of control characters. Even when using the --disable-colour parameter. So redirecting the output to a text file results in a non-plain text file.

    I wanted to love this scanner, but in its current state i cannot recommend it.

    Note: I tested the Windows version

  • 3

    Adding Logging to File of the findings

    Current scanner send its output to stdout (Status + findings)

    a scan job can output hundreds and hundreds os status line ("Checked 33 files in 00h:00m:01s, average rate is: 1401 files/min"), as well as a lot of findings

    Findings will get lost when scanning big servers outputting more than the console buffer


    • Add a logging function to files for the finding only
    • If no parameter specified, still log to file by default
    • Output the finding both to the console & to the log file