Is CVE-2023-42793 (JetBrains TeamCity Authentication Bypass) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-42793 to its Known Exploited Vulnerabilities catalogue on 4 October 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. JetBrains TeamCity contains an authentication bypass vulnerability that allows for remote code execution on TeamCity Server. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this TeamCity CVE

The practical answer is less about the label and more about operational urgency. When a vulnerability is in CISA’s Known Exploited Vulnerabilities catalogue, treat it as an active threat path, not a theoretical weakness. For TeamCity, that means exposure can move quickly from initial access to code execution, credential theft, and broader compromise of the build environment.

For a build server issue, the security significance is usually bigger than the product boundary suggests. Build systems often hold source code, signing material, deployment secrets, and access to downstream environments, so exploitation can become a launch point for wider intrusion. A good example of how attackers abuse that kind of trust boundary is documented in TeamCity CVE-2023-42793 SVR exploitation 2023.

Because this question is about an exploited vulnerability, the right response is to assume the issue may already be weaponised in automation, scanning, or ransomware-enabled intrusion chains. The main decision is not whether exploitation is possible, but whether your TeamCity instance is exposed and whether it can still be reached by an attacker who can use the bypass to execute code remotely. For broader remediation sequencing on confirmed exploitation, the Zero-Day and Exploited Vulnerabilities Guide is the clearest internal playbook.

Why TeamCity exploitation is operationally dangerous

Authentication bypass flaws in CI/CD systems are especially risky because the platform often sits at the junction of source control, build orchestration, artifact production, and secret handling. Once an attacker reaches the server, they may not need to stay within the original vulnerability path for long, because the environment itself can provide the next access step. In practice, that can mean session theft, token exposure, service account abuse, or access to signing infrastructure.

The blast radius is also amplified by what CI/CD servers know. Build logs, environment variables, runner credentials, repository credentials, and deployment tokens are common targets because they help an intruder expand access or persist. That is why build-server compromise is often treated as a supply-chain event, not just a single-host incident. For teams that want a deeper control view of pipeline hardening, CI/CD Security Guide covers the adjacent defensive problem set.

When a product appears in KEV, the risk is also that exploitation may already be occurring opportunistically across many environments. The attacker does not need to know your organisation in advance, only that the service is exposed and the flaw can be reached remotely. In that sense, the relevant question becomes whether your instance is internet-facing, reachable from untrusted networks, and still running the vulnerable condition.

What to do next if you run TeamCity

The immediate practitioner step is exposure confirmation: identify every TeamCity server, whether it is internet-facing, and whether any compensating control actually blocks the vulnerable path. If you cannot prove the instance is not reachable, treat it as at risk. If the product is still in scope, prioritise vendor remediation and CISA KEV guidance over routine patch planning.

Decision rule: if the server is accessible to untrusted users or networks, assume exploitation is plausible and move straight to emergency remediation, not standard change windows. If patching or mitigation must wait, isolate the service, restrict reachability, and reduce the trust placed in that server until the exposure is removed.

What to verify: review authentication logs, administrative actions, build-job changes, new users, unexpected tokens, and any unusual outbound connections around the exposure window. If the server can reach sensitive repositories, signing systems, or deployment targets, assume those adjacent assets may also need review.

What practitioners underestimate: the compromise often extends beyond the TeamCity host itself. If the server issued credentials, signed artifacts, or had access to other systems, review those downstream trust relationships as part of the same incident judgement, not as a later cleanup task.

Practitioner takeaway: for an exploited build-platform CVE, the priority is fast containment and trust-bounds review, because remote code execution on the server can quickly become credential exposure and downstream supply-chain risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	TeamCity exploitation can expose or abuse credentials and tokens.
	AU-6 — Audit Review, Analysis, and Reporting	Checking for prior compromise depends on reviewing TeamCity activity and build logs.
Recommendation — Rotate exposed credentials and invalidated tokens tied to the compromised build server. Review server and build logs for unusual administrative actions and access patterns.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation calls for rapid identification and remediation of exposed TeamCity instances.
Recommendation — Prioritise and remediate the exposed TeamCity instance using emergency vulnerability management.
OWASP ASVS	V6 — Authentication	The CVE is an authentication bypass affecting access control to the TeamCity server.
	V8 — Authorization	Remote code execution after bypass can lead to unauthorized privileged actions in TeamCity.
Recommendation — Validate that administrative authentication paths cannot be bypassed on the server. Verify that privileged actions remain gated after authentication is bypassed or removed.

Practitioner Guidance

What to prioritise: confirm whether the instance is exposed, then compare the actual running condition against the vendor advisory and the KEV listing. If the system is externally reachable, treat the remediation path as urgent even before you finish full forensic certainty.

Evidence to retain: preserve logs, configuration state, build history, and account activity before making disruptive changes, so you can determine whether the environment was used only for access or also for lateral movement, credential capture, or artifact tampering.

Common mistake: limiting the response to “patch the app” while leaving adjacent secrets, sessions, and service credentials untouched. For an exploitation case like this, the safer assumption is that any material trust material present on or near the build server may need review.

Practitioner takeaway: exploit confirmation changes the response posture, but it does not replace exposure analysis, because the damage path is usually defined by what the build server could reach and what it could reveal.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org