Sechs Advisories in 48 Stunden: Wenn das Java-Fundament wackelt
Am 19. und 20. März 2026 veröffentlichte das Spring-Team in schneller Folge sechs Security Advisories, die das gesamte Spring-Ökosystem durchziehen – von Spring Security über Spring Boot bis hin zu Spring Cloud Config und dem Spring Framework selbst. Die Bandbreite reicht von einer kritischen Header-Schwachstelle über Authentication-Bypasses in Spring Boot Actuator bis hin zu Path-Traversal-Angriffen auf Konfigurationsserver.
Für Unternehmen, die auf Spring setzen – und das sind in Deutschland sehr viele – bedeutet diese geballte Offenlegung: Sofortiges Handeln ist erforderlich. Denn während einzelne CVEs im Tagesgeschäft untergehen können, entfaltet die Kombination dieser sechs Schwachstellen ein Bedrohungspotenzial, das weit über die Summe seiner Teile hinausgeht.
CVE-2026-22732: Die unsichtbare Lücke in Spring Security (Kritisch)
Die gravierendste der sechs Schwachstellen trägt die Kennung CVE-2026-22732 und betrifft Spring Security – genauer gesagt das Modul spring-security-web. Der Fehler klingt zunächst unspektakulär: Wenn eine Anwendung die Content-Length über bestimmte Methoden setzt, werden anschließend konfigurierte HTTP-Sicherheitsheader stillschweigend aus der Response entfernt.
In der Praxis bedeutet das: Header wie X-Frame-Options, Content-Security-Policy, X-Content-Type-Options oder Strict-Transport-Security verschwinden, ohne dass Entwickler oder Monitoring es bemerken. Die Anwendung antwortet weiterhin mit Status 200, die Geschäftslogik funktioniert einwandfrei – aber der Browser des Nutzers erhält keine Sicherheitsanweisungen mehr.
Die Konsequenzen sind erheblich: Ohne X-Frame-Options wird Clickjacking möglich. Ohne Content-Security-Policy können Cross-Site-Scripting-Angriffe (XSS) durchschlagen, die eigentlich blockiert worden wären. Ohne X-Content-Type-Options kann der Browser MIME-Types erraten und potenziell schädliche Inhalte ausführen.
Betroffene Versionen: Spring Security 4.2.x, 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x und 6.4.x – also praktisch jede produktiv eingesetzte Version der letzten Jahre.
Warum diese CVE besonders tückisch ist
Anders als ein klassischer Remote-Code-Execution-Bug erzeugt CVE-2026-22732 keine Fehlermeldungen, keine Abstürze, keine offensichtlichen Symptome. Die Schwachstelle ist vollkommen lautlos. Automatisierte Schwachstellenscanner, die nur auf Statuscodes und Response-Bodies achten, übersehen sie. Erst ein gezielter Header-Check – etwa über curl -I oder spezialisierte Security-Scanner – macht das Problem sichtbar.
Für Angreifer ist das ein ideales Szenario: Die Anwendung läuft produktiv, das Entwicklungsteam hat keine Auffälligkeiten im Monitoring, und gleichzeitig fehlen kritische Schutzschichten im Browser des Endnutzers.
CVE-2026-22731 und CVE-2026-22733: Authentication-Bypass über Spring Boot Actuator (Hoch)
Die beiden nächsten Schwachstellen betreffen Spring Boot Actuator – jene Komponente, die Entwicklungsteams für Health-Checks, Metriken und Betriebsüberwachung einsetzen. Actuator-Endpunkte haben ein eigenes Sicherheitsmodell, das in der Regel weniger restriktiv ist als das der eigentlichen Geschäftsanwendung. Genau hier setzen CVE-2026-22731 und CVE-2026-22733 an.
CVE-2026-22731 betrifft Spring Boot 3.4.x und speziell die Auto-Konfiguration von Actuator-Endpunkten. Wenn eine Anwendung eigene Endpunkte unter bestimmten Subpfaden registriert, die sich mit Actuator-Pfaden überschneiden, greift die permissive Actuator-Sicherheitskonfiguration – auch dann, wenn der Anwendungsendpunkt eigentlich eine Authentifizierung erfordert. Ein unauthentifizierter Angreifer kann so auf geschützte Endpunkte zugreifen.
CVE-2026-22733 erweitert dieses Problem auf die CloudFoundry-Integration von Spring Boot Actuator. Hier betrifft die Schwachstelle die Versionen 1.5.x, 2.5.x, 2.7.x, 3.2.x, 3.3.x und 3.4.x. Bei nicht registrierten Endpunktpfaden versagt die Sicherheitsvalidierung, sodass interne Managementdaten ohne Berechtigung abrufbar werden.
In der Praxis können Angreifer über diese Lücken an Health-Status-Informationen, Konfigurationsdetails, Umgebungsvariablen und – im schlimmsten Fall – an sensible Betriebsdaten gelangen, die für gezielte Folgeangriffe nutzbar sind.
CVE-2026-22739: Path Traversal und SSRF in Spring Cloud Config (Hoch)
Spring Cloud Config Server ist die zentrale Konfigurationsinstanz in Microservice-Architekturen. Hier werden Datenbankverbindungen, API-Schlüssel, Feature-Flags und weitere sensible Konfigurationsdaten verwaltet. CVE-2026-22739 mit einem CVSS-Score von 8.6 ermöglicht es Angreifern, über Path-Traversal-Techniken aus dem vorgesehenen Konfigurationsverzeichnis auszubrechen.
Die Folgen sind gravierend: Angreifer können lokale Dateien auf dem Konfigurationsserver lesen – darunter potenziell application.yml-Dateien mit Datenbankpasswörtern, private Schlüssel oder Secrets, die für andere Services bestimmt sind. Darüber hinaus können sie den Server als Sprungbrett für Server-Side-Request-Forgery-Angriffe (SSRF) nutzen und damit interne Netzwerkressourcen erreichen, die von außen nicht zugänglich sein sollten.
Betroffene Versionen: Spring Cloud Config 3.0.x, 3.1.x, 4.1.x und 4.2.x.
Für Unternehmen, die Spring Cloud Config in ihrer Microservice-Landschaft einsetzen, ist diese Schwachstelle besonders brisant: Der Konfigurationsserver kennt die Geheimnisse aller angeschlossenen Services. Ein kompromittierter Config-Server bedeutet potenziell kompromittierte gesamte Infrastruktur.
CVE-2026-22737 und CVE-2026-22735: Framework-Schwachstellen im Kern
CVE-2026-22737 (Mittel) betrifft spring-webmvc und erlaubt Path-Traversal-Angriffe über Script-Template-Views. Wenn Anwendungen Java-Scripting-Engine-basierte Template-Views verwenden (etwa Nashorn oder GraalJS), können Angreifer Dateien außerhalb der vorgesehenen Template-Verzeichnisse lesen. Betroffen sind Spring Framework 4.3.x, 5.3.x und 6.1.x.
CVE-2026-22735 (Niedrig) ermöglicht Server-Sent-Events-Injection durch unvalidierte Newline-Zeichen in id- und event-Feldern. Obwohl die Schwere als niedrig eingestuft wird, kann diese Schwachstelle in Anwendungen, die SSE für Echtzeit-Updates nutzen, zur Manipulation von Event-Streams missbraucht werden.
Das EOL-Problem: Wenn Patches nicht mehr ankommen
Ein besonders kritischer Aspekt dieser Schwachstellenwelle: Viele der betroffenen Versionen befinden sich bereits im End-of-Life-Status. Offizielle Patches gibt es ausschließlich für aktiv gepflegte Release-Lines. Unternehmen, die noch auf Spring Boot 2.x oder Spring Framework 5.x setzen – und davon gibt es im deutschen Mittelstand viele – stehen vor einem Dilemma:
Entweder sie aktualisieren auf Spring Boot 3.x und Spring Framework 6.x, was aufgrund des Wechsels von javax.* zu jakarta.* einen erheblichen Migrationsaufwand bedeutet. Oder sie bleiben auf der veralteten Version und nehmen wissentlich ungepatchte Schwachstellen in Kauf. Drittanbieter wie HeroDevs bieten Extended Support für EOL-Versionen an, was jedoch zusätzliche Kosten verursacht.
Sofortmaßnahmen: Was Java-Teams jetzt priorisieren müssen
1. Bestandsaufnahme durchführen
Identifizieren Sie zunächst alle Anwendungen in Ihrer Organisation, die Spring-Komponenten einsetzen. Prüfen Sie pom.xml oder build.gradle auf die exakten Versionen von spring-security-web, spring-boot-actuator, spring-cloud-config-server, spring-webmvc und spring-web.
2. CVE-2026-22732 mit höchster Priorität patchen
Die kritische Spring-Security-Schwachstelle muss sofort adressiert werden. Aktualisieren Sie auf die neueste gepatchte Version von Spring Security. Führen Sie anschließend einen Header-Check auf allen produktiven Endpunkten durch:
curl -I https://ihre-anwendung.de/api/endpoint
Prüfen Sie, ob X-Frame-Options, Content-Security-Policy, X-Content-Type-Options und Strict-Transport-Security in der Response enthalten sind.
3. Actuator-Endpunkte absichern
Überprüfen Sie die Konfiguration Ihrer Actuator-Endpunkte. Stellen Sie sicher, dass management.endpoints.web.exposure.include nur die wirklich benötigten Endpunkte freigibt. Aktivieren Sie explizite Authentifizierung für alle Actuator-Pfade und trennen Sie den Management-Port vom Anwendungsport.
4. Spring Cloud Config Server isolieren
Wenn Sie Spring Cloud Config einsetzen, aktualisieren Sie den Server umgehend. Beschränken Sie den Netzwerkzugriff auf den Config-Server auf ausschließlich autorisierte Microservices. Prüfen Sie, ob Secrets im Config-Server durch Verschlüsselung geschützt sind – Spring Cloud Config bietet native Encrypt/Decrypt-Funktionalität.
5. Migrationsstrategie für EOL-Versionen planen
Wenn Ihre Anwendungen noch auf Spring Boot 2.x oder Spring Framework 5.x laufen, ist jetzt der Zeitpunkt, die Migration auf aktuelle Versionen konkret zu planen. Jede weitere ungepatchte Schwachstelle erhöht das Risiko exponentiell.
Warum diese Schwachstellenwelle ein Weckruf ist
Sechs CVEs an zwei Tagen in einem der am weitesten verbreiteten Java-Frameworks – das ist kein Zufall, sondern Ausdruck einer systematischen Sicherheitsüberprüfung durch das Spring-Team und die Security-Community. Es zeigt aber auch, wie tief Schwachstellen in vermeintlich ausgereiften Frameworks stecken können.
Für Unternehmen im deutschen Mittelstand, die Java-basierte Geschäftsanwendungen betreiben, ist die Botschaft klar: Ein regelmäßiges, systematisches Schwachstellenmanagement ist keine Option, sondern Pflicht. Wer seine Dependencies nicht aktiv überwacht – etwa über Tools wie Dependabot, Snyk oder OWASP Dependency-Check – erfährt von solchen Schwachstellen erst, wenn es zu spät ist.
Die aktuelle NIS2-Gesetzgebung unterstreicht diese Notwendigkeit zusätzlich: Compliance-Anforderungen wie NIS2 fordern explizit ein dokumentiertes Schwachstellenmanagement. Unternehmen, die Spring-Anwendungen ohne systematisches Patch-Management betreiben, riskieren nicht nur technische Kompromittierung, sondern auch regulatorische Konsequenzen.
Wenn Sie Unterstützung bei der Absicherung Ihrer Java-Anwendungen oder bei der Entwicklung einer nachhaltigen Patch-Management-Strategie benötigen, stehen Ihnen die Experten von pleXtec gerne zur Verfügung. Sprechen Sie uns an – über unser Kontaktformular oder direkt per Telefon.
