Kurzfassung
Spring bringt gleich vier kritische Schwachstellen mit. Betroffen sind Spring MVC, Spring WebFlux und mehrere Teile von Spring Security. Für Unternehmen im DACH-Raum ist das vor allem dort relevant, wo Java-Services mit Spring im produktiven Betrieb laufen und extern erreichbar sind.
Die Risiken sind unterschiedlich. CVE-2026-47890 kann Stream-Inhalte bei Server-Sent Events verfälschen. CVE-2026-47891 setzt auf fehlerhafte Speicherbegrenzung bei XML-Verarbeitung. CVE-2026-59270 öffnet den eingebetteten LDAP-Dienst unnötig weit ins Netz. CVE-2026-59354 kann bei aktivierter Dynamic Client Registration zu XSS, Rechteausweitung oder SSRF führen.
Was ist passiert?
Die NVD listet vier getrennte, aber zusammengehörige Sicherheitsprobleme rund um das Spring-Ökosystem. Alle vier sind als kritisch eingestuft. Das ist kein kosmetischer Befund, sondern ein Hinweis auf echte Angriffsfläche in verbreiteter Infrastruktur.
Wer Spring für Webanwendungen, Authentifizierung oder interne Test- und Entwicklungsdienste nutzt, sollte die betroffenen Versionen sofort gegen die eigene Software-Landschaft spiegeln. Gerade in deutschen Unternehmen hängen an Spring oft zentrale Fachanwendungen, interne APIs und Login-Strecken. Ein einzelner verwundbarer Dienst reicht dann aus, um interne Daten oder Token in Gefahr zu bringen.
Technische Details
CVE-2026-47890 betrifft Spring MVC und Spring WebFlux beim Einsatz von Server-Sent Events zusammen mit View-Fragments. Dabei kann ein Stream beschädigt werden. Laut NVD sind Spring Framework 7.0.0 bis 7.0.8 sowie 6.2.0 bis 6.2.19 betroffen.
CVE-2026-47891 betrifft Spring WebFlux in Kombination mit dem Aalto XML Processor. Die Anwendung setzt die Grenze maxInMemorySize beim Parsen von XML nicht korrekt durch. Genannt werden Spring Framework 7.0.0 bis 7.0.8, 6.2.0 bis 6.2.19, 6.1.0 bis 6.1.28, 6.0.0 bis 6.0.30, 5.3.0 bis 5.3.49 sowie 5.2.25.RELEASE und älter.
CVE-2026-59270 steckt in Spring Securitys eingebettetem UnboundID LDAP Server, genauer im UnboundIdContainer. Der Dienst legt nach Angaben der NVD immer ein administratives Credential an und bindet seinen Listener an alle verfügbaren Netzwerkschnittstellen. Betroffen sind Spring Security 7.1.0, 7.0.0 bis 7.0.6, 6.5.0 bis 6.5.11, 6.4.0 bis 6.4.18, 5.8.0 bis 5.8.27 und 5.7.0 bis 5.7.25.
CVE-2026-59354 betrifft das OAuth2 Authorization Server-Modul von Spring Security in den Versionen 7.0.0 bis 7.0.4, wenn Dynamic Client Registration ausdrücklich aktiviert ist. Die Registrierung prüft bestimmte Metadatenfelder unzureichend. Mit einem gültigen Initial Access Token kann ein Angreifer einen manipulierten Client anlegen. Je nach Konfiguration kann das in Stored XSS, Rechteausweitung oder SSRF münden.
Wer ist betroffen?
Betroffen sind vor allem Betreiber von Java-Anwendungen, die Spring Framework oder Spring Security einsetzen. Das reicht von internen Fachanwendungen bis zu öffentlich erreichbaren Web-APIs. Für viele DACH-Unternehmen ist Spring ein Standardbaustein; genau deshalb trifft es oft mehr Systeme, als die erste Asset-Liste vermuten lässt.
Besonders relevant sind Umgebungen mit WebFlux, SSE, XML-Verarbeitung, eingebettetem LDAP oder OAuth2-Client-Registrierung. Wer solche Funktionen gar nicht nutzt, ist nicht automatisch fein raus. Oft liegen die Komponenten trotzdem im Build oder im Laufzeitpaket und werden erst bei genauer Prüfung sichtbar.
Für Privatnutzer ist das Thema meist zweitrangig. Diese Schwachstellen zielen auf Server-Software und Anwendungsplattformen, nicht auf typische Endgeräte.
Empfohlene Maßnahmen
Erster Schritt: eingesetzte Spring-Versionen inventarisieren. Nicht auf Bibliotheksnamen im Quellcode verlassen, sondern die tatsächlich ausgelieferten Artefakte und Container-Images prüfen. Gerade in CI/CD-Pipelines schleichen sich ältere Transitiv-Abhängigkeiten gern durch.
Dann zügig patchen. Wer Spring Framework 7.0.x oder 6.2.x betreibt, sollte die betroffenen Minor-Releases ersetzen. Für ältere 6.x- und 5.x-Zweige gilt dasselbe, sofern sie noch im Support- oder Wartungsfenster liegen. Ob es für alle Linien bereits konkrete Fix-Versionen gibt, lässt die NVD-Zusammenfassung offen; die NVD-Seiten selbst sollten hier die maßgebliche Referenz bleiben.
Für CVE-2026-59270 gilt: den eingebetteten LDAP-Server nur nutzen, wenn er wirklich gebraucht wird. In Test- und Entwicklungsumgebungen sollte er nicht pauschal auf allen Interfaces lauschen. Wer ihn nicht braucht, schaltet ihn ab oder bindet ihn strikt auf localhost.
Bei CVE-2026-59354 ist Dynamic Client Registration der Hebel. Wenn das Feature nicht gebraucht wird, raus damit. Wenn es gebraucht wird, müssen Metadatenvalidierung, Ausgabe in Oberflächen und nachgelagerte Nutzung der Felder geprüft werden. Tokens mit hoher Reichweite gehören zusätzlich begrenzt und überwacht.
Und ja: Logs prüfen. Verdächtige Client-Registrierungen, ungewöhnliche LDAP-Zugriffe, große XML-Requests oder gebrochene SSE-Verbindungen können frühe Hinweise liefern. Das ersetzt kein Update, hilft aber bei der Eingrenzung.
Einschätzung von CyberSecurity-News.de
Vier kritische CVEs auf einmal sind für jedes Spring-Team ein Pflichtenheft, kein Randthema. Die Mischung ist unangenehm: ein Streaming-Fehler, ein Speicherlimit-Problem, ein zu offen exponierter LDAP-Dienst und ein Auth-Server-Problem mit möglicher Folgeauswirkung bis hin zu SSRF. Das trifft nicht nur Edge Cases.
Die Informationslage ist dabei noch fragmentiert. Die NVD liefert die Kerndaten, aber in solchen Fällen fehlen oft zunächst saubere Praxisanweisungen des Herstellers oder belastbare Exploit-Details. Genau deshalb sollte niemand auf „mal beobachten“ setzen. Wer Spring produktiv einsetzt, sollte jetzt patchen, Expositionen reduzieren und die betroffenen Funktionen gezielt abschalten, wo sie nicht gebraucht werden.
Besonders beim eingebetteten LDAP-Dienst und bei Dynamic Client Registration ist das Risiko in vielen Umgebungen hausgemacht. Solche Features werden gern für Tests aktiviert und später vergessen. Das ist der Teil, der in echten Netzen am Ende am meisten wehtut.
Fazit
CVE-2026-47890, CVE-2026-47891, CVE-2026-59270 und CVE-2026-59354 gehören auf die Patchliste. Nicht irgendwann, sondern jetzt. Wer Spring im produktiven Umfeld betreibt, sollte Versionen, aktivierte Module und freigegebene Netzwerkoberflächen sofort prüfen.
Für den DACH-Raum ist die Lage klar: Wer Java-Anwendungen mit Spring betreibt, muss diese Meldung ernst nehmen. Die betroffenen Funktionen sitzen oft tief in Plattformen, die geschäftskritisch sind. Genau dort ist ein sauberer Patch- und Härtungsprozess Pflicht.
