JetBrains heeft gebruikers van zijn cloudservice Cadence gewaarschuwd na een incident waarbij aanvallers toegang kregen tot een deel van de Cadence-omgeving. Volgens JetBrains is de oorzaak terug te voeren op een recent bekendgemaakte kritieke kwetsbaarheid in TeamCity. Daarbij roepen ze gebruikers op om zo snel mogelijk alle mogelijke credentials en secrets te roteren en bovendien om alle Cadence-uitvoeringen te beschouwen als mogelijk onbetrouwbaar. In dit artikel zetten we de kernpunten op een rij en geven we een praktisch stappenplan om schade te beperken.
De key boodschap van JetBrains is helder: na de TeamCity-breuk in Cadence moeten organisaties uitgaan van gecompromitteerde gegevens, inclusief gegevens die in backups of binnen Cadence zelf waren opgeslagen. Ook tokens die via de Cadence-plugin in PyCharm worden gebruikt, zijn door JetBrains ongeldig gemaakt.
Wat is er gebeurd met Cadence via TeamCity?
Cadence is een door JetBrains gehoste cloudcomputingdienst. Met een optionele plugin koppelen ontwikkelaars PyCharm aan Cadence om machine learning en zware workloads op cloud-GPU’s uit te voeren vanuit hun ontwikkelomgeving.
Bij het incident maakten aanvallers misbruik van een kritieke TeamCity-kwetsbaarheid, aangeduid als CVE-2026-63077 (CVSS-score 9.8). JetBrains beschrijft dat een deserialisatie van onbetrouwbare data een aanvaller die toegang heeft tot een TeamCity-server in staat kan stellen om authenticatiechecks te omzeilen en vervolgens willekeurige commando’s uit te voeren met de rechten van het TeamCity-proces.
Waarom is dit extra gevoelig voor credentials?
Omdat de aanvallers toegang kregen tot de Cadence-server, stelt JetBrains dat alles wat is opgeslagen met of via Cadence als gecompromitteerd moet worden behandeld. Dat gaat dus verder dan alleen wat “live” in gebruik was tijdens uitvoeringen.
JetBrains adviseert gebruikers om niet alleen hun credentials en secrets te roteren, maar ook om alle Cadence-uitvoeringen — inclusief inputs en outputs binnen projecten — te beschouwen als mogelijk onbetrouwbaar. Denk daarbij aan scenario’s waarin gegevens uit projectcontext of artefacts onbedoeld zijn blootgesteld.
Wat zegt JetBrains over de data die is geraakt?
Volgens JetBrains konden aanvallers gegevens uit een backup benaderen die dateert van 2024. Daarbij noemt JetBrains meerdere categorieën informatie die zijn ingezien of mogelijk zijn gecompromitteerd:
- Persoonsgegevens, waaronder gebruikersnamen, echte namen, e-mailadressen, “last-login” momenten en de laatst gebruikte IP-adressen.
- Een volledige backup van de Cadence-server uit 2024, met onder meer credentials, configuraties, artefacts en logs.
- Meerdere AWS IAM-gebruikers en bijbehorende credentials of secrets die met Cadence werden gebruikt, inclusief IAM-accounts van JetBrains-medewerkers.
- Bestanden in S3-buckets binnen AWS-accounts van JetBrains die door Cadence werden gebruikt.
Daarnaast waarschuwt JetBrains dat aanvallers mogelijk ook broncode hebben kunnen bereiken die werd gesynchroniseerd vanuit PyCharm naar de getroffen Cadence-server. Gebruikers die PyCharm vertrouwden om projectbestanden te uploaden of te synchroniseren voor uitvoering in Cadence, lopen daarmee extra risico op blootstelling van code, credentials en configuraties.
Welke rol speelt CVE-2026-63077?
Het incident draait om de TeamCity-kwetsbaarheid CVE-2026-63077. JetBrains stelt dat de exploitation in het wild actief werd, en dat de kwetsbaarheid op 5 augustus 2026 is opgenomen in CISA’s Known Exploited Vulnerabilities (KEV)-catalogus.
JetBrains ontdekte de uitbuiting volgens eigen informatie op 23 augustus 2026. Over de tijdlijn meldt JetBrains dat de intrusie heeft plaatsgevonden tussen 8 en 24 augustus 2026.
Verder geeft JetBrains aan dat de betreffende Cadence-server (api.cadence.jetbrains.com) inmiddels is uitgeschakeld. Het bedrijf geeft aan dat die server “volgens verwachting” gepatcht had moeten zijn binnen zijn eigen respons op kwetsbaarheden, maar licht niet toe waarom dat niet is gebeurd.
Wat moeten gebruikers direct doen na de TeamCity-breuk in Cadence?
JetBrains formuleert een duidelijke reeks acties. Hieronder staan de belangrijkste stappen in logische volgorde.
1) Roteer of revok e alle credentials en secrets
Gebruikers moeten direct alle credentials en secrets intrekken of vervangen die mogelijk zijn gebruikt voor Cadence-uitvoeringen. JetBrains noemt expliciet dat ook credentials of secrets die zijn opgeslagen in Cadence of in een gecompromitteerde backup, moeten worden behandeld als gecompromitteerd.
2) Behandel inputs en outputs als mogelijk onbetrouwbaar
Omdat de aanvallers toegang hadden tot de server, adviseert JetBrains om zowel de uitvoering als de gegevensstroom te benaderen alsof die niet meer te vertrouwen is. Dat betekent praktisch: ga extra zorgvuldig om met wat er is gegenereerd, opgeslagen en teruggekoppeld in projecten.
3) Controleer tokens en plugin-toegang
JetBrains heeft volgens het advies toegangstokens ongeldig gemaakt die werden gebruikt door de Cadence-plugin in PyCharm om verbinding te maken met Cadence. Daarmee verkleint JetBrains het risico dat bestaande sessies of verbindingen nog bruikbaar zijn voor misbruik.
4) Doorlicht verbonden systemen en cloudomgevingen
Naast het roteren van credentials vraagt JetBrains om aangesloten systemen te controleren op verdachte activiteiten. Het gaat daarbij onder andere om:
- AWS-accounts en rollen/policies.
- S3-buckets en objecten.
- Deploymentomgevingen.
- Package- en containerregistries.
- Andere systemen die bereikbaar zijn met de ingetrokken credentials.
Ook adviseert JetBrains om broncode repositories te controleren op ongeautoriseerde wijzigingen binnen de periode waarin de intrusie plaatsvond.
Indicatoren van compromis (IOCs) om te onderzoeken
JetBrains heeft een set signalen gedeeld om verdachte activiteiten te detecteren. Hoewel je niet alles hoeft “af te vinken”, helpen deze punten om snel te bepalen waar je aandacht moet liggen.
Vooral relevant zijn activiteiten vanaf 8 augustus 2026, bijvoorbeeld authenticatie of gedrag met credentials die eerder al in Cadence waren opgeslagen of beschikbaar waren. JetBrains noemt daarnaast IP-adressen die geassocieerd zijn met de waargenomen exploitation:
- 150.109.230.104
- 43.153.227.206
- 62.210.127.48
- 210.247.242.190
- 15.235.225.205
- 152.233.30.18
Ook noemt JetBrains signalen zoals:
- Authenticatie of andere activiteiten vanuit onverwachte IP-adressen of locaties.
- Onverwachte repository-clones of downloads, plus ongebruikelijke commits.
- Wijzigingen aan repository secrets, webhooks, collaborators of permissies.
- Nieuwe of aangepaste persoonlijke toegangstokens, API-tokens of SSH-sleutels in externe services.
- Nieuwe service accounts in externe omgevingen.
- Onverwachte wijzigingen in cloud IAM-rollen, policies of permissies.
- Onverwachte toegang tot cloud storage en objecten (zoals S3), inclusief publicatie of wijzigingen.
Deze lijst sluit aan bij een belangrijk patroon in supply chain- en ontwikkelomgevingen: als een aanvaller toegang krijgt tot de “bouw- of uitvoerketen”, kan de impact zich uitbreiden naar gekoppelde cloudresources.
Als je dit soort incidenten breder wilt vergelijken met eerdere supply chain-cases op de site, lees dan ook hoe je supply chain risico’s kunt blokkeren in webservers of wat supply chain risico’s betekenen in Git-configs voor AI-agenten.
Mogelijke gevolgen: meer dan alleen interne schade
JetBrains waarschuwt dat de blootstelling van persoonsgegevens kan leiden tot een verhoogd risico op gerichte aanvallen. Denk daarbij aan phishing, social engineering, en imitterende communicatie met gebruik van namen en e-mailadressen van getroffen personen.
Met andere woorden: zelfs als de technische toegang tot de omgeving is beëindigd, kan de impact doorwerken in de menselijke laag van cybersecurity. Organisaties doen er daarom goed aan om medewerkers te wijzen op mogelijke nepcommunicatie in de periode na het incident.
Praktisch stappenplan voor je security-team
Om de maatregelen van JetBrains goed te vertalen naar uitvoering, kun je een kort plan hanteren dat je meteen kunt starten:
- Inventariseer alle credentials en secrets die met Cadence zijn gebruikt (ook die in CI/CD, secrets stores of cloudconfiguraties kunnen zitten).
- Roteer of revok e op korte termijn alles wat mogelijk is betrokken.
- Audit de periode 8–24 augustus 2026: authenticatie, tokengebruik, repo-wijzigingen en cloud-IAM-aanpassingen.
- Controleer opslag: S3 buckets, objectwijzigingen, en ongebruikelijke toegangspatronen.
- Herzie geautomatiseerde workflows: ga na of Cadence-uitvoeringen input of output hebben geraakt die niet meer vertrouwd mag worden.
Door deze stappen te combineren met je bestaande incidentresponse-werkwijze kun je het risico op verdere misbruik minimaliseren. Cruciaal blijft dat je niet alleen technische sporen onderzoekt, maar ook mogelijke vervolgschade door datalekken meeneemt.
Conclusie
De TeamCity-breuk in Cadence laat zien hoe kwetsbaar ontwikkelketens kunnen zijn zodra een component als TeamCity wordt geraakt. JetBrains adviseert daarom om direct credentials en secrets te roteren, tokens en plugin-toegang te herbeoordelen, en alle Cadence-uitvoeringen als mogelijk onbetrouwbaar te behandelen.
Als je nu handelt volgens het advies—met focus op cloud-IAM, S3-toegang, repositorywijzigingen en de periode 8–24 augustus 2026—vergroot je de kans dat je de impact beperkt tot het minimum. Tegelijk helpt het om je organisatie bewust te maken van de bredere gevolgen, zoals gerichte phishing op basis van mogelijk blootgestelde persoonlijke gegevens.
Bron: https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html
