Kurzfassung

Apache Tomcat enthält mit CVE-2026-76183 eine kritische Schwachstelle, über die sich Sicherheitsbeschränkungen für WebSocket-Endpunkte umgehen lassen. Betroffen sind Tomcat 9.0, 10.1 und 11.0 in mehreren Release-Linien; der CVSS-Basiswert liegt bei 9.8 und damit im kritischen Bereich. Unternehmen sollten betroffene Instanzen zügig auf 9.0.122, 10.1.60 oder 11.0.26 anheben.

Was ist passiert?

Bei Apache Tomcat wurde eine Schwachstelle in der Behandlung alternativer Namen festgestellt. Dadurch können Schutzmechanismen für WebSocket-Endpunkte ausgehebelt werden. Praktisch geht es um eine Umgehung der Authentifizierung beziehungsweise der konfigurierten Zugriffsbeschränkungen, sofern Anwendungen WebSocket-Endpunkte über Tomcat bereitstellen und diese durch Sicherheitsregeln abgesichert werden sollten.

Für viele klassische Tomcat-Installationen ist die Lücke nur dann unmittelbar relevant, wenn tatsächlich WebSocket-Funktionen im Einsatz sind. In modernen Java-Webanwendungen ist das aber keineswegs selten, etwa bei Echtzeit-Dashboards, Chat-Funktionen, Push-Mechanismen oder Administrationsoberflächen mit Live-Aktualisierung.

Technische Details

CVE-2026-76183 hat einen CVSS-3.1-Basiswert von 9.8. Dieser Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch eine bereits beobachtete Ausnutzung in realen Angriffen.

Der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet: Angriffe sind über das Netzwerk möglich, die Hürde für die Ausnutzung ist gering, es sind keine Zugangsdaten erforderlich und kein Benutzer muss eine Aktion ausführen; im Erfolgsfall sind erhebliche Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit möglich.

Die Schwachstelle betrifft laut NVD eine Umgehung von Sicherheitsbeschränkungen für beliebige WebSocket-Endpunkte. Ob und wie stark eine konkrete Anwendung gefährdet ist, hängt daher von der Tomcat-Konfiguration und davon ab, welche WebSocket-Routen exponiert sind und welche Funktionen dahinterliegen.

Wer ist betroffen?

Betroffen sind nach aktuellem Stand diese unterstützten Apache-Tomcat-Versionen:

  • 11.0.0-M1 bis einschließlich 11.0.25
  • 10.1.0-M1 bis einschließlich 10.1.59
  • 9.0.0.M1 bis einschließlich 9.0.121

Behoben ist das Problem in:

  • 11.0.26
  • 10.1.60
  • 9.0.122

Zusätzlich als betroffen genannt werden nicht mehr unterstützte Versionen:

  • 8.5.0 bis 8.5.100
  • 7.0.43 bis 7.0.109

Bei diesen Altversionen ist die Lage für Unternehmen im DACH-Raum besonders heikel. Wer Tomcat 7 oder 8.5 noch produktiv betreibt, sollte nicht auf einen Einzelpatch hoffen, sondern die Migration auf eine unterstützte Hauptversion priorisieren. Ob weitere nicht unterstützte Versionen ebenfalls verwundbar sind, ist nicht ausgeschlossen.

Empfohlene Maßnahmen

Erstens: Prüfen Sie umgehend, ob in Ihrer Umgebung Tomcat-basierte Anwendungen mit WebSocket-Endpunkten laufen. Besonders relevant sind Internet-exponierte Systeme, Reverse-Proxy-Setups und Anwendungen mit administrativen oder mandantenfähigen Echtzeitfunktionen.

Zweitens: Aktualisieren Sie betroffene Installationen so schnell wie möglich auf 9.0.122, 10.1.60 oder 11.0.26. Für nicht unterstützte Versionen 7.x und 8.5.x ist ein Upgrade auf eine unterstützte Release-Linie der saubere Weg.

Drittens: Wenn ein sofortiges Upgrade betrieblich nicht möglich ist, reduzieren Sie vorübergehend die Angriffsfläche. Deaktivieren Sie nicht zwingend benötigte WebSocket-Endpunkte, beschränken Sie den Zugriff über vorgeschaltete Proxys oder Firewalls auf bekannte Netze und prüfen Sie, ob besonders sensible Funktionen temporär abgeschaltet werden können.

Viertens: Kontrollieren Sie Logs und Monitoring auf ungewöhnliche WebSocket-Verbindungen, vor allem an Endpunkten, die eigentlich nur authentisierten Benutzern offenstehen sollten. Achten Sie auf Zugriffe ohne erwartete Session-Zuordnung, auf neue Verbindungsquellen und auf Anomalien bei Backend-Aktionen, die über WebSocket ausgelöst werden.

Fünftens: Nehmen Sie die Schwachstelle in Ihr Schwachstellenmanagement mit hoher Priorität auf. Ein CVSS von 9.8 rechtfertigt beschleunigte Change-Fenster, insbesondere bei extern erreichbaren Java-Anwendungen.

Einschätzung von CyberSecurity-News.de

Die technische Schwere ist hoch, und die Kombination aus Netzwerkangriff, keiner Authentifizierung und keiner Nutzerinteraktion macht die Lücke aus Betriebssicht ernst. Entscheidend ist aber der reale Einsatz: Wer Tomcat ohne WebSocket-Funktionen betreibt, ist wahrscheinlich nicht unmittelbar exponiert. Wer dagegen geschützte WebSocket-Endpunkte veröffentlicht, sollte von einer relevanten Gefährdung ausgehen.

Positiv ist, dass feste Versionen für die unterstützten Linien klar benannt sind. Weniger hilfreich ist, dass ohne zusätzliche Herstellerdetails für viele Admin-Teams zunächst Eigenarbeit bleibt: Sie müssen selbst ermitteln, welche Anwendungen WebSocket tatsächlich nutzen und ob Sicherheitsregeln an diesen Endpunkten geschäftskritische Funktionen schützen.

Für manche Berichte wäre es zu kurz gegriffen, den CVSS-Wert allein mit akuter Massenbedrohung gleichzusetzen. Die Schwachstelle ist technisch kritisch, aber ihre praktische Reichweite hängt stark von der Anwendungsarchitektur ab. Für Unternehmen mit Tomcat im Internet und aktiv genutzten WebSocket-Schnittstellen ist das Thema dennoch klar patchwürdig.

Fazit

Wenn Sie Apache Tomcat für Anwendungen mit WebSocket-Endpunkten einsetzen, sollten Sie CVE-2026-76183 zeitnah beheben. Priorität haben extern erreichbare Systeme und Umgebungen, in denen WebSocket-Zugriffe eigentlich an Authentifizierung oder Rollen gebunden sind. Update einspielen, Altversionen ablösen, Logs prüfen.

Quellenangabe

Weiterführende Informationen bei NVD: CVE-2026-76183