Die TeamCity-Lücke CVE-2026-63077 verlangt weder ein Passwort noch einen Klick des Opfers: Ein präpariertes Datenpaket an die Agenten-Schnittstelle genügt für Systembefehle auf dem Build-Server. Die US-Cyberbehörde CISA hat die Schwachstelle am 5. August in ihren Katalog der aktiv ausgenutzten Lücken aufgenommen und Bundesbehörden ganze drei Tage zum Patchen gelassen. Deutsche Entwicklungsteams merken sich zwei andere Nummern: 2025.11.7 und 2026.1.3.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
So knapp setzt CISA eine Frist nur, sobald Angriffe bereits laufen. Betroffen ist jede selbst betriebene TeamCity-Installation, vom einzelnen Server in der Agentur bis zur Build-Farm im Rechenzentrum.
Das Wichtigste in Kürze
- CVE-2026-63077 erreicht den CVSS-Wert 9,8 und betrifft alle Versionen von TeamCity On-Premises.
- Ein unauthentifizierter Aufruf der Agenten-Schnittstelle reicht für Betriebssystembefehle mit den Rechten des Serverprozesses.
- JetBrains schließt die Lücke in 2025.11.7 und 2026.1.3, ein Sicherheitspatch-Plugin deckt Installationen ab Version 2017.1 ab.
- TeamCity Cloud bleibt außen vor, dort greifen die Gegenmaßnahmen bereits.
Wie kommt ein Angreifer ohne Passwort auf den Build-Server?
Der Fehler steckt in der Deserialisierung,[4] also in dem Schritt, in dem TeamCity empfangene Daten zurück in Java-Objekte verwandelt. Das Protokoll, über das sich Build-Agenten beim Server melden, nimmt solche Objekte entgegen, bevor eine Authentifizierung greift. Ein Angreifer mit HTTP-Zugriff schiebt dort eine präparierte Struktur hinein und bringt den Server dazu, Klassen zu laden, die dort nicht hingehören.[1]
Im Logfile hinterlässt der Angriff Einträge mit com.thoughtworks.xstream.converters.ConversionException. Nach dem Patch erscheinen stattdessen Meldungen vom Typ ForbiddenClassException, ein Zeichen für abgewehrte Versuche. Verdächtig sind außerdem Build-Agenten, die sich unerlaubt registriert haben und deren Name mit scan beginnt.[2]
Warum steht TeamCity zum vierten Mal in CISAs Katalog?
Vier TeamCity-Einträge führt CISA seit Oktober 2023: die Authentifizierungs-Umgehung CVE-2023-42793, das Duo CVE-2024-27198 und CVE-2024-27199 aus dem März 2024 sowie nun CVE-2026-63077. Bei den drei älteren Einträgen vermerkt die Behörde ausdrücklich einen Einsatz in Ransomware-Kampagnen.[3] Nach der Lücke von 2024 verteilten Angreifer über gekaperte Build-Server die Ransomware BianLian und den Kryptominer XMRig. Dasselbe Muster einer aktiv ausgenutzten Einstiegslücke zeigte im August IBMs KI-Baukasten Langflow.
Der Reiz liegt in der Beute. Ein Server für Continuous Integration hält die Zugangsdaten für Code-Repository, Container-Registry und Zielumgebung an einem Ort. Ein Angreifer mit Kontrolle darüber verändert die Auslieferung, statt in jedes Zielsystem einzeln einzubrechen. Denselben Hebel nutzten der Angriff auf die npm-Pakete rund um Keyv und ein manipuliertes Tracking-Skript bei Adform.
Ein Build-Server kennt die Zugangsdaten für Repository, Registry und Produktivumgebung. Eine übernommene TeamCity-Instanz liefert Angreifern damit den Generalschlüssel für die gesamte Auslieferungskette.
— Michael Dobler, Herausgeber Dr. Web
Vom Fund bis zur Frist
Was gilt jetzt für deutsche Entwicklungsteams?
Die CISA-Frist bindet allein US-Bundesbehörden, europäische Hersteller trifft ein anderes Regelwerk. Ab dem 11. September 2026 greift die Meldepflicht aus Artikel 14 der EU-Cyberresilienzverordnung: Hersteller digitaler Produkte melden eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden an die EU-Agentur ENISA und das zuständige CSIRT. Für JetBrains mit Firmensitz in Prag wäre ein Fall wie CVE-2026-63077 ab diesem Stichtag meldepflichtig.
Für Betreiber zählt der Meldeweg. Kritische Anlagen melden einen erheblichen Sicherheitsvorfall nach dem BSI-Gesetz an das BSI. Sobald personenbezogene Daten abfließen, läuft daneben die 72-Stunden-Frist aus Artikel 33 DSGVO. Ein kompromittierter Build-Server erfüllt beide Voraussetzungen schnell, denn dort liegen Testdaten neben Deployment-Schlüsseln. Warum die Meldewege vor dem Ernstfall feststehen sollten, zeigt der Überblick zu Cybersecurity als Chefsache.
Das Update auf 2025.11.7 oder 2026.1.3 hat Vorrang, für ältere Installationen ab 2017.1 liefert JetBrains ein Sicherheitspatch-Plugin nach.[1] Danach durchsuchen Sie die Server-Logs nach den genannten Ausnahme-Meldungen und tauschen sämtliche in TeamCity hinterlegten Zugangsdaten aus. Diesen Austausch nennt JetBrains nicht ausdrücklich, nach einem Systembefehl mit Serverrechten führt an ihm trotzdem kein Weg vorbei. Wie lange gestohlene Anmeldedaten nachwirken, zeigt der Snowflake-Fall mit vier Jahre alten Passwörtern.
Quellen
[1] JetBrains: „Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)“
[2] JetBrains: „CVE-2026-63077: Additional Guidance Following Reports of Active Exploitation“
[3] CISA: „Known Exploited Vulnerabilities Catalog“
[4] Rapid7: „CVE-2026-63077: Critical unauthenticated remote code execution in JetBrains TeamCity“
Mehr Newshunger?
- Langflow-Lücke: IBMs KI-Baukasten vergibt Superuser-Token an jeden Aufrufer
- Zapscape: Der dritte KVM-Ausbruch trifft Hosts mit verschachtelter Virtualisierung
- Keyv kompromittiert: Der Angriff auf die npm-Lieferkette läuft noch
- Atlassian Rovo: Eine versteckte Anweisung genügt für den Datenabfluss aus Jira und Confluence
- Snowflake-Hack: Vier Jahre alte Passwörter öffneten 165 Firmenkonten
- Adform kompromittiert: Ein manipuliertes Tracking-Skript ersetzte Krypto-Adressen
