TeamCity CVE-2026-63077 beheben: Notfallleitfaden 2026

Die offizielle Sicherheitsmitteilung bestätigt, dass TeamCity On-Premises betroffen ist und ungepatchte Server aktiv ausgenutzt beziehungsweise mit Ausnutzungsversuchen konfrontiert wurden (Sicherheitsupdate zu CVE-2026-63077). Das ist eine andere Ausgangslage als ein gewöhnliches Wartungsfenster: Bis zur Prüfung darf der Server nicht als vertrauenswürdige Steuerzentrale der Build-Kette behandelt werden.

TeamCity Cloud erfordert nach der offiziellen Abgrenzung keine Nutzeraktion für diesen Fix. Bei On-Premises-Installationen muss das Unternehmen dagegen selbst entscheiden, ob die Instanz sofort auf eine korrigierte Version gebracht, vorübergehend mit dem offiziellen Security-Patch abgesichert oder vollständig isoliert wird.

Die Sofortreihenfolge sollte so aussehen:

1. Externen Zugriff begrenzen: Internetzugang, öffentliche Administration und nicht zwingend erforderliche eingehende Verbindungen durch Firewall, Reverse Proxy oder Netzwerksegmentierung sperren. Ein bloßes Verbergen der Anmeldeseite gilt nicht als ausreichende Maßnahme.
2. Hochprivilegierte Änderungen einfrieren: Keine neuen Administratoren, Build-Konfigurationen, Tokens, Webhooks oder Agent-Autorisierungen freigeben, solange die Ausgangslage nicht dokumentiert ist.
3. Produktionssignierung pausieren: iOS-Archive, App-Store-Releases und andere signierte Lieferungen bleiben angehalten, wenn Server, Agent oder Signaturumgebung nicht eindeutig vertrauenswürdig sind.
4. Beweise sichern: Server-Logs, Audit-Daten, Agent-Listen, Konfigurationsänderungen, Build-Aufträge und relevante Zeitstempel unverändert kopieren.
5. Verantwortung aufteilen: Ein Team kontrolliert die TeamCity-Instanz, ein zweites untersucht Credentials und Artefakte, ein drittes bewertet Mac Agent und Signaturkette.

Ein Patch blockiert weitere bekannte Ausnutzung, beweist aber nicht, dass vor dem Patch keine Manipulation stattgefunden hat. Diese Trennung zwischen „behoben“ und „sauber“ verhindert, dass ein reparierter Server sofort wieder ein kompromittiertes Build-Skript oder einen unautorisierten Agent steuert.

Welche Korrekturversion ist für TeamCity CVE-2026-63077 vorgesehen?

Die offizielle Mitteilung nennt 2025.11.7 und 2026.1.3 als Versionen mit Fix. Diese Versionsnummern sind keine pauschale Empfehlung für jedes Unternehmen: Die passende Zielversion hängt vom aktuellen Release, von Lizenzbedingungen, Datenbank, Java-Version, Plugins, Wartungsfenster und einem möglichen Rückfallplan ab (offizielle TeamCity-Sicherheitsmitteilung).

Wenn ein sofortiges Upgrade auf eine korrigierte Version nicht möglich ist, kann das Unternehmen den von TeamCity bereitgestellten Security-Patch als zeitlich begrenzte Schutzmaßnahme prüfen. Der Patch ersetzt weder die Untersuchung noch die reguläre Aktualisierung. TeamCity 2026.2 wurde am 01.09.2026 veröffentlicht; ein direkter Sprung auf diese Version darf nur nach Prüfung der Upgrade Notes erfolgen, nicht allein wegen der höheren Versionsnummer.

Vor der Auswahl werden mindestens diese Angaben festgehalten:

• aktuell installierte TeamCity-Version und Edition;
• Datenbanktyp, Treiberversion und Sicherungsstatus;
• verwendete Plugins einschließlich eigener Erweiterungen;
• Java-Laufzeit und Startparameter;
• Agent-Versionen, Betriebssysteme und Produktionsrollen;
• serverUrl, Autorisierungsstatus und letzte Verbindung jedes Agents;
• aktive Build-Konfigurationen, VCS-Verbindungen, Artefaktpfade und Webhooks;
• Signatur-Credentials, Deployment-Schlüssel und externe Tokens;
• geplante Rückfallversion und Verantwortlicher für die Freigabe.

Für Java 21 ist die offizielle TeamCity-Dokumentation maßgeblich, weil die Eignung nicht nur vom Serverpaket, sondern auch von der konkreten Upgrade-Stufe und den verwendeten Komponenten abhängt (offizielle Hinweise zu Java 21 in TeamCity). Auch die aktuellen Upgrade Notes müssen vor dem Wartungsfenster gelesen werden; insbesondere Datenbanktreiber und Plugins können einen vermeintlich einfachen Sicherheitsfix in ein Kompatibilitätsproblem verwandeln.

Welche Sicherungen werden wirklich benötigt?

Eine Datenbanksicherung allein reicht nicht aus. Für eine belastbare Wiederherstellung werden zusätzlich das TeamCity Data Directory, serverbezogene Konfigurationen, relevante Build- und Audit-Logs sowie die Dokumentation der Agent-Zuordnung gesichert. Credentials sollten nicht unverschlüsselt in eine neue Sicherung kopiert werden. Stattdessen muss das Sicherheitsteam festlegen, welche Geheimnisse nach der Beweissicherung widerrufen und neu ausgestellt werden.

Die Sicherung wird vor dem Stoppen des Servers auf Lesbarkeit und Wiederherstellbarkeit geprüft. Dazu gehören ein nachvollziehbarer Zeitstempel, ein geschützter Ablageort, eine Prüfsumme und ein benannter Zugriffskreis. Ein Backup, das nie testweise eingelesen wurde, ist nur ein Aufbewahrungsnachweis, aber kein verlässlicher Rückfallplan.

Die Installation sollte bewusst nicht als allgemeine Kommandoanleitung behandelt werden. Entscheidend ist die Reihenfolge mit einem dokumentierten Abbruchpunkt:

1. Wartungsfreigabe einholen: Produktverantwortliche bestätigen, dass laufende Builds beendet oder kontrolliert angehalten wurden und keine Signaturaufträge mehr gestartet werden.
2. TeamCity-Server stoppen: Aktive Prozesse werden geordnet beendet; parallele Änderungen durch Administratoren und Automatisierung bleiben gesperrt.
3. Backup bestätigen: Datenbank, Data Directory, Logs und Konfigurationsnachweise werden gegen die vorbereitete Sicherungsliste geprüft.
4. Korrektur installieren: Das Unternehmen verwendet eine unterstützte Fix-Version oder, falls ausdrücklich notwendig, den offiziellen Security-Patch.
5. Server starten und Basiszustand prüfen: Startprotokoll, Datenbankverbindung, Speicherpfade und Administrationszugang werden kontrolliert.
6. Version nachweisen: Die tatsächlich laufende Version wird im Server und in der Änderungsdokumentation festgehalten.
7. Zugriff schrittweise öffnen: Netzwerkfreigaben werden erst nach erfolgreicher Prüfung der Sicherheits- und Betriebsfunktionen erweitert.

Nach dem Start werden zunächst keine produktiven iOS-Builds freigegeben. Die Administrationsoberfläche, VCS-Verbindungen, Build-Warteschlange, Artefaktverwaltung und der Status des Security-Patches werden getrennt geprüft. Ein erreichbarer Webzugang ist kein Nachweis dafür, dass alle Integrationen korrekt und sicher arbeiten.

Für Server oder Agents ohne direkten Internetzugang muss zusätzlich geprüft werden, ob Download, Plugin-Auflösung und automatische Aktualisierung absichtlich blockiert sind. Ein Offline-Agent kann stabil erscheinen, obwohl er eine benötigte Aktualisierung nicht erhalten hat. Deshalb gehört der tatsächliche Installations- und Versionsnachweis in das Wartungsprotokoll.

Woran lässt sich eine mögliche Ausnutzung des TeamCity-Servers erkennen?

Die offiziellen Hinweise und die vorhandenen TeamCity-Protokolle liefern Untersuchungsansätze, aber einzelne Auffälligkeiten beweisen keine Kompromittierung. Eine unerwartete Administratoränderung, ein unbekannter Agent, eine neue Build-Konfiguration oder ein ungewöhnlicher Zugriff wird deshalb mit Zeit, Benutzerkonto, Quellsystem und Folgeaktivität erfasst. Erst die Korrelation mehrerer Indikatoren erlaubt eine belastbare Entscheidung.

Die Untersuchung sollte mindestens diese Fragen beantworten:

• Gab es während des relevanten Zeitfensters neue oder veränderte Benutzer, Tokens, Projekte oder Berechtigungen?
• Wurde ein Agent autorisiert, den kein Teammitglied oder kein dokumentierter Automatisierungsprozess erwartet?
• Haben sich Build-Schritte, VCS-Roots, Webhooks, Artefaktziele oder Deployment-Verbindungen geändert?
• Gibt es Builds, die außerhalb des üblichen Zeitplans liefen oder auf ungewohnten Agents gestartet wurden?
• Wurden Logs gelöscht, verkürzt, exportiert oder mit ungewöhnlichen Zugriffsrechten versehen?
• Stimmen die erzeugten Artefakte mit Commit, Build-Konfiguration, Agent und Freigabeprozess überein?

Der offizielle TeamCity-Sicherheitshinweis sollte dabei direkt neben der internen Untersuchungsliste liegen. Medienberichte können die Dringlichkeit erklären, ersetzen aber weder den offiziellen Fix-Nachweis noch die unternehmensinterne Beweissicherung.

Wie wird ein Mac Build Agent sicher wieder zugelassen?

Jeder Mac Agent wird zunächst aus der Produktionsroute entfernt. Anschließend prüft das Team den Namen, die Host-Identität, den Autorisierungsstatus, serverUrl, installierte Agent-Version, letzte Verbindung und das Ergebnis einer eventuellen automatischen Aktualisierung. Die offizielle Agent-Dokumentation beschreibt die relevanten Status- und Autorisierungsinformationen.

Ein Agent sollte während einer automatischen Aktualisierung nicht zwangsweise neu gestartet werden. Ein erzwungener Neustart kann den Aktualisierungsvorgang und die anschließende Beurteilung des Zustands verfälschen. Die Dokumentation zum Upgrade von TeamCity-Servern und Agents ist deshalb vor dem Eingriff zu berücksichtigen.

Für jeden Mac Agent gilt diese isolierte Prüfsequenz:

1. Produktionsrouting und Signaturaufträge deaktivieren.
2. Agent-Identität, Hostnamen und erwartete Zuordnung mit dem Inventar abgleichen.
3. Autorisierung und serverUrl kontrollieren.
4. Ergebnis der Agent-Aktualisierung sowie lokale Toolchain dokumentieren.
5. Eine unsignierte Testpipeline mit festem Commit starten.
6. Xcode-Auswahl, Abhängigkeiten, Cache-Verhalten und Workspace-Bereinigung prüfen.
7. Erst danach einen kontrollierten Archiv-Build ohne Veröffentlichung ausführen.
8. Bei Abweichungen den Agent nicht erneut autorisieren, sondern isoliert halten und zur Untersuchung markieren.

Unbekannte oder nicht erklärbare Agents werden nicht „zur Probe“ freigegeben. Sie bleiben von den bekannten, vertrauenswürdigen Mac-Knoten getrennt. Für Teams ohne Ersatzknoten kann eine temporär isolierte Mac-Umgebung von NUKCLOUD als Wiederaufbau- und Vergleichsumgebung dienen; sie ersetzt nicht die forensische Prüfung des alten Systems.

Welche CI/CD-Credentials müssen nach einem Vorfall rotiert werden?

Die Rotation wird nicht auf das TeamCity-Administratorkonto begrenzt. Das verantwortliche Team erstellt eine Matrix mit Besitzer, Zweck, betroffenen Projekten, Widerrufszeitpunkt, Neuausstellung und erfolgreichem Test. Je nach Architektur gehören dazu:

• VCS-Zugänge und persönliche oder technische Zugriffstokens;
• Artefakt-Repository- und Paketquellen-Credentials;
• Cloud- und Deployment-Schlüssel;
• Webhook- und Integrations-Tokens;
• Apple-Entwickler-Credentials und App-Store-Zugänge;
• Zertifikate, Provisioning-Profile und Signatur-Keys;
• lokale Keychains und auf Mac Agents gespeicherte Geheimnisse;
• SSH-Schlüssel für Infrastruktur- oder Release-Systeme.

Die Rotation wird in einer Reihenfolge durchgeführt, die keine neuen dauerhaften Zugangsdaten auf einem möglicherweise nicht vertrauenswürdigen Agent hinterlässt. Zuerst werden betroffene Zugänge widerrufen, danach werden neue Geheimnisse in einem geprüften Verwaltungsprozess erzeugt und schließlich auf einem sauberen Agent getestet. Ein Credential gilt erst als ersetzt, wenn der alte Zugriff nachweislich nicht mehr funktioniert.

Wie werden vorhandene Build-Artefakte behandelt?

Artefakte aus dem möglichen Ausnutzungsfenster werden nicht automatisch erneut veröffentlicht. Für jedes relevante Paket werden Quellrevision, Build-Konfiguration, verwendeter Agent, Build-Zeit, Signaturstatus und Zielablage miteinander verglichen. Fehlt einer dieser Nachweise, wird das Artefakt zurückgehalten und aus einem sauberen Umfeld neu gebaut.

Auch ein erfolgreich installierbares iOS-Paket kann aus Sicht der Lieferkette unbrauchbar sein, wenn der ausführende Agent, ein Build-Skript oder ein Abhängigkeitszugriff nicht nachvollziehbar ist. Die Entscheidung lautet daher nicht „Build grün oder rot“, sondern „Build reproduzierbar, zugeordnet und mit vertrauenswürdiger Signatur erzeugt oder nicht“.

Erfahrungshinweis: Eine einzelne ungewöhnliche Logzeile sollte weder als Entwarnung noch als endgültiger Angriffsbeweis behandelt werden. Erst die Verbindung von Serverereignis, Agent-Zustand, Credential-Nutzung und Artefaktspur ergibt eine belastbare Untersuchungsrichtung.

Die Wiederherstellung beginnt auf einem isolierten, sauberen Mac Agent mit einer minimalen Produktionsumgebung. Der Ablauf wird in derselben Reihenfolge geprüft, in der ein echtes Release entsteht:

• Quellcode aus dem freigegebenen Commit abrufen;
• Abhängigkeiten aus den freigegebenen Quellen auflösen;
• Projekt mit der dokumentierten Xcode-Version bauen;
• Tests und statische Prüfungen ausführen;
• Archiv erzeugen und Metadaten kontrollieren;
• Signatur in einer kontrollierten Umgebung durchführen;
• Prüfsummen, Build-Logs und Artefaktzuordnung speichern;
• Veröffentlichung zunächst nur als manuell freizugebenden Schritt vorbereiten.

Die Ergebnisse des sauberen Agents werden mit einem alten Knoten verglichen. Stimmen Toolchain, Abhängigkeiten, Build-Ausgabe oder Signaturmetadaten nicht überein, bleibt der alte Agent gesperrt. Je nach Beweislage wird er neu installiert, weiter forensisch untersucht oder außer Betrieb genommen.

Für Teams, die kurzfristig eine getrennte Mac-Ressource benötigen, kann die Mac-Infrastruktur von NUKCLOUD als temporärer Wiederaufbaupfad geprüft werden. Der organisatorische Nutzen liegt dabei nicht in einer pauschalen Sicherheitszusage, sondern in der Möglichkeit, einen Agent neu aufzusetzen, die Pipeline getrennt zu testen und den bisherigen Knoten für die Untersuchung unangetastet zu lassen.

Entscheidungs- und Nachweistabelle

Fünf Freigabebedingungen für den Betrieb

• [ ] Die TeamCity-Instanz ist auf einer bestätigten Korrekturversion oder mit einer dokumentierten Übergangsschutzmaßnahme abgesichert.
• [ ] Externe Zugriffe, Administratoränderungen und Agent-Autorisierungen wurden während der Untersuchung kontrolliert.
• [ ] Server-, Agent- und Build-Logs sind unverändert gesichert und einer Untersuchungsentscheidung zugeordnet.
• [ ] VCS-, Artefakt-, Cloud-, Apple- und Signatur-Credentials wurden nach Risiko bewertet und bei Bedarf rotiert.
• [ ] Eine saubere iOS-CI/CD-Pipeline hat Pull, Build, Test, Archiv und kontrollierte Signatur nachvollziehbar durchlaufen.
• [ ] Alte Mac Agents sind entweder neu installiert, ausdrücklich als vertrauenswürdig bewertet oder weiterhin isoliert.
• [ ] Die Herkunft aller wiederverwendeten Artefakte ist nachvollziehbar.
• [ ] Für den Fall eines Fehlers existieren Rückfallverantwortlicher, Kommunikationsweg und dokumentierter letzter vertrauenswürdiger Zustand.

Die folgende Übersicht trennt die operative Entscheidung von der technischen Maßnahme. Sie ist kein Ersatz für die Sicherheitsbewertung, verhindert aber, dass ein grüner Serverstatus vorschnell als Produktionsfreigabe interpretiert wird.

Für eine kurzfristige Ersatzkapazität sollte der technische Leiter vorab klären, ob ein gemieteter Mac die benötigte Xcode-Toolchain, Netzwerkfreigabe, Keychain-Strategie und TeamCity-Agent-Anbindung unterstützt. Die verfügbaren NUKCLOUD-Optionen können dabei als Ausgangspunkt für einen begrenzten Wiederaufbau- oder PoC-Einsatz dienen. Für langfristig hohe, gleichmäßige Build-Lasten oder Anforderungen an lokale Hardware, physische Schnittstellen und dauerhafte Kontrolle kann ein eigener Mac-Knoten weiterhin die passendere Lösung sein.

Der entscheidende Unterschied zwischen dem bisherigen Aufbau und einer temporären NUKCLOUD-Umgebung liegt damit nicht in einem pauschalen Versprechen, sondern in der Möglichkeit, Server, Agent, Credentials und Produktionspipeline organisatorisch zu trennen. Für Unternehmen ohne vorbereiteten Ersatzknoten kann das die Zeit bis zur belastbaren Wiederaufnahme verkürzen, während der ursprüngliche Mac Agent für Untersuchung oder Neuinstallation zurückgehalten wird.