Eine 9.8 im Server, der Ihre Software baut

CVE-2026-63077 ist eine Schwachstelle durch Deserialisierung nicht vertrauenswürdiger Daten, die Klasse, die CISA unter CWE-502 führt, in JetBrains TeamCity On-Premises, dem Continuous-Integration- und Continuous-Delivery-Server, den tausende europäische und britische Entwicklungsteams nutzen, um ihren eigenen Code zu kompilieren, zu testen und auszuliefern. Sie erreicht einen CVSS-Wert von 9.8, die nahezu höchste Stufe, reserviert für Lücken, die weder Zugangsdaten noch Nutzerinteraktion brauchen und dem Angreifer alles auf einmal übergeben.

Die Lücke sitzt im Agent-Polling-Protokoll von TeamCity, dem Kanal, über den sich Build-Agenten beim Server melden. Ein Angreifer, der diesen Kanal über HTTP oder HTTPS erreicht, ganz ohne Anmeldung, kann eine präparierte Nutzlast senden, die TeamCity deserialisiert und als Betriebssystembefehl ausführt, mit genau den Rechten, die der TeamCity-Serverprozess selbst besitzt. Jede ausgelieferte On-Premises-Version ist betroffen; TeamCity Cloud, von JetBrains gehostet, war bereits gepatcht und erfordert keine Maßnahme der Kunden.

Neun Tage von der Offenlegung bis zur bestätigten Ausnutzung

JetBrains veröffentlichte am 27. Juli 2026 eine eigene Sicherheitsmitteilung, würdigte die Entdeckung und lieferte behobene Builds, TeamCity 2025.11.7 und 2026.1.3, dazu ein Sicherheits-Patch-Plugin für alle Versionen ab 2017.1, die nicht sofort aktualisieren können. Zu diesem Zeitpunkt erklärte JetBrains, keine aktive Ausnutzung festgestellt zu haben.

Das änderte sich schnell. Am 5. August 2026 nahm die US-Behörde CISA (Cybersecurity and Infrastructure Security Agency) CVE-2026-63077 in ihren Known-Exploited-Vulnerabilities-Katalog auf, die Liste, die CISA für Lücken reserviert, deren aktive Ausnutzung in echten Angriffen bestätigt ist, nicht nur theoretisch möglich. Gemäß Binding Operational Directive 26-04 hatten US-Bundesbehörden bis zum 8. August 2026, vergangenen Samstag, Zeit, zu patchen oder betroffene Systeme vom Netz zu nehmen. Der Eintrag erfolgte in derselben Woche, in der CISA eine separate Welle aktiver Ausnutzung bei IBM Langflow, N-able N-central und Apache Tomcat bestätigte, einen Tag zuvor, am 4. August, in einer eigenständigen Mitteilung in den Katalog aufgenommen - andere Schwachstellen, andere Hersteller, dieselbe Botschaft darüber, wie wenig Zeit internetseitig erreichbare Infrastruktursoftware nach einer Offenlegung bleibt.

Ein CI/CD-Einbruch ist ein Lieferketten-Einbruch

Ein gewöhnlicher Webserver-Einbruch kostet eine Organisation das, was auf genau diesem einen Server liegt. TeamCity hält mehr: die Cloud-Anbieter-Schlüssel und Container-Registry-Tokens, mit denen Build-Agenten ausliefern, die Paket-Repository-Zugangsdaten, mit denen eine Pipeline unter dem verifizierten Namen einer Organisation veröffentlicht, und oft die Code-Signierschlüssel, die ausgelieferte Software für jeden Kunden, der sie installiert, authentisch aussehen lassen. Remote-Code-Ausführung mit Serverrechten auf dem Orchestrator im Zentrum dieser Vertrauenskette erreicht all diese Zugangsdaten gleichzeitig.

Ein Angreifer, der so weit kommt, kann mehr als nur eine Datenbank kopieren: Er kann sich in einen künftigen Build einschleusen, bis jemand es bemerkt, derselbe Mechanismus hinter den Lieferketten-Kompromittierungen, die bereits weit größere Softwarehersteller als die typische EU- oder UK-Entwicklungsfirma getroffen haben. Die Auswirkung reicht über den TeamCity-Server selbst hinaus, zu jedem Kunden und jedem nachgelagerten System, das dem vertraut, was dieser Server produziert.

Die Frist ist nicht Ihre; die Ausnutzung ist es bereits

Die Binding Operational Directive 26-04 bindet rechtlich nur US-Bundesbehörden, und eine Entwicklungsfirma in Berlin, Amsterdam oder Manchester, die TeamCity On-Premises betreibt, schuldet CISA keinen Bericht. Das als Freibrief zu lesen, nach gewohntem Zeitplan zu patchen, verwechselt ein Compliance-Artefakt mit einer Bedrohungsprognose.

Die wichtigste Tatsache ist der KEV-Eintrag selbst. CISA nimmt eine CVE erst in diesen Katalog auf, wenn bestätigt ist, dass echte Angreifer sie gegen echte, internetseitig erreichbare Server einsetzen, und eine internetseitig erreichbare TeamCity-Instanz in der EU oder im UK ist für diesen Angreifer genauso erreichbar wie eine in Virginia. NIS2 und die britischen Vorgaben für wesentliche und wichtige Einrichtungen erwarten bereits, dass Organisationen bestätigte aktive Ausnutzung als operativen Notfall behandeln, unabhängig davon, welche Regierung die Frist benannt hat. Die Bundesfrist verstrich am Samstag; die Gefährdung, für die sie geschrieben wurde, besteht weiter.

Was diese Woche zu prüfen ist

Wer TeamCity On-Premises betreibt, kennt die Lösung als Versionsnummer: Update auf 2025.11.7 oder 2026.1.3. Ist ein sofortiges Update nicht möglich, deckt JetBrains' Sicherheits-Patch-Plugin Versionen ab 2017.1 ab und schließt die Lücke ohne vollen Versionssprung. Bis eine der beiden Maßnahmen umgesetzt ist, gehört der Server vom offenen Internet genommen, der Zugriff auf ein VPN oder ein anderes vertrauenswürdiges Netzwerk beschränkt, und der TeamCity-Prozess sollte mit den minimal nötigen Betriebssystemrechten laufen, nicht mit einem Administratorkonto.

Das Patchen schließt die Tür für die Zukunft. Was vor dem Patch bereits hindurchgelangt sein könnte, verdient eigene Aufmerksamkeit: jede Zugangsdaten, die der TeamCity-Server erreichen konnte, Cloud-API-Schlüssel, Registry-Tokens, Signaturschlüssel, Deployment-SSH-Schlüssel, sollten rotiert werden, unabhängig davon, ob ein Einbruch bestätigt wurde, denn eine Deserialisierungs-RCE mit Serverprozess-Rechten hinterlässt nicht zuverlässig Protokolle im Verhältnis zu dem, worauf sie zugreifen konnte. Vor der nächsten Veröffentlichung lohnt sich ein Abgleich aktueller Build-Artefakte mit bekannt guten Prüfsummen von vor dem Expositionsfenster.