Spring Boot Actuator Exploitation: A Security Researcher's Arsenal

Hook

A single misconfigured Actuator endpoint in your Spring Boot application can provide attackers with at least seven distinct paths to remote code execution—and most developers don't even realize these endpoints are exposed in production.

Context

Spring Boot Actuator revolutionized application monitoring by providing out-of-the-box management endpoints for metrics, health checks, and runtime configuration. The problem? Many developers deploy these endpoints to production without proper security controls, not understanding that /actuator/env, /actuator/restart, and /actuator/jolokia aren't just informational—they're administrative interfaces with powerful capabilities.

The pyn3rd/Spring-Boot-Vulnerability repository emerged as a practical response to this gap between perceived and actual security posture. While Spring Security documentation covers proper configuration, this repository takes the opposite approach: it demonstrates exactly what happens when Actuator endpoints are exposed without authentication. By documenting real-world attack chains used in penetration tests and security research, it serves as a wake-up call for developers who've left management.endpoints.web.exposure.include=* in their application.properties file.

Technical Insight

The repository's most valuable contribution is documenting attack chain escalation—showing how seemingly low-severity information disclosure through /actuator/env can chain into remote code execution. The progression follows a logical pattern: first, attackers enumerate exposed endpoints and extract configuration data including JDBC connection strings, then leverage write-enabled endpoints like /actuator/env to modify runtime properties, and finally trigger execution via /actuator/restart.

Consider the H2 database console exploitation path. When Spring Boot runs with an embedded H2 database and both /actuator/env and /h2-console are exposed, attackers can manipulate the JDBC URL to inject malicious payloads:

POST /actuator/env HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/json

{
  "name": "spring.datasource.hikari.connection-test-query",
  "value": "CREATE ALIAS EXEC AS 'String shellexec(String cmd) throws java.io.IOException {Runtime.getRuntime().exec(cmd);return \"success\";}';"
}

Followed by triggering the restart endpoint:

POST /actuator/restart HTTP/1.1
Host: vulnerable-app.com

This creates a SQL alias function that wraps Runtime.exec(), effectively transforming a database connection test into a shell command executor. The restart is critical—Spring Boot needs to reinitialize the datasource with the new connection-test-query property for the malicious SQL to execute.

The repository also demonstrates HikariCP datasource manipulation, a particularly clever technique. HikariCP, Spring Boot's default connection pool, allows setting arbitrary Java properties through its configuration. Attackers can leverage this to set system properties or manipulate the JVM environment:

POST /actuator/env HTTP/1.1
Content-Type: application/json

{
  "name": "spring.datasource.hikari.data-source-properties.dataSource.logWriter",
  "value": "com.zaxxer.hikari.util.PropertyElf.setTargetFromProperties"
}

The Jolokia exploitation path is equally sophisticated. Jolokia exposes JMX MBeans over HTTP/JSON, and when /actuator/jolokia is accessible, attackers gain full JMX control without needing RMI access. The repository documents how to invoke the createJNDIRealm method to establish JNDI connections to attacker-controlled LDAP servers, leading to arbitrary class loading and execution.

What makes these attack chains particularly dangerous is their stealth. Unlike traditional vulnerability exploitation that generates obvious error messages or crashes, these techniques abuse legitimate Spring Boot functionality. Application logs show normal Actuator usage, restart events appear as routine maintenance, and datasource reconfigurations look like standard operations. The MyBatis XXE exploitation documented in the repository exemplifies this—by manipulating mybatis.config-location through /actuator/env, attackers can point to external DTDs containing XML entity definitions that exfiltrate file contents or trigger SSRF attacks, all while appearing as configuration changes in audit logs.

The repository also covers the Logview actuator vulnerability (CVE-2021-21234), which demonstrates directory traversal through maliciously crafted log file paths. This shows how even custom Actuator endpoints, not just Spring's built-in ones, can introduce severe vulnerabilities when input validation is insufficient.

Gotcha

The repository's biggest limitation is its offensive-only focus. If you're a developer trying to secure your Spring Boot application, you won't find guidance here on proper Actuator configuration, authentication setup, or remediation strategies. There's no discussion of Spring Security configuration, no examples of properly secured endpoints using management.endpoints.web.exposure.include with specific endpoint lists, and no mention of management.server.port isolation techniques that expose Actuators on internal-only network interfaces.

The documentation also lacks version-specific context. Spring Boot has evolved significantly through versions 1.x, 2.x, and 3.x, with different default behaviors for Actuator endpoint exposure and security. The H2 console exploitation techniques documented may not work on newer Spring Boot versions where these endpoints require explicit enabling and authentication by default. Similarly, some documented techniques rely on specific library combinations—HikariCP behaviors, MyBatis configurations, or Jolokia presence—that won't be present in all Spring Boot applications. Without clear version matrices or dependency requirements, penetration testers may waste time attempting exploits against patched or incompatible targets.

Verdict

Use if: You're conducting security assessments or penetration tests against Spring Boot applications and need a quick reference for Actuator exploitation techniques. This repository is invaluable for red teams who need to demonstrate risk severity to development teams by showing complete attack chains from information disclosure to code execution. It's also useful for security training programs teaching developers about the dangers of misconfigured management endpoints through hands-on exploitation exercises. Skip if: You're looking for defensive security guidance or hardening recommendations for your Spring Boot applications—this repository won't help you fix vulnerabilities, only exploit them. Developers should instead consult Spring Security's official documentation, implement proper authentication on all Actuator endpoints, and use tools like Spring Boot Actuator Security Scanning to audit their configurations. Also skip if you need up-to-date CVE tracking with version-specific patches, as this repository is more of a techniques catalog than a vulnerability database.