CVE-2024-27199 – JetBrains TeamCity relative path traversal – quick fix guide

What breaks and who should care

If your scanner just shouted CVE-2024-27199, you are looking at a relative‑path traversal bug in JetBrains TeamCity. It lets an attacker walk the file system and perform a handful of privileged actions without needing full admin rights. Anyone running a TeamCity server – whether it hosts internal builds, public CI pipelines, or third‑party integrations – should treat this as a high‑severity incident.

Related remediation guides

Other vulnerabilities in the same family or affecting the same products:

• CVE-2024-23897 – Jenkins CLI Path Traversal – What you need to know and fix now
• CVE-2025-26633 – Immediate steps for Windows MMC vulnerability
• CVE-2025-49706 – SharePoint Server improper authentication – what you need to know and fix now

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

Vulnerability summary

The National Vulnerability Database rates the flaw at 7.3 (high) on the CVSS scale. The description says the bug could allow “limited admin actions to be performed”. That is the official wording – the exact set of actions is not published, but the impact is enough to change configuration, read files outside the intended directory, or trigger other unsafe behaviour.

Class of issue

This is a classic relative path traversal. An endpoint accepts a path component from the request, concatenates it with a base directory, and then uses the result without proper validation. By inserting sequences such as ../ an attacker can climb out of the intended folder and reach locations that should be off‑limits.

The vulnerability lives in the web UI handling of certain file‑related requests. Because the UI runs with the same rights as the TeamCity service account, the attacker inherits those rights once the traversal succeeds.

How the flaw works

JetBrains has not released a detailed technical write‑up, so the exact request pattern is not public. The general pattern for a relative‑path traversal is:

• A request parameter (often called path or file) is taken from the HTTP payload.
• The server joins that value to a known base directory, for example /opt/teamcity/data/.
• No canonicalisation or whitelist is applied, so strings like ../../etc/passwd are accepted.

When the server later reads or writes using the constructed path, it ends up touching files outside the data folder. In TeamCity’s case, those files include configuration files that control build agents, authentication tokens, or even the internal SQLite database used for user permissions. By reading or overwriting those files, an attacker can elevate their influence without needing the full admin password.

Is your server vulnerable?

First, verify which version of TeamCity you are running. The simplest way is to query the server directly:

• From the command line on the host, run teamcity-server.sh status or teamcity-server.bat status. The output includes a line like “Version: x.y.z”.
• If you prefer the web UI, log in and open the Administration → Diagnostics page. The version is displayed at the top right.

Compare the reported version with the entries in the table below. If the version appears in the “affected” column, you are at risk.

Next, check whether the vulnerable endpoint is reachable from the network. Use a tool such as curl to request a known UI page and look for the presence of the teamcity cookie – that indicates the web service is listening.

curl -I http://your-teamcity.example.com/app/rest/

If you receive a 200 OK response, the service is reachable and the vulnerability could be exploited.

Mitigation steps

The vendor has released a patched build that resolves the traversal. The official guidance is to upgrade to the patched release for your branch as soon as possible. Follow these steps:

• Back up your TeamCity data directory and the internal database. This is standard practice before any upgrade.
• Download the latest installer from the JetBrains website. Choose the package that matches your operating system (Linux, Windows, Docker, etc.).
• Stop the TeamCity service: systemctl stop teamcity or service teamcity stop on Linux, or use the Services snap‑in on Windows.
• Replace the existing installation directory with the new files, preserving the conf and data folders.
• Start the service again and verify the version output shows the patched release.

If you cannot upgrade immediately, the CISA advisory recommends applying mitigations per the vendor’s instructions. JetBrains provides a configuration flag that disables the vulnerable endpoint. Add the following line to teamcity-server.properties and restart the service:

teamcity.disable.traversal.endpoint=true

Disabling the endpoint removes the attack surface but may break any integrations that rely on the affected API. Test in a staging environment first.

For cloud‑hosted instances, follow the guidance in BOD 22‑01. That includes:

• Ensuring the server is only reachable from trusted IP ranges.
• Enabling multi‑factor authentication for all admin accounts.
• Activating audit logging and forwarding logs to a SIEM.

These steps do not replace a patch, but they raise the bar for an attacker who might otherwise exploit the traversal.

If you cannot patch right now

Sometimes operational constraints prevent an immediate upgrade – for example, a long release cycle or a dependency on a specific plugin version. In those cases, you should adopt defence‑in‑depth measures:

• Network segmentation: Place the TeamCity server behind a firewall that only allows traffic from CI agents and trusted developers. Block all inbound traffic from the internet.
• Least‑privilege accounts: Review user permissions and remove any unnecessary admin rights. The vulnerability only grants limited admin actions, so reducing the number of users with those rights limits impact.
• File‑system permissions: Ensure the service account cannot write to system‑wide locations such as /etc or C:\Windows. Restrict write access to the TeamCity data directory only.
• Log monitoring: Enable detailed request logging in teamcity-server.log. Look for suspicious patterns like repeated ../ sequences in URLs. Set up an alert that fires on any match.
• Application firewall: Deploy a web‑application firewall (WAF) that blocks requests containing path traversal payloads. Most commercial WAFs have a rule set for ../ attacks.

These controls buy you time while you arrange the upgrade. They do not eliminate the flaw, but they make successful exploitation considerably harder.

Next steps

1. Verify your current version against the table below.
2. If you are on an affected build, schedule the upgrade to the patched release without delay.
3. If you must stay on the old build, apply the vendor‑provided configuration flag and tighten network and host controls.
4. Keep an eye on the CISA Known Exploited Vulnerabilities catalogue for any new guidance.

Remember: the vulnerability is already being used in ransomware campaigns. Acting now reduces the chance that an attacker will turn a simple path traversal into a full‑blown data breach.

For a quick reference, see the table below which lists the affected and fixed releases for TeamCity.

Affected versions

Straight from the NVD record for CVE-2024-27199. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
teamcity	* up to 2023.11.4	2023.11.4