JetBrains has patched a critical TeamCity On-Premises vulnerability, tracked as CVE-2026-63077, after SecurityWeek reported the issue on July 31, 2026. The flaw can let an unauthenticated attacker with HTTP or HTTPS access to a TeamCity server bypass authentication checks and execute operating-system commands with the privileges of the TeamCity server process.
JetBrains says all TeamCity On-Premises versions are affected. Fixed versions are available in 2025.11.7 and 2026.1.3, and the company also released a security patch plugin for some older deployments. TeamCity Cloud customers do not need to take action, and JetBrains said it was not aware of active exploitation at the time of publication.
Why a build server belongs in the business conversation
A CI/CD system is not just a developer convenience. It is where source code, build steps, deployment logic, secrets, and release artifacts often meet. If a build server is exposed or poorly owned, a technical patch notice can turn into a vendor accountability problem.
That matters even for companies that do not write much software themselves. A New Jersey medical practice, manufacturer, nonprofit, school, accounting firm, or professional services office may depend on a web vendor, SaaS provider, MSP, or industry software partner that uses TeamCity or a similar build pipeline. The owner may never see the server, but the business still depends on the integrity of what comes out of it.
The practical question is not only whether TeamCity was patched. It is whether anyone can prove which CI/CD systems exist, who owns them, who can reach them, what credentials they store, and whether recent builds or deployments were reviewed after a critical patch.
The decision behind the patch ticket
For an internal IT or development team, this is a direct patch and exposure review. For a business that depends on outside providers, it is a vendor evidence request. Either way, the answer should be more specific than, we are aware of it.
A responsible response should identify whether TeamCity On-Premises is in use, whether the affected server is reachable from the public internet or only through trusted networks, whether the fixed version or security plugin has been applied, and whether the TeamCity server runs with only the operating-system privileges it needs.
Owners do not need to become build engineers to ask those questions. They do need enough clarity to avoid treating a build pipeline like a mysterious back room where patching, secrets, and release integrity are nobody's business.
Questions to ask your IT provider or software vendor
- Do we, or any critical vendor supporting us, run TeamCity On-Premises?
- If yes, has CVE-2026-63077 been addressed by upgrading to TeamCity 2025.11.7 or 2026.1.3, or by applying the JetBrains security patch plugin?
- Is the TeamCity login screen, REST API, or agent polling protocol reachable from the public internet?
- Does access require VPN or another trusted-network control?
- What credentials, deployment keys, environment variables, or secrets are stored in or reachable from the CI/CD server?
- Were recent builds, artifacts, plugins, user accounts, service accounts, and deployment logs reviewed after the patch?
- Who owns future build server patching: the internal team, MSP, software vendor, hosting provider, or another party?
A practical next step
Start with an inventory question. Ask your provider for a short written answer that identifies whether TeamCity On-Premises or another self-hosted CI/CD platform is part of your environment or vendor stack. If the answer is yes, ask for the patched version, exposure status, and the date logs and credentials were reviewed.
For smaller organizations, the biggest risk is often not the vulnerability by itself. It is the missing owner. Build pipeline security sits between software development, IT operations, vendor management, and business continuity. When those responsibilities are split, patch evidence can get lost in the handoff.
TeamCity CVE-2026-63077 is a clear reason to make that ownership visible. The build pipeline may be technical, but the decision about evidence, exposure, and vendor accountability belongs on the business side of the table too.
Sources and further reading
