Gebruik je TeamCity On-Premises als CI/CD-server? Dan is dit het moment om even alles anders te laten liggen. JetBrains liet op 7 augustus 2026 weten dat het kritieke lek CVE-2026-63077 inmiddels daadwerkelijk wordt misbruikt door aanvallers. Servers die nog niet zijn bijgewerkt, lopen op dit moment een reëel risico op volledige overname.
In dit artikel leggen we uit wat het lek precies doet, waarom juist een build- en releaseserver zo’n aantrekkelijk doelwit is, welke versies veilig zijn, hoe je stap voor stap controleert of jouw omgeving is geraakt en welke maatregelen je structureel zou moeten nemen.
Wat is er aan de hand?
JetBrains publiceerde eind juli 2026 een beveiligingsmelding over een kritieke kwetsbaarheid in TeamCity On-Premises, met kenmerk CVE-2026-63077. Tegelijk met die melding waren er al gepatchte versies en een losse patch-plug-in beschikbaar. Ruim een week later volgde een aanvullende waarschuwing: er komen meldingen binnen van zowel geslaagde als mislukte aanvalspogingen op TeamCity-servers die nog niet zijn bijgewerkt.
Daarmee verschuift de situatie van “belangrijk om snel op te pakken” naar “nu direct handelen”. Zodra een kwetsbaarheid in het wild wordt uitgebuit, worden kwetsbare systemen doorgaans binnen enkele dagen geautomatiseerd gescand en aangevallen. Het maakt daarbij niet uit hoe klein of onbekend je organisatie is: aanvallers zoeken op poort en protocol, niet op naam.
Gebruik je TeamCity Cloud? Dan hoef je zelf niets te doen. JetBrains heeft de benodigde maatregelen daar al doorgevoerd. Deze blog gaat dus specifiek over zelf beheerde (on-premises of in eigen cloudomgeving gehoste) TeamCity-servers.
Waarom dit lek zo gevaarlijk is
Er is geen inlog nodig
De kwetsbaarheid is uit te buiten zonder authenticatie. Iedereen die via HTTP of HTTPS bij je TeamCity-server kan komen, kan de aanval uitvoeren via het protocol waarmee build-agents de server bevragen. Er zijn dus geen gestolen wachtwoorden, tokens of interne toegang nodig. Bij succes voert de aanvaller commando’s uit op het besturingssysteem, met dezelfde rechten als het TeamCity-serverproces.
Je secrets liggen op één plek
Een CI/CD-server is per definitie een verzamelplaats van gevoelige gegevens: verbindingsgegevens naar repositories, deploytokens voor productieomgevingen, cloud-credentials, certificaten en API-keys. Wordt de server overgenomen, dan zijn niet alleen de projectconfiguraties en build-historie in gevaar, maar in potentie alle systemen waar die server naartoe mag deployen.
Supply chain-risico voor je eigen software
Het meest onderschatte gevolg is manipulatie van de build zelf. Een aanvaller die build-stappen of artifacts kan aanpassen, kan kwaadaardige code meesturen in software die jij vervolgens zelf naar productie of naar je klanten uitrolt. Zo’n aanpassing valt niet op in je broncode, omdat de wijziging pas ná de checkout gebeurt. Dat maakt een gecompromitteerde buildserver tot een probleem dat verder reikt dan één server.
Welke versies zijn veilig?
JetBrains heeft het probleem verholpen in TeamCity 2025.11.7 en 2026.1.3. Draai je een oudere release en kun je niet meteen upgraden, dan is er een security patch plug-in beschikbaar voor TeamCity 2017.1 en nieuwer. Let op: die plug-in dicht uitsluitend dit ene lek en is dus een tijdelijke noodmaatregel, geen alternatief voor bijwerken.
| Situatie | Actie nodig? | Wat je moet doen |
|---|---|---|
| TeamCity 2025.11.x vóór 2025.11.7 | Ja, direct | Bijwerken naar 2025.11.7 |
| TeamCity 2026.1.x vóór 2026.1.3 | Ja, direct | Bijwerken naar 2026.1.3 |
| Oudere versies (vanaf 2017.1) | Ja, direct | Upgraden, of tijdelijk de security patch plug-in installeren |
| TeamCity 2025.11.7 / 2026.1.3 of nieuwer | Nee | Wel controleren op eerdere aanvalspogingen |
| TeamCity Cloud | Nee | JetBrains heeft dit al afgehandeld |
Wat je nu moet doen
1. Breng in kaart welke servers je hebt
Begin met de vraag die vaak wordt overgeslagen: waar draait TeamCity eigenlijk allemaal? Naast de productie-instantie zijn er in de praktijk vaak vergeten test- of legacy-servers, of een oude instantie die “voor de zekerheid” nog aan staat. Controleer per server het versienummer en of de server vanaf internet bereikbaar is.
2. Werk bij naar een gepatchte versie
Bijwerken naar 2025.11.7 of 2026.1.3 is de enige volledige oplossing. Maak vooraf een back-up van de datamap en de database, plan een kort onderhoudsvenster en controleer na de upgrade of agents weer verbinden en builds normaal draaien. Loopt de upgrade over meerdere stappen? Zorg dan dat de server tijdens dat traject niet vanaf internet bereikbaar is.
3. Kun je niet direct bijwerken? Dicht de deur
Lukt bijwerken niet op korte termijn, installeer dan de security patch plug-in én beperk tegelijk de netwerktoegang. Staat de server publiek open, haal hem dan tijdelijk achter een VPN of firewallregel tot je de fix hebt toegepast. Externe bereikbaarheid intrekken is bijna altijd sneller te regelen dan een volledige upgrade, en verkleint het risico onmiddellijk.
Controleren op misbruik: waar let je op?
Patchen is stap één, maar de vraag “is er al iets gebeurd?” is even belangrijk. JetBrains noemt drie concrete aanwijzingen die je zelf kunt nalopen in de serverlogs en de beheerinterface.
Verdachte logmelding
Zoek in de TeamCity-serverlogs op com.thoughtworks.xstream.converters.ConversionException. Deze melding alleen bewijst geen inbraak, maar kan wijzen op een poging of een geslaagde aanval en verdient nader onderzoek.
Geblokkeerde poging
Heb je al gepatcht? Zoek dan op com.thoughtworks.xstream.security.ForbiddenClassException. Die melding betekent dat iemand het heeft geprobeerd nádat de fix actief was en dat de poging is tegengehouden.
Onbekende build-agents
Bekijk de lijst met niet-geautoriseerde agents. Onverwachte namen die met scan beginnen, duiden op een aanvalspoging tegen een server die van buitenaf bereikbaar was. Zulke agents mag je verwijderen.
Belangrijk detail bij die laatste controle: de datum die bij een niet-geautoriseerde agent staat, zegt niets over het moment van de aanvalspoging. Gebruik voor tijdlijnen altijd de timestamps uit de logbestanden. Twijfel je over de interpretatie van je logs, dan kun je een ticket openen bij de TeamCity-support van JetBrains.
Wat te doen bij een vermoeden van misbruik
Vind je aanwijzingen dat de aanval bij jou is geslaagd, ga dan uit van een volledig gecompromitteerde server. Patchen alleen verwijdert namelijk niet wat een aanvaller al heeft achtergelaten of meegenomen. Werk in dat geval de volgende punten af:
- Isoleer de server van internet en van omgevingen waar hij naartoe kan deployen, voordat je verder onderzoekt.
- Bewaar bewijs. Maak kopieën van logs en van de datamap voordat je gaat opschonen of herinstalleren.
- Roteer alle secrets die op de server stonden: deploytokens, SSH-keys, cloud-credentials, certificaten en API-keys. Ga ervan uit dat alles wat de server kon lezen, is gelezen.
- Controleer build-configuraties op onverwachte wijzigingen, extra build-stappen of gewijzigde scripts.
- Verifieer recente artifacts en releases die na de eerste verdachte logregel zijn gebouwd, en bouw ze bij twijfel opnieuw vanaf een schone omgeving.
- Controleer accounts en rechten in TeamCity zelf en op de onderliggende server, inclusief nieuwe gebruikers, tokens en geplande taken.
- Documenteer je bevindingen en beoordeel of er een meldplicht geldt, bijvoorbeeld richting de Autoriteit Persoonsgegevens of vanuit NIS2-verplichtingen.
Structurele maatregelen voor je CI/CD-omgeving
Dit lek is opgelost, maar het volgende komt er ooit. Een buildserver verdient daarom dezelfde bescherming als je andere kroonjuwelen. Deze drie pijlers beperken de schade van een toekomstige kwetsbaarheid aanzienlijk:
Netwerktoegang beperken
- Niet direct aan het internet hangen
- Toegang via VPN of extra beveiligingslaag
- Alleen vertrouwde netwerken toestaan
- Agents in een apart netwerksegment
Minimale rechten
- Serverproces met zo weinig rechten als mogelijk
- Server op een eigen host, los van build-agents
- Deploytokens beperken tot wat echt nodig is
- Secrets in een kluis, niet in build-configuraties
Patchen en monitoren
- Vaste updateronde voor CI/CD-tooling
- Abonneren op security-advisories van je leveranciers
- Logs centraal wegschrijven en bewaren
- Alerteren op onbekende agents en afwijkende builds
De compliance-kant: dit is geen vrijblijvend advies
Val je onder NIS2, dan is het tijdig verwerken van bekende kwetsbaarheden geen kwestie van goede bedoelingen, maar onderdeel van je zorgplicht. Aantoonbaar patchmanagement, logging die je daadwerkelijk kunt terugzoeken en een incidentproces dat werkt, zijn precies de onderdelen waar bij een audit of incident naar wordt gekeken. Een misgelopen update op een buildserver is dan niet alleen een technisch risico, maar ook een aantoonbaar tekortkomen in je beheerproces.
Verwerk deze casus daarom ook administratief: leg vast wanneer je hebt gepatcht, wat je in de logs hebt gecontroleerd en welke conclusie je daaraan verbond. Dat kost een kwartier en is later goud waard.
Conclusie
CVE-2026-63077 is het type kwetsbaarheid waar je niet mee wilt wachten: geen authenticatie nodig, uitvoering van commando’s op de server en een doelwit dat toegang heeft tot vrijwel al je omgevingen. Nu er actief misbruik is gemeld, is bijwerken naar 2025.11.7 of 2026.1.3 de belangrijkste taak van vandaag. Direct daarna volgt de controle of er in jouw logs al sporen te vinden zijn.
De volledige technische melding en de instructies voor de patch-plug-in staan in de aanvullende blogpost van JetBrains. Wil je hulp bij het bijwerken, het nalopen van je logs of het structureel dichtzetten van je CI/CD-omgeving? Neem dan contact met ons op.
- Actief misbruik gemeld: onbijgewerkte TeamCity On-Premises-servers worden nu daadwerkelijk aangevallen.
- Fix beschikbaar: update naar TeamCity 2025.11.7 of 2026.1.3; de patch-plug-in is enkel een tijdelijke noodoplossing.
- Geen inlog nodig: een aanvaller met HTTP(S)-toegang kan commando’s uitvoeren met de rechten van het serverproces.
- Controleer je logs op de genoemde exception-meldingen en je agentlijst op onbekende namen die met
scanbeginnen. - Bij vermoeden van inbraak: isoleer, bewaar bewijs, roteer alle secrets en verifieer je recente builds.
- TeamCity Cloud-klanten hoeven zelf niets te doen.
