🔥 Critical TeamCity RCE (CVE-2026-63077): Patch Your On-Prem Instances Now
TeamCity On-Prem users, we have a critical situation here. JetBrains just dropped an advisory for a vulnerability allowing unauthenticated remote code execution. With a CVSS score of 9.8, this is about as bad as it gets for a CI/CD pipeline.
The flaw affects all on-prem versions prior to the latest fixes (2025.11.7 or 2026.1.3). Since this is pre-auth, an attacker doesn't need valid credentials to run OS commands on your build server.
If you can't patch immediately, I highly suggest restricting access to the web interface at the perimeter. I'm currently auditing my fleet to ensure we aren't exposed. Here is a quick bash snippet to help identify your current TeamCity build version on Linux servers:
grep -E 'version|build.number' /path/to/teamcity/conf/teamcity-startup.properties
You should also start hunting for suspicious web requests. While specific IOCs are still emerging, monitoring for anomalous POST requests to the REST API is a solid starting point. Here is a basic KQL query if you are forwarding IIS/Apache logs to Sentinel:
WebEvent
| where UrlPath has "/app/rest/"
| where RequestMethod == "POST"
| project TimeGenerated, SrcIpAddr, UrlPath, UserAgent
| summarize Count() by SrcIpAddr, UrlPath, bin(TimeGenerated, 15m)
| where Count_ > 10
Given the persistence mechanisms available through compromised build agents, how is everyone handling the forensic review after patching? Are you blowing away agents and rebuilding from scratch, or just checking for recent artifacts?
Thanks for the heads-up. We just finished pushing 2025.11.7 to our dev environment, but prod is going to take a few hours due to the pipeline freeze.
If anyone is struggling with downtime, remember that TeamCity allows you to pause the server without stopping the build agents. You can patch the server core first to block the RCE vector, then update agents later. Just make sure you block external access to port 8111 at the firewall level until the core is updated.
Great post. As a pentester, I can't stress enough how valuable these CI/CD servers are. If you pop the build server, you often get domain admin access via the service account or can steal secrets from the build environment.
I've drafted a quick Sigma rule to catch potential mass-scanning attempts for this CVE assuming the vulnerability path is similar to past TeamCity issues:
detection:
selection:
cs-method: 'POST'
cs-uri-query|contains: '/app/rest/'
sc-status: 500
condition: selection
We're seeing a lot of noise on port 8111 already in our honeypots. I'd recommend checking your logs for any User-Agent strings that look like standard Python libraries (e.g., 'python-requests/2.28.0') hitting unusual endpoints—automated exploit scanners often use defaults.
Building on Diana's point, if you're running TeamCity behind Nginx, you can automate the log hunting for those library strings. Here’s a quick one-liner to isolate potential scanning IPs and sort them by frequency:
grep -i "python-requests" /var/log/nginx/teamcity-access.log | awk '{print $1}' | sort | uniq -c | sort -nr
If you see a high frequency of requests from a single IP, block it immediately at the firewall level while you wait for the patch window.
Since this is pre-auth, isolating the server behind a VPN is crucial if patching is delayed. You can quickly enforce this by locking down port 8111 to your internal subnets using iptables:
iptables -A INPUT -p tcp --dport 8111 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8111 -j DROP
Just remember to adjust the CIDR range for your specific VPN network.
Great points on the network side. For those needing to quickly verify if an external instance is vulnerable before diving into logs, I whipped up a small Python script to check the version headers:
import requests
target = "http://target-url:8111"
resp = requests.get(target)
print(f"Detected TeamCity Version: {resp.headers.get('X-TeamCity-Version')}")
Just swap the URL and see if it returns a version older than 2025.11.7.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access