JetBrains behebt kritische Schwachstelle 9.8 in TeamCity, die Remoteausführung ohne Authentifizierung ermöglicht

JetBrains hat am 27. Juli eine Warnung veröffentlicht, in der alle Kunden von TeamCity On-Premises aufgefordert werden, auf die Versionen 2025.11.7 oder 2026.1.3 zu aktualisieren. Das Unternehmen hat die CVE-2026-63077 behoben, eine unsichere Deserialisierungsanfälligkeit im Polling-Protokoll zwischen Server und Build-Agenten, die mit 9.8 im CVSS v3.1 bewertet wurde und die Remoteausführung von Code ohne jegliche Authentifizierung ermöglicht.

Das Problem liegt in der CWE-502, der Deserialisierung von nicht vertrauenswürdigen Daten, die über den Kanal exponiert wird, den die Build-Agenten verwenden, um den Server nach neuen Jobs abzufragen. Ein Angreifer mit HTTP- oder HTTPS-Zugang zum Server sendet ein bösartiges Payload an den Polling-Endpunkt und erhält ohne Sitzung, ohne Token und ohne Benutzerinteraktion die Ausführung im TeamCity-Prozess. Alle On-Premises-Versionen vor den Patches sind gefährdet.

Der Forscher Antoni Tremblay meldete die Schwachstelle am 10. Juli über das koordinierte Offenlegungsprogramm von JetBrains. Das Unternehmen gibt an, dass bis zur Veröffentlichung der Warnung keine aktive Ausnutzung beobachtet wurde, und stellte auch ein Sicherheits-Patch-Plugin für ältere Installationen bereit, das ab Version 2017.1 unterstützt wird. Kunden von TeamCity Cloud müssen nicht handeln: die verwaltete Umgebung wurde bereits behoben.

Installierte Basis und globale Risikobewertung

Laut JetBrains ist TeamCity in mindestens 30.000 Installationen zu finden, wobei eine Kundenliste Citibank, Ferrari, Wargaming und die Oculus-Sparte von Meta umfasst. Marktstudien von Datanyze positionieren die Plattform auf dem zweiten Platz im CI, mit einem Marktanteil von 18,7 %, nur hinter Jenkins und vor neueren Alternativen wie GitHub Actions in etablierten Unternehmensumgebungen. Die Konzentration liegt in den USA, Deutschland und Australien, den drei Märkten mit der höchsten anerkannten Nutzung.

CI/CD-Server sind heutzutage eines der wertvollsten Ziele für Angreifer. Wer TeamCity kontrolliert, kontrolliert die Pipeline und damit das signierte Binary, das in die Produktion geht. Der unvermeidliche Vergleich ist mit dem Vorfall bei 3CX im Jahr 2023 und dem Engagement von CircleCI im selben Jahr, die beide als Plattform für Supply-Chain-Angriffe auf Dritte verwendet wurden. Aus diesem Grund hat die CISA eine frühere Schwachstelle von TeamCity, die CVE-2024-27198, im März 2024 in ihren KEV-Katalog aufgenommen, nur wenige Wochen nach der Offenlegung. Zu diesem Zeitpunkt begannen BianLian und andere Ransomware-Gruppen, das Internet innerhalb von weniger als 72 Stunden nach der Veröffentlichung des öffentlichen Exploits auf der Suche nach exponierten Servern zu durchsuchen.

Die Gefahr beschränkt sich nicht nur auf Frankfurt oder San Jose. Delivery-Zentren von Cognizant, Infosys und TCS in Indien betreiben TeamCity als Teil des von amerikanischen und europäischen Banken beauftragten Stacks; ein kompromittierter Server in Bangalore oder Pune öffnet die Tür zum Repository des Kunden in der City von London. In Brasilien verwenden Shared-Service-Umgebungen von mittelständischen Banken und Engineering-Teams von paulistanischen Fintechs TeamCity als Orchestrator für Java- und .NET-Bauten, ein Erbe des historischen Gewichts von JetBrains in der Unternehmensentwicklung. Für den CISO hier ist die Botschaft die gleiche: Wenn der Server dem Internet oder einem weitreichenden Unternehmensnetzwerk ausgesetzt ist, ist der Patch jetzt fällig.

Was in den nächsten 48 Stunden zu tun ist

Die direkte Empfehlung von JetBrains: Für diejenigen, die im Branch 2026.x sind, auf 2026.1.3 aktualisieren; für diejenigen im Branch 2025.11.x, auf 2025.11.7 aktualisieren. Das Patch-Plugin löst Probleme für diejenigen, die in alten Versionen feststecken, ersetzt jedoch nicht das Update. Den TeamCity-Server vom öffentlichen Internet zu trennen, obwohl der Anbieter diesen Punkt nicht in der Warnung erwähnt, eliminiert den Hauptvektor, während das Expositionsfenster schrumpft. Reaktionsteams, die bereits interne Scans mit Nuclei oder Tenable durchführen, sollten die Signatur priorisieren, sobald sie verfügbar ist, und die Protokolle des Agent-Polling-Endpunkts auf der Suche nach unüblichen binären Payloads in den letzten zwei Wochen überprüfen, einem Zeitraum, der das Fenster zwischen privater Meldung und öffentlicher Offenlegung abdeckt.

Eine letzte Anmerkung zum Kalender. Zwischen dem Datum, an dem Tremblay die Schwachstelle meldete, dem 10. Juli, und der öffentlichen Offenlegung, dem 27. Juli, vergingen siebzehn Tage. Es ist ein kurzes Fenster für eine Korrektur, die eine Änderung im Protokoll beinhaltet. JetBrains handelte schnell nach dem Vorfall von 2024, als Rapid7 das Embargo brach und die vorzeitige Offenlegung erzwingte. Die Frage, die für das Sicherheitsteam des Kunden bleibt, ist eine andere: Wie lange, jetzt, wo die CVE öffentlich ist, bis zur ersten Ausnutzung im Wild?