TeamCity CVE-2026-63077 RCE: Ungesicherte CI/CD-Übernahme

TeamCity CVE-2026-63077 RCE erlaubt einem unauthentifizierten Angreifer, mit einer einzigen präparierten Anfrage Befehle auf einem TeamCity-On-Premises-Server auszuführen — ohne Login, ohne gültige Session, ohne Nutzerinteraktion. Die CISA nahm die Lücke am 5. August mit einer Drei-Tage-Frist in den KEV-Katalog auf; die aktive Ausnutzung läuft.

Was ist passiert

TeamCity CVE-2026-63077 RCE geht auf eine Deserialisierungs-Schwachstelle (CWE-502) im Agent-Polling-Protokoll zurück, über das TeamCity On-Premises mit seinen Build-Agenten kommuniziert. Durch präparierte HTTP/S-Anfragen an dieses Protokoll umgeht ein Angreifer die Authentifizierung vollständig und führt Betriebssystembefehle mit den Rechten des TeamCity-Serverprozesses aus. JetBrains schloss die Lücke bereits am 28. Juli in TeamCity 2025.11.7 und 2026.1.3 und veröffentlichte zusätzlich ein Security-Patch-Plugin für Organisationen ab Version 2017.1, die nicht sofort aktualisieren können. TeamCity Cloud war nie betroffen.

Der stille Fix blieb nicht still. Am 5. August änderte die CISA ihre Einschätzung zur Ausnutzung von „keine“ auf „aktiv“ und nahm die Schwachstelle in den KEV-Katalog auf — mit der Bewertung „automatisierbar“ und „vollständige technische Auswirkung“, der höchsten Kombination, die CISA vergibt. Die Bundesfrist von nur drei Tagen (bis 8. August) nach Binding Operational Directive 26-04 signalisiert, dass die CISA von einer wahrscheinlichen Massenausnutzung ausgeht, nicht von einem theoretischen Risiko.

Warum das wichtig ist

Ein kompromittierter TeamCity-Server ist nicht nur ein weiterer betroffener Host — er ist eine kompromittierte Software-Fabrik. Angreifer mit den Rechten des Serverprozesses können gespeicherte Zugangsdaten für jedes verbundene Repository, jeden Cloud-Account und jede Artefakt-Registry auslesen, Build-Konfigurationen manipulieren und schadhaften Code in Build-Artefakte einschleusen, bevor diese ausgeliefert werden. Für jede Organisation, die Build-Server-Zugangsdaten nicht konsequent von Produktionszugriffen getrennt hat, wird ein TeamCity-Einbruch direkt zu einem Supply-Chain-Vorfall für jeden Kunden oder jedes interne Team, das diese Builds konsumiert.

TeamCity On-Premises ist bei deutschen Engineering-, Fertigungs- und Automotive-Softwareteams weiterhin verbreitet, die ihre CI/CD-Infrastruktur aus Gründen der Datenresidenz oder vertraglicher Vorgaben on-premises betreiben — genau die Gruppe, die am wenigsten zu TeamCity Cloud migriert ist und damit voll exponiert bleibt. Es ist die vierte selbst gehostete Entwicklerplattform, die DIESEC 2026 als Angriffsziel verfolgt hat, nach Gogs/Gitea (29. Mai), einer zweiten Gitea-Schwachstelle (14. Juli) und GitLabs „Oj Spill“-Offenlegung (28. Juli) — ein wiederkehrendes Muster: selbst gehostete Entwicklerinfrastruktur wird still gepatcht, Wochen bevor die Ausnutzung live geht, oft ohne klar zugewiesene Patch-Verantwortung.

Was Sie jetzt tun sollten

1. Sofort patchen: TeamCity On-Premises auf 2026.1.3 (Build 222742) oder 2025.11.7 (Build 208264) aktualisieren. Falls ein sofortiges Update nicht möglich ist, das dedizierte Security-Patch-Plugin von JetBrains installieren (verfügbar ab TeamCity 2017.1).
2. Version prüfen: Build-Nummer des TeamCity-Servers gegen die oben genannten Fix-Builds abgleichen. Jede frühere Version ist verwundbar, unabhängig davon, wie kürzlich sie installiert wurde.
3. Mitigieren, falls heute kein Patch möglich ist: JetBrains empfiehlt, den Netzwerkzugriff auf den TeamCity-Server auf vertrauenswürdige Netze zu beschränken — für jede internetzugängliche Instanz eine VPN-Verbindung verlangen und die direkte Internet-Exposition des Agent-Polling-Endpunkts wo möglich entfernen.
4. Monitoring: TeamCity-Server-Logs auf unerwartete Anfragen an das Agent-Polling-Protokoll, nicht erklärbare Änderungen an Build-Konfigurationen und ausgehende Verbindungen prüfen, die nicht zu bekannten Artefakt-Registries oder Repositories passen. In TeamCity gespeicherte Zugangsdaten (Repository-Tokens, Cloud-Provider-Keys, Registry-Zugangsdaten) rotieren, falls der Server seit dem 28. Juli internetzugänglich und ungepatcht war.

DIESEC Einschätzung

Wir sehen 2026 immer wieder dasselbe Muster: selbst gehostete Entwicklertools — Gitea, GitLab, jetzt TeamCity — erhalten einen stillen Hersteller-Patch, und das eigentliche Risikofenster öffnet sich erst Wochen später, wenn ein Forscher oder Angreifer eine funktionierende Ausnutzung demonstriert. Die Lücke ist selten technisch — sie ist organisatorisch. In den meisten deutschen Mittelstands-Engineering-Teams ist „CI/CD-Server patchen“ keine benannte Verantwortung, so wie es „Domain Controller patchen“ ist. CVE-2026-63077 ist ein guter Anlass, genau diese Lücke zu schließen — nicht nur bei diesem einen Server.

Nicht sicher, ob Ihre CI/CD-Infrastruktur diese Verantwortungslücke hat? Kontaktieren Sie DIESEC für eine schnelle Build-Pipeline-Expositionsanalyse und Credential-Hygiene-Prüfung.

Quellen: JetBrains Blog | The Hacker News
Veröffentlicht: 2026-08-10 | Kategorie: Tägliche News | ~4 Min. Lesezeit