Spring Boot Penetrationstest: Actuator-Endpunkte, Spring4Shell und Java-Deserialisierungssicherheit

Spring Boot ist das dominante Java-Web-Framework fuer Enterprise-Anwendungen und Microservices und verarbeitet taeglich Milliarden von Anfragen in Banken, Versicherungen, Behörden und globalen Konzernen. Die hohe Verbreitung macht Spring-Boot-Anwendungen zu besonders attraktiven Angriffszielen. CVE-2022-22965 (Spring4Shell, CVSS 9.8) eroeffnete Remote-Code-Execution in fast allen Spring-MVC-Anwendungen auf JDK 9+. CVE-2021-44228 (Log4Shell) betraf alle Anwendungen, die Log4j 2 einsetzen -- was auf den meisten Java-Stacks der Fall war. Exponierte Spring-Boot-Actuator-Endpunkte sind bis heute eine der haeufigsten Fehlkonfigurationen in Unternehmensumgebungen.

Spring Boot Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

Warum Spring-Boot-Anwendungen spezialisierte Sicherheitspruefungen benoetigen

Spring Boot vereinfacht die Java-Anwendungsentwicklung drastisch durch Auto-Konfiguration, Starter-Dependencies und integrierte Produktions-Tooling. Genau diese Komfort-Features eroeffnen aber Sicherheitsrisiken: Die Spring-Boot-Actuator-Endpunkte, die Betriebszustand, Metriken und Konfiguration exponieren, sind bei falscher Konfiguration ohne Authentifizierung zugaenglich und liefern Angreifern vollstaendige interne Einblicke. Das Spring-Oekosystem ist gross und komplex -- Spring Security, Spring Data, Spring Cloud, Spring Batch -- jedes Modul hat eigene Sicherheitskonfigurationen, die korrekt zusammenpassen muessen. Die Java-Deserialisierungsproblematik (Apache Commons Collections, ROME, Spring-spezifische Gadget-Chains) bleibt ein dauerhaftes Risiko in Java-Enterprise-Umgebungen.

CVE-2022-22965 (Spring4Shell, CVSS 9.8): Eine der kritischsten Java-Schwachstellen der letzten Jahre. Spring-MVC- und Spring-WebFlux-Anwendungen auf JDK 9+ waren durch eine Umgehung des DataBinder-ClassLoader-Filterings anfaellig fuer Remote-Code-Execution. Ein Angreifer konnte ohne Authentifizierung eine Webshell auf dem Server deployen. Betrifft Spring Framework 5.2.x vor 5.2.20 und 5.3.x vor 5.3.18.
CVE-2021-44228 (Log4Shell, CVSS 10.0): Die kritischste Java-Schwachstelle aller Zeiten -- Log4j 2's JNDI-Lookup-Feature erlaubte Remote-Code-Execution durch eine einzige manipulierte Log-Nachricht. Alle Spring-Boot-Anwendungen, die Log4j 2 (statt Logback) oder abhaengige Bibliotheken mit Log4j 2 nutzten, waren betroffen. Viele Anwendungen sind noch nicht vollstaendig bereinigt.
CVE-2023-20861 (Spring Expression Language DoS, CVSS 6.5): Spring-Security-Anwendungen, die SpEL-Ausdruecke aus Benutzerinput auswerteten, waren durch Regular-Expression-basierte Denial-of-Service anfaellig. SpEL (Spring Expression Language) ist in Spring Security fuer Pre/Post-Authorize-Annotationen, Spring Data Queries und Spring Batch konfigurierbar.
CVE-2024-22243 (UriComponentsBuilder SSRF): Spring Framework's UriComponentsBuilder war anfaellig fuer Server-Side-Request-Forgery bei bestimmten URL-Parsing-Mustern. Betrifft Spring Framework vor 6.1.4 und 6.0.x vor 6.0.17. Besonders relevant fuer Anwendungen, die externe URLs verarbeiten und weiterleiten.
Exponierte Spring-Boot-Actuator-Endpunkte: /actuator/env exponiert alle Umgebungsvariablen (inkl. Datenbankpasswoerter und API-Schluessel); /actuator/heapdump liefert einen vollstaendigen Java-Heap-Dump mit allen In-Memory-Daten (Passwoerter, Tokens, Benutzerdaten); /actuator/loggers ermoeglicht dynamische Log-Level-Aenderung; /actuator/shutdown kann die Anwendung stoppen.
Java-Deserialisierung und Gadget-Chains: Java-RMI, JMX und HTTP-Endpunkte die serialisierte Java-Objekte verarbeiten, sind anfaellig fuer Deserialisierungs-Angriffe. ysoserial und JRMPClient demonstrieren verfuegbare Gadget-Chains. In Spring-Umgebungen sind besonders Apache Commons Collections, ROME und Groovy-basierte Chains verbreitet.
Fehlkonfigurierte Spring Security: Spring Security ist maechtig, aber die Konfiguration ist komplex. Haeufige Fehler: antMatcher() vs. mvcMatcher() Verhalten-Unterschiede (gelten seit Spring Security 5.8 behoben), CSRF deaktiviert fuer REST-APIs, unsichere CORS-Konfiguration, fehlende Method-Level-Security (@PreAuthorize) als Defense-in-Depth.

Was beim Spring Boot Penetrationstest geprueft wird

Actuator-Endpunkt-Analyse: Vollstaendige Enumeration aller /actuator/*-Endpunkte; Test ob /env, /heapdump, /threaddump, /loggers, /beans, /mappings, /shutdown ohne Authentifizierung zugaenglich sind; Pruefung der management.endpoints.web.exposure.include-Konfiguration.
Spring4Shell-Anfaelligkeit (CVE-2022-22965): Pruefung der Spring-Framework-Version; Test ob DataBinder-basierte RCE-Exploits anwendbar sind; Pruefung ob JDK-Version und Tomcat-Konfiguration die Angriffsbedingungen erfuellen; Verifizierung der Patch-Version.
Log4Shell-Nachweis (CVE-2021-44228): Pruefung ob Log4j 2 in der Abhaengigkeitsliste oder als Transitivabhaengigkeit vorhanden ist; Test ob JNDI-Lookups in Log-Nachrichten aktiv sind; Nachweis auch fuer Log4j2-Wrapper-Bibliotheken.
Spring-Expression-Language (SpEL) Injection: Test ob Benutzerinput in SpEL-Ausdruecke fliesst (@Query, @PreAuthorize mit dynamischen Ausdruecken, SpelExpressionParser); Test auf Code-Injection und DoS-Anfaelligkeit (CVE-2023-20861).
Java-Deserialisierungs-Schwachstellen: Test ob HTTP-Endpunkte serialisierte Java-Objekte akzeptieren; Analyse des Classpaths auf bekannte Deserialisierungs-Gadget-Chain-Bibliotheken (Commons Collections, ROME, Spring); JMX und RMI Exposition.
Spring Security Konfigurationsaudit: Vollstaendige Analyse der SecurityConfiguration-Klasse; URL-Pattern-Matching-Schwachstellen; CSRF-Konfiguration; Method-Level-Security (@Secured, @PreAuthorize, @PostAuthorize); Session-Management und concurrent-session-Limits.
Dependency-Audit (Maven/Gradle): Scan von pom.xml oder build.gradle gegen NVD und Maven Central Security Advisory; Identifikation veralteter Spring-Framework-, Spring-Boot- und Spring-Security-Versionen; transitive Abhaengigkeiten wie Apache Commons, Jackson, Netty.
SSRF-Tests via UriComponentsBuilder (CVE-2024-22243): Test ob URL-Verarbeitung mit UriComponentsBuilder Anfaelligkeit zeigt; Pruefung auf interne Infrastruktur-Erreichbarkeit; Spring-Version-Verifikation.
Jackson-Deserialisierung und polymorphe Typen: Test ob Jackson ObjectMapper mit aktiviertem Default-Typing ('enableDefaultTyping()' oder '@JsonTypeInfo(use=Id.CLASS)') anfaellig fuer Deserialisierungs-Angriffe ist; Pruefung ob CVE-2019-14439-aehnliche Gadget-Chains anwendbar sind.
Microservice-spezifische Sicherheit (Spring Cloud): Spring Cloud Config Server Exposition; Feign-Client-SSRF; Hystrix-Dashboard-Exposition; Eureka-Server-Authentifizierung; Spring Cloud Gateway Route-Manipulation.

Beispiel-Befund

Kritisch

Exponierter /actuator/env-Endpunkt gibt Datenbankpasswoerter und API-Schluessel aus

Der Spring-Boot-Actuator-Endpunkt GET /actuator/env ist ohne Authentifizierung zugaenglich (management.endpoints.web.exposure.include=* in application.properties). Die Antwort enthaelt alle Umgebungsvariablen und Konfigurationsparameter im Klartext: Datenbankpasswoerter, AWS-Access-Keys, JWT-Secrets, Stripe-API-Schluessel und interne Service-URLs. Zusaetzlich exponiert /actuator/heapdump einen 2,3 GB grossen Heap-Dump mit vollstaendigen In-Memory-Benutzerdaten und Session-Tokens. Keine Authentifizierung, keine IP-Einschraenkung.

Behebung: Sofortige Absicherung: management.endpoints.web.exposure.include auf 'health,info' beschraenken (Minimum fuer Betrieb); management.endpoint.env.enabled=false explizit setzen; Spring Security-Konfiguration fuer Actuator-Endpunkte erfordern (actuator-security-config mit .requestMatchers("/actuator/**").hasRole("ACTUATOR")). Alle exponierten Secrets sofort rotieren. Management-Port auf separaten, nicht oeffentlichen Port verlegen (management.server.port=8081) und via Netzwerk-Policy einschraenken.

Referenz: CVE-2022-22965 (Spring4Shell, CVSS 9.8) · CVE-2021-44228 (Log4Shell, CVSS 10.0) · CVE-2023-20861 (SpEL DoS) · OWASP A05:2021 Security Misconfiguration · CWE-200 Exposure of Sensitive Information

Spring Boot Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

Spring Boot Pentest Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Haeufige Fragen zum Spring Boot Penetrationstest

Sind meine Spring-Boot-Actuator-Endpunkte sicher konfiguriert?

Die haeufigste Fehlkonfiguration ist 'management.endpoints.web.exposure.include=*' in application.properties, was alle Actuator-Endpunkte ohne Authentifizierung exponiert. Sichere Konfiguration: (1) Nur benoetigt Endpunkte aktivieren: 'management.endpoints.web.exposure.include=health,info'; (2) Sensitiven Endpunkte mit Spring-Security absichern; (3) Management-Port von Anwendungs-Port trennen und Netzwerkzugriff einschraenken; (4) /actuator/heapdump und /actuator/env explizit deaktivieren wenn nicht benoetigt.

Ist Spring4Shell (CVE-2022-22965) noch relevant fuer aktuelle Spring-Boot-Anwendungen?

Spring4Shell ist in Spring Framework 5.2.20+, 5.3.18+ und Spring Boot 2.5.12+, 2.6.6+ gepatcht. Anwendungen, die diese oder neuere Versionen verwenden und korrekt konfiguriert sind (Tomcat 9.0.62+, JDK 9+), sind nicht mehr anfaellig. Relevant bleibt: (1) Aeltere Anwendungen, die nicht aktualisiert wurden; (2) Anwendungen mit Custom-Deserialisierungslogik; (3) Anwendungen in Unternehmen, wo Update-Zyklen lang sind. Matproof prueft die Spring-Framework-Version und Exploitierbarkeit.

Wie pruefe ich ob meine Anwendung noch Log4j 2 (Log4Shell-anfaellig) verwendet?

Pruefung in Maven: 'mvn dependency:tree | grep log4j'; in Gradle: './gradlew dependencies | grep log4j'. Auch Transitivabhaengigkeiten pruefen: viele Bibliotheken bringen log4j-core als Transitivabhaengigkeit mit. Wenn Log4j 2 verwendet wird: Update auf 2.17.1+ (Java 8) oder 2.12.4+ (Java 7). Alternativ: log4j2.formatMsgNoLookups=true als JVM-Argument (nur partieller Schutz, nicht empfohlen als alleinige Massnahme).

Was sind die Sicherheitsimplikationen von Spring Expression Language (SpEL)?

SpEL ist eine maechtige Ausdruckssprache, die in Spring-Annotations (@PreAuthorize, @PostAuthorize, @Query), Spring Batch und benutzerdefinierten Komponenten verwendet wird. Das Sicherheitsrisiko entsteht, wenn Benutzerinput in SpEL-Ausdruecken ausgewertet wird: (1) ReDoS via Regex-basierte Ausdruecke (CVE-2023-20861); (2) Informations-Exfiltration bei unkontrollierten SpEL-Ausdruecken; (3) In seltenen Faellen Code-Execution. Best Practice: SpEL-Ausdruecke statisch definieren, nie aus Benutzerinput konstruieren.

Wie sichert man Spring Security gegen URL-Pattern-Matching-Angriffe ab?

Spring Security hat das Verhalten von antMatcher() und mvcMatcher() in verschiedenen Versionen unterschiedlich definiert -- das hat zu Sicherheitsluecken durch unterschiedliche URL-Aufloesung in SecurityFilter vs. DispatcherServlet gefuehrt. Seit Spring Security 5.8 und 6.x ist HttpSecurity.authorizeHttpRequests() mit mvcMatchers() der empfohlene Weg. Wichtig: Immer die spezifischste Regel zuletzt oder mit anyRequest() abschliessen; keine URL-Muster verwenden, die durch Trailing-Slashes oder Pfad-Traversal umgangen werden koennen.

Welche Maven-Abhaengigkeiten in Spring-Boot-Projekten sind besonders risikoreich?

Hoeherriskante Abhaengigkeiten: (1) Apache Commons Collections (Deserialisierungs-Gadget-Chains); (2) Jackson-Databind (polymorphe Deserialisierung -- jackson-databind < 2.14.0 mit Default-Typing); (3) Netty (HTTP-Request-Smuggling, buffer overflow -- aktuelle Patches pruefen); (4) Snakeyaml (YAML-Deserialisierungs-Angriffe -- snakeyaml < 2.0); (5) Jedis/Lettuce (Redis-Client-Sicherheit); (6) Spring-Cloud-Config (Server-side-include). 'mvn dependency-check:check' (OWASP Dependency Check) fuer automatisierten CVE-Scan.

Wie erkenne ich Java-Deserialisierungs-Schwachstellen in Spring-Boot-Anwendungen?

Indikatoren fuer Deserialisierungs-Risiken: (1) Java-RMI-Endpunkte (Port 1099); (2) HTTP-Endpunkte, die 'Content-Type: application/x-java-serialized-object' akzeptieren; (3) Apache Commons Collections, ROME, Groovy oder Spring-AOP im Classpath (Gadget-Chain-Voraussetzungen); (4) JMX aktiviert und oeffentlich zugaenglich; (5) Custom-Deserializer ohne Typ-Whitelist. Tools: ysoserial fuer Chain-Generation; Burp Suite Java-Deserialization-Scanner; serialkiller fuer Classpath-Analyse.

Wie oft sollte eine Spring-Boot-Microservice-Architektur einem Penetrationstest unterzogen werden?

Fuer Spring-Boot-Microservice-Architekturen empfehlen sich: (1) Service-spezifische Pentests bei jedem Major-Service-Release; (2) Architektur-weite Tests bei Einfuehrung neuer Service-Kommunikationsmuster; (3) Mindestens jaehrlicher Vollpentest aller Produktions-Services; (4) Kontinuierliches Dependency-Scanning (Matproof Sentinel, OWASP Dependency Check in CI). Fuer Spring-Boot-Anwendungen im Finanzsektor (DORA Art. 24) gilt zusaetzlich der regulatorische Pentestpflicht-Rahmen.

Vertiefen — verwandte Artikel aus unserem Blog

Spring Boot Penetrationstest jetzt starten

Schutzen Sie Ihre Spring-Boot-Anwendung vor Actuator-Exposition, Spring4Shell und Java-Deserialisierungsrisiken. Audit-bereiter Bericht auf Deutsch fuer Enterprise-Compliance.