CVE-2025-46618

What it actually does

This is a stored cross-site scripting flaw in JetBrains TeamCity versions before 2025.03.1 affecting content rendered on the Data Directory tab. An attacker who can place malicious content into the affected stored field or configuration value can cause JavaScript to execute in the browser of another TeamCity user who later views that page. Because the script runs in the TeamCity web origin, it may be able to perform actions with the victim user’s privileges, read page-accessible data, issue authenticated requests to TeamCity APIs, alter build or project configuration, create or modify users/tokens if the victim has sufficient privileges, or pivot toward CI/CD supply-chain compromise.

Why it matters to the business

Successful exploitation can turn a TeamCity administrative page into a vehicle for account takeover or unauthorized CI/CD changes, especially if an administrator views the affected Data Directory tab. The most serious business consequence is compromise of build pipelines, secrets, deployment credentials, or released artifacts through actions performed as a privileged user. Although it is not listed in CISA KEV and there is no known public exploit maturity reported, the EPSS score is elevated, so internet-accessible or broadly reachable TeamCity instances should be prioritized for upgrade.

How an attack unfolds

An attacker first needs a way to store attacker-controlled markup in the TeamCity data displayed by the vulnerable Data Directory tab. This could be through an authenticated low-privilege account, abuse of an exposed administrative function, social engineering of a user who can modify the affected value, or chaining with another vulnerability that allows configuration tampering. The attacker stores a payload such as HTML or JavaScript event-handler code. When a privileged TeamCity user later opens the Data Directory tab in a vulnerable TeamCity version, the application renders the stored value without sufficient output encoding. The browser executes the attacker’s script in the TeamCity origin. From there, the script can make same-origin requests as the victim, harvest page-visible data, modify TeamCity settings, create persistence through tokens or users if permissions allow, or alter build pipeline behavior. The attacker may then use the compromised CI/CD system to access source code, secrets, artifacts, or deployment workflows.

How to fix it

Upgrade JetBrains TeamCity to version 2025.03.1 or later. If immediate upgrade is not possible, restrict access to TeamCity to trusted networks or VPNs, limit access to administrative pages, reduce the number of users with permissions that can modify data shown on the Data Directory tab, and enforce least privilege for TeamCity administrators and project maintainers. Review and harden TeamCity authentication, enable MFA where available, rotate exposed or suspicious access tokens, and review CI/CD secrets if exploitation is suspected. Do not rely solely on WAF filtering because stored XSS payloads may already reside in application data and execute later inside authenticated sessions.

How to confirm the fix worked

Confirm the running TeamCity version is 2025.03.1 or later using the TeamCity administration UI, server startup logs, or package/container metadata. Review upgrade records to ensure all TeamCity nodes, containers, or images were updated, not only the primary server. After patching, inspect the Data Directory tab and related administrative pages for unexpected markup rendering; user-supplied values should display as inert text rather than executable HTML or JavaScript. If safe testing is authorized, use a harmless encoded test string such as a non-executing HTML marker and verify it is escaped. Confirm reverse proxies or caches are not still serving an older TeamCity instance. Review TeamCity audit logs for unauthorized administrative changes before and after remediation.

Typical attack path

1. Identify a TeamCity instance running a version earlier than 2025.03.1.
2. Obtain access or find a workflow that allows attacker-controlled content to be stored in data displayed on the Data Directory tab.
3. Submit a stored XSS payload using script tags, JavaScript URLs, SVG payloads, or HTML event handlers.
4. Wait for or lure a privileged TeamCity user to open the Data Directory tab.
5. Execute JavaScript in the victim’s browser under the TeamCity web origin.
6. Use the victim’s privileges to issue authenticated TeamCity requests, change configuration, create tokens/users, or alter CI/CD settings.
7. Abuse TeamCity access to reach source code, build secrets, artifacts, deployment credentials, or downstream environments.

How to detect it

Investigate whether attacker-controlled HTML or JavaScript was stored in TeamCity data rendered by administrative pages, especially the Data Directory tab. Review TeamCity server logs, audit logs, authentication logs, build configuration history, reverse proxy or load balancer access logs, WAF logs, and endpoint browser telemetry for administrators. Look for requests containing encoded or plain XSS payloads, including script tags, JavaScript URLs, SVG onload payloads, iframe/object/embed tags, and HTML event handlers such as onerror or onload. Correlate suspicious payload submissions with later administrative page views and subsequent privileged actions, such as user creation, token creation, permission changes, project setting changes, build step modification, VCS root changes, plugin installation, or secret/parameter updates. Also review unexpected outbound connections from administrator browsers immediately after visiting TeamCity administrative pages, as injected scripts may beacon to attacker-controlled infrastructure. Because exploitation is stored, payload submission and payload execution may occur at different times and from different users.

• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onmouseover=
• onclick=
• <svg
• %3Csvg
• <iframe
• %3Ciframe
• <img
• %3Cimg
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• /app/rest/users
• /app/rest/userGroups
• /app/rest/projects
• /app/rest/buildTypes
• /app/rest/vcs-roots
• /app/rest/server
• Data Directory

What your security team should do

• Upgrade all TeamCity servers to 2025.03.1 or later as the highest-priority corrective action.
• Treat internet-accessible TeamCity instances and instances used for production deployments as urgent because of the elevated EPSS score and CI/CD impact.
• Restrict TeamCity administrative access to trusted networks, SSO groups, and MFA-protected accounts.
• Review TeamCity users, groups, access tokens, project permissions, build configuration changes, and recent administrative activity for signs of misuse.
• Search TeamCity logs, reverse proxy logs, and application data for stored XSS payload patterns such as script tags, JavaScript URLs, SVG payloads, and HTML event handlers.
• Rotate TeamCity access tokens, deployment credentials, and CI/CD secrets if suspicious XSS payloads or unauthorized administrative actions are found.
• Add monitoring for suspicious TeamCity API activity performed shortly after an administrator views administrative pages.
• Document exposure status and patch completion for all TeamCity deployments, including containers, test servers, and disaster recovery instances.