Vulnerability Analysis

CVE-2024-27199: JetBrains TeamCity Authentication Bypass via Path Traversal — How to Detect, Fix & Harden Your CI/CD Pipeline

Executive Summary

CVE-2024-27199 is an authentication bypass vulnerability in JetBrains TeamCity On-Premises, stemming from a path traversal flaw (CWE-22) in the server's web component. An unauthenticated remote attacker can exploit this flaw to access restricted endpoints — leaking sensitive information and modifying system settings — without ever logging in. Added to CISA's Known Exploited Vulnerabilities (KEV) catalog on April 20, 2026, this vulnerability is being actively exploited in the wild and demands immediate patching or mitigation by any organization running an unpatched TeamCity instance.

1. What Is This Vulnerability?

JetBrains TeamCity is a widely-used continuous integration/continuous delivery (CI/CD) platform trusted by development teams worldwide to automate their build, test, and deployment pipelines. Because TeamCity servers often hold source code access credentials, deployment keys, API tokens, and privileged infrastructure secrets, they are extremely high-value targets for attackers.

CVE-2024-27199 exists in the web component of TeamCity On-Premises. The root cause is improper enforcement of authentication controls on certain URL paths. Specifically, TeamCity's web server incorrectly allows requests to URLs that contain a /../ path traversal segment to bypass authentication middleware and reach restricted JSP pages and servlet endpoints that would otherwise require a valid session.

The Mechanics of Path Traversal Authentication Bypass

TeamCity enforces authentication by checking whether a request URL belongs to a set of "protected" paths. The flaw allows an attacker to craft a URL that starts with an unprotected path (such as /res/ or /update/) and then uses path traversal notation (/../) to redirect the request to a sensitive endpoint behind the authentication gate.

Example — Bypassing authentication to reach the HTTPS certificate upload endpoint:

GET /res/../../../../app/https/settings/uploadCertificate HTTP/1.1
Host: teamcity.targetcompany.com

The authentication check sees the request begin with /res/ (a public resource path) and passes it through without requiring credentials. The underlying servlet engine then normalizes the path traversal segments and delivers the request to /app/https/settings/uploadCertificate — an admin-only endpoint — as though it were authenticated.

Endpoints known to be reachable via this bypass include:

  • /app/https/settings/uploadCertificate — allows replacing the server's HTTPS certificate
  • /app/https/settings/setPort — allows changing the HTTPS listener port
  • Certain JSP pages and diagnostic servlets that expose system configuration details and environment variables

Attack Vector

Attack complexity: Low
Authentication required: None
User interaction required: None
Network access: Remote (HTTP/HTTPS)

An attacker with network access to a TeamCity server needs only to send a single crafted HTTP GET request to exploit this vulnerability. No account, session cookie, or credentials of any kind are needed.

Real-World Impact

Exploitation of CVE-2024-27199 has been observed in conjunction with its higher-severity sibling, CVE-2024-27198 (CVSS 9.8), which allows full unauthenticated remote code execution. Threat actors — including ransomware groups deploying Jasmin ransomware — have chained these vulnerabilities together: using CVE-2024-27199 to gather reconnaissance and modify server settings, then escalating to full system compromise via CVE-2024-27198.

Telemetry from security vendors has documented attackers using these flaws to mass-create unauthorized admin accounts on vulnerable TeamCity servers — a persistence mechanism designed to survive patching. LeakIX reported hundreds of such rogue user accounts being created across compromised instances in the weeks following initial disclosure in March 2024. Active exploitation continues as of April 2026, prompting CISA to mandate remediation by federal agencies.

2. Who Is Affected?

Attribute Details
Vulnerable product JetBrains TeamCity On-Premises
Vulnerable versions All versions prior to 2023.11.4
TeamCity Cloud Not affected (cloud instances were patched proactively by JetBrains)
Attack surface Any instance with a network-accessible web interface (port 80, 443, or custom)
Risk multiplier Servers exposed to the public internet are at extreme risk; internal servers are also at risk from insider threats and lateral movement

Organizations at elevated risk include:

  • Software development companies using TeamCity for CI/CD automation
  • Enterprises with TeamCity instances accessible from the internet (even behind VPNs with split tunneling)
  • Any organization that has not patched since before March 3, 2024
  • Organizations that patched the server but did not audit for backdoor accounts created before patching

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Identify your TeamCity version

Log into TeamCity as an admin and navigate to Administration → Server Administration → Diagnostics. Note the version number displayed. If the version is earlier than 2023.11.4, the server is vulnerable.

Alternatively, the version is often visible unauthenticated at:

https://<teamcity-host>/login.html

Look for a version footer or check /version.txt if exposed.

Step 2: Test for authentication bypass manually

From an unauthenticated browser session (use incognito mode or a fresh curl command with no cookies), send a path-traversal request to a known restricted endpoint:

curl -sk "https://<teamcity-host>/res/../../../../app/https/settings/setPort" -o response.txt
cat response.txt
  • Vulnerable result: You receive a response from the settings endpoint (HTML form, JSON response, or HTTP 200/302 with content) rather than a redirect to the login page.
  • Patched result: You are redirected to /login.html with an HTTP 302 or receive an HTTP 401/403 error.

Step 3: Check for unauthorized admin accounts

Even if you have since patched, log in and navigate to:
Administration → User Management → Users

Sort by creation date. Any accounts created between the vulnerability disclosure date (March 4, 2024) and your patch date that you cannot attribute to legitimate personnel should be treated as attacker-created backdoor accounts and immediately disabled and investigated.

Automated Scanning

Tool: Nuclei (ProjectDiscovery)

A community Nuclei template exists for CVE-2024-27199. Run it as follows:

nuclei -u https://<teamcity-host> -t cves/2024/CVE-2024-27199.yaml -o nuclei-output.txt
  • Expected vulnerable output: [CVE-2024-27199] [http] [high] https://<teamcity-host>/... with matched response body
  • Expected patched output: No match, or 302 redirect to login

Tool: Tenable Nessus / Tenable.io

Nessus plugin 191749 (jetbrains_teamcity_2023_11_4.nasl) detects CVE-2024-27199 by querying the version endpoint. Run an authenticated or unauthenticated web application scan against the TeamCity host.

Tool: Burp Suite Pro

  1. Navigate to the TeamCity login page with Burp intercepting traffic.
  2. Use the Burp Intruder or Repeater module to send a crafted GET request with path traversal (/../) segments to the /res/ and /update/ paths.
  3. Look for HTTP 200 responses that contain content inconsistent with a login redirect.

Code Review Checklist (for custom TeamCity plugins or integrations)

  • Confirm all API calls to TeamCity use authenticated sessions with valid tokens
  • Verify no hardcoded TeamCity credentials exist in build scripts or .env files
  • Check that TeamCity service accounts follow the principle of least privilege
  • Review webhook configurations for unauthorized external destinations
  • Audit TeamCity build pipeline scripts for injected or modified steps

4. How to Fix It (Mitigation)

Step-by-Step Remediation

Option A: Upgrade TeamCity (Strongly Recommended)

  1. Back up your TeamCity data directory before making any changes:

    tar -czf teamcity-backup-$(date +%Y%m%d).tar.gz /var/lib/teamcity/

  2. Download TeamCity 2023.11.4 or later from the official JetBrains download page:
    https://www.jetbrains.com/teamcity/download/

  3. Stop the TeamCity server service:

    sudo systemctl stop teamcity

  4. Apply the upgrade following JetBrains' official upgrade guide (unpack new binaries to the TeamCity installation directory, preserving the data directory).

  5. Restart TeamCity and verify the new version in the Administration panel.

  6. Audit admin accounts (see detection step 3 above) before restoring full operations.

Option B: Install the Security Patch Plugin (if immediate upgrade is not possible)

JetBrains released a standalone security patch plugin that can be installed on all TeamCity versions through 2023.11.3 to address both CVE-2024-27198 and CVE-2024-27199 without a full upgrade.

  1. Download the plugin from the JetBrains security advisory page.
  2. In the TeamCity Administration panel, go to Administration → Plugins → Upload plugin zip.
  3. Upload the security patch plugin ZIP file.
  4. Restart the TeamCity server.

⚠️ The plugin is a temporary workaround only. Plan and execute a full upgrade to the latest stable TeamCity release as soon as operationally feasible.

Code Fix Example (Understanding the Root Cause)

The vulnerability exists in TeamCity's URL authentication filter. A simplified example of the flaw vs. the correct pattern:

// VULNERABLE: checks only the raw (non-normalized) request URI prefix
public boolean isPublicPath(String requestUri) {
    return requestUri.startsWith("/res/") || requestUri.startsWith("/update/");
}

// If requestUri = "/res/../../../../app/https/settings/uploadCertificate"
// isPublicPath() returns TRUE — auth check is skipped!

// CORRECT: normalize the path before checking against the allowlist
public boolean isPublicPath(String requestUri) {
    String normalized = URI.create(requestUri).normalize().getPath();
    return normalized.startsWith("/res/") || normalized.startsWith("/update/");
}

// Normalized path = "/app/https/settings/uploadCertificate"
// isPublicPath() returns FALSE — auth check enforced correctly

Configuration Hardening

Restrict network access immediately:

If you cannot patch right now, use a firewall or reverse proxy to restrict access to the TeamCity web interface:

# Nginx: block path traversal requests at the proxy layer
server {
    location ~ \.\. {
        return 403;
    }
    location / {
        proxy_pass http://teamcity-backend:8111;
    }
}

Restrict public internet exposure:

TeamCity should never be directly accessible from the public internet. If it must be, place it behind a VPN or an IP allowlist at the network perimeter.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Confirm the path traversal bypass is blocked — send the crafted request from Step 2 of the detection section and verify a 302 redirect to /login.html or an HTTP 401 is returned.
  • Scenario B: Confirm that legitimate authenticated admin access still works — log in with valid admin credentials and verify all Administration panels are accessible.
  • Scenario C: Confirm that CI/CD pipelines and build agents continue to connect and run builds successfully after the upgrade.
  • Scenario D: Confirm that no unauthorized admin accounts exist in User Management (see detection step 3).

Security Test Cases

Test Case 1: Verify path traversal authentication bypass is remediated

  • Precondition: Apply patch (upgrade to 2023.11.4+ or install security patch plugin); restart TeamCity
  • Steps:
    1. From a machine with no active TeamCity session, run: curl -skv "https://<host>/res/../../../../app/https/settings/uploadCertificate"
    2. Inspect the HTTP response
  • Expected Result: HTTP 302 redirect to /login.html — the endpoint is no longer reachable without authentication

Test Case 2: Verify HTTPS certificate cannot be replaced without authentication

  • Precondition: Patched TeamCity instance
  • Steps:
    1. Generate a self-signed certificate: openssl req -x509 -newkey rsa:2048 -keyout test.key -out test.crt -days 1 -nodes
    2. Attempt to upload it unauthenticated: curl -sk -X POST "https://<host>/res/../../../../app/https/settings/uploadCertificate" -F "certificate=@test.crt"
  • Expected Result: Upload is rejected; login redirect returned

Automated Tests

import requests
import sys

TEAMCITY_HOST = "https://your-teamcity-host"
BYPASS_URL = f"{TEAMCITY_HOST}/res/../../../../app/https/settings/setPort"

def test_auth_bypass_remediated():
    resp = requests.get(BYPASS_URL, verify=False, allow_redirects=False, timeout=10)
    
    # A patched server should redirect to the login page
    assert resp.status_code in (302, 401, 403), (
        f"FAIL: Got HTTP {resp.status_code} — server may still be vulnerable!"
    )
    if resp.status_code == 302:
        location = resp.headers.get("Location", "")
        assert "login" in location.lower(), f"FAIL: Unexpected redirect to {location}"
    
    print(f"PASS: Auth bypass blocked (HTTP {resp.status_code})")

if __name__ == "__main__":
    test_auth_bypass_remediated()

Run this script from a host with network access to TeamCity. A PASS result confirms the bypass is blocked.

6. Prevention & Hardening

Best Practices

  • Keep TeamCity current. Subscribe to the JetBrains Security Bulletin and maintain a patch cadence that ensures you apply security releases within 72 hours of disclosure for any critical or high-severity CVEs.

  • Never expose TeamCity to the public internet. Place TeamCity behind a VPN, private network, or at minimum an IP allowlist firewall rule. CI/CD servers are crown jewels — they should not have an internet-facing attack surface.

  • Apply the principle of least privilege to TeamCity accounts. Service accounts used by build agents should have only the permissions needed to run builds. No service account should have server administrator privileges.

  • Rotate all secrets after any confirmed or suspected compromise. If you cannot rule out exploitation during the window between disclosure and patching, treat all credentials stored in TeamCity (VCS passwords, deployment keys, API tokens, environment variables in build configurations) as compromised. Rotate them immediately.

  • Enable Multi-Factor Authentication (MFA) on all TeamCity admin accounts. This won't prevent authentication bypass vulnerabilities but limits the blast radius if credentials are compromised through other means.

Monitoring & Detection

Configure your SIEM or log management system to alert on the following patterns in TeamCity access logs and web server logs:

1. Path traversal attempts:

# Pattern to detect `/../` traversal segments in HTTP requests
grep -E '(/\.\./)' /opt/teamcity/logs/teamcity-server.log

2. Unexpected admin account creation:

Enable TeamCity audit logging (Administration → Audit Log) and alert on User created events, particularly for accounts with Administrator roles, especially outside business hours.

3. Anomalous access to sensitive endpoints:

Alert on any access (successful or not) to the following paths from unauthenticated sessions:

  • /app/https/settings/
  • /app/admin/
  • /app/rest/server

4. Unusual build agent connections:

Monitor for new build agents registering with the server from unexpected IP addresses — a common indicator that an attacker has pivoted to use your CI/CD infrastructure as a launchpad.

SIEM detection rule example (Splunk):

index=web_logs host=teamcity sourcetype=access_combined
| regex uri="(/\.\./)|(/%2e%2e/)"
| stats count by src_ip, uri, http_method, status
| where count > 5
| table _time, src_ip, uri, status, count

References

Latest from the blog

See all →