CVE-2023-34220

What it actually does

This vulnerability is a stored cross-site scripting flaw in JetBrains TeamCity versions before 2023.05, specifically in the Commit Status Publisher window. A user with sufficient access to place crafted content into the affected TeamCity feature can cause malicious script to be stored and later executed in another user's browser when that user views the impacted TeamCity interface. Because the CVSS scope is changed, successful exploitation can cross a trust boundary from TeamCity-stored content into the victim user's browser session, enabling theft or misuse of UI-accessible data, unauthorized actions as the victim within the TeamCity web application, or manipulation of displayed build/status information. It does not directly provide server-side code execution, but it can be used to compromise administrative sessions or pivot within CI/CD workflows if a privileged TeamCity user views the malicious content.

Why it matters to the business

An attacker who can plant malicious content in the affected TeamCity area may be able to hijack or abuse another user's TeamCity session, including sessions belonging to build engineers or administrators. In practical terms, this can lead to unauthorized changes to CI/CD configuration, exposure of build metadata or secrets visible in the web interface, tampering with build and commit status information, and loss of trust in software delivery pipelines. The vulnerability is not listed in CISA KEV and has no known ransomware association from the provided data, but its EPSS score is high enough to warrant prioritization, especially because TeamCity commonly sits in sensitive software build environments.

How an attack unfolds

An attacker first obtains or uses a low-privileged TeamCity account, or another role that can influence data shown in the Commit Status Publisher window. They craft a payload containing JavaScript or HTML designed to execute when rendered by the TeamCity web UI. The payload is saved into a field or object that TeamCity stores and later displays in the Commit Status Publisher context without proper neutralization. When another user, especially a project administrator or server administrator, opens the affected TeamCity page, the browser executes the attacker's script in the context of the TeamCity application. The script can then perform actions available to the victim's session, read accessible page content, manipulate UI state, issue authenticated requests to TeamCity endpoints, or exfiltrate data to attacker-controlled infrastructure. The attacker may use the resulting access to modify project settings, tamper with build status publishing, or stage further CI/CD compromise.

How to fix it

Upgrade JetBrains TeamCity to version 2023.05 or later. If immediate upgrade is not possible, reduce exposure by limiting TeamCity web access to trusted networks or VPN, restricting Commit Status Publisher configuration permissions to trusted administrators, reviewing and removing untrusted or unusual Commit Status Publisher configuration values, and enforcing least-privilege roles for TeamCity users. Consider adding or tightening browser-side and reverse-proxy protections such as Content Security Policy where feasible, but do not treat these as a substitute for upgrading. After remediation, rotate credentials, tokens, or secrets that may have been exposed through TeamCity pages if exploitation is suspected.

How to confirm the fix worked

Confirm the running TeamCity version is 2023.05 or later through the TeamCity administration UI, startup logs, package manager, container image tag, or vendor distribution metadata. Review TeamCity projects and build configurations that use Commit Status Publisher features and verify that user-controlled fields are rendered as text rather than executable HTML or JavaScript. In a non-production test instance or approved validation environment, attempt to save a harmless XSS test string such as a non-exfiltrating alert payload in the affected configuration path and confirm it is escaped or rejected after upgrade. Also verify that access controls prevent low-privileged users from modifying Commit Status Publisher settings unless explicitly required.

Typical attack path

1. Gain authenticated access to TeamCity with a role capable of configuring or influencing Commit Status Publisher data.
2. Create or modify Commit Status Publisher-related content with a crafted stored XSS payload.
3. Wait for a higher-privileged user to view the affected TeamCity window.
4. Execute JavaScript in the victim's browser under the TeamCity origin.
5. Use the victim's authenticated browser session to read accessible TeamCity information or send unauthorized TeamCity requests.
6. Optionally change CI/CD configuration, tamper with build status publishing, or exfiltrate sensitive data visible to the victim.

How to detect it

Investigate whether malicious script content was stored in TeamCity Commit Status Publisher-related configuration or displayed fields before upgrade. Relevant sources include TeamCity audit logs, project configuration change history, server logs, reverse-proxy or WAF logs, browser telemetry or EDR data from administrator workstations, and network egress logs. Look for TeamCity requests that create or modify Commit Status Publisher settings containing HTML tags, JavaScript event handlers, encoded script payloads, data URIs, or references to unfamiliar external domains. Review access patterns where a low-privileged user modified project or publisher configuration shortly before an administrator viewed the affected page. On endpoints used by TeamCity administrators, look for browser connections to suspicious external callback hosts shortly after visiting TeamCity pages. If version control stores TeamCity Kotlin DSL or XML configuration, search repository history for script-like payloads in TeamCity project configuration. Because the vulnerability is stored XSS, compromise evidence may appear as malicious configuration content, anomalous authenticated TeamCity actions performed by a victim user, or external web requests from a victim browser rather than malware on the TeamCity server itself.

• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• navigator.sendBeacon
• eval(
• atob(
• btoa(
• data:text/html
• data:application/javascript
• Commit Status Publisher

What your security team should do

• Prioritize upgrading all JetBrains TeamCity instances to 2023.05 or later, with urgency increased for internet-accessible or broadly accessible instances.
• Inventory TeamCity instances, including containerized and embedded deployments, and confirm no pre-2023.05 versions remain in service.
• Restrict TeamCity administrative and project configuration access to trusted users and enforce least privilege for roles that can edit VCS, build, and Commit Status Publisher settings.
• Audit Commit Status Publisher configurations and recent project configuration changes for suspicious HTML, JavaScript, event handlers, external URLs, or obfuscated payloads.
• Review TeamCity access logs, audit logs, and reverse-proxy logs for suspicious requests around Commit Status Publisher pages and unusual outbound connections triggered from administrator workstations.
• If suspicious payloads are found, treat privileged TeamCity user sessions as potentially compromised and rotate exposed access tokens, VCS credentials, build secrets, and integration tokens.
• Add SIEM detections for stored XSS indicators in TeamCity configuration changes, including script tags, JavaScript URI handlers, common event-handler attributes, and external callback domains in TeamCity-related parameters.