TeamCity Exposure Turns Project Visibility into Build Authority
TeamCity presents build results, agents, project settings, and user administration through one web application. The page is useful to developers, but a project administrator or system administrator can change build configuration, handle credentials, and influence what runs on an agent. The authorization mode determines whether a user with access to one project can reach another.
A count-only ZoomEye search on 2026-10-30 returned 8 matches for app="TeamCity" and 3,016 for title="TeamCity" between 06:41 and 06:42 China Standard Time. The product fingerprint is much narrower than the title, which is a reminder that a title can describe a documentation page or a different layout. Neither count proves that the matched host is a live TeamCity server with weak permissions.
Choose the authorization model deliberately
TeamCity documentation describes simple and per-project authorization modes. In simple mode, there are three broad levels: guest, logged-in user, and administrator. Per-project roles can be edited and propagated to subprojects. The mode is a deployment decision with runtime consequences. A complex organization should not leave all authenticated users at one project-wide role when the platform supports narrower roles.
Review guest access first. A guest role may be intended to show build status, but it can still reveal source branches, artifact names, test output, and issue references. Disable guest access unless the content is approved for anonymous viewing. Then review project administrators: they may be able to change settings that indirectly affect build permissions in another project, so their scope should be explicit.
API access needs a separate credential policy. A token can be limited to a project and a set of permissions. Create tokens for integrations rather than sharing a human password. Record the owner, purpose, project scope, and expiry. Revoke tokens when a person leaves or when an integration is rebuilt with a new identity.
Protect the super-user path and logs
TeamCity documentation describes a super-user account used for recovery and high-privilege administration. A new super-user token is generated on server start and written to the server logs. That makes log access a sensitive capability. Restrict who can read server logs, ship the logs to a protected store, and treat a super-user token in a support bundle as a credential exposure.
Do not use the super-user account for routine automation. Keep an emergency path that is tested but monitored. Rotate or invalidate the token according to the product's supported process when a host is copied, when logs are shared externally, or when an administrator leaves. Check whether the token appears in deployment automation output or diagnostic archives.
Build agents also deserve isolation. A build that runs on an agent can access the agent's environment, local files, and network. A project administrator who can alter build steps may influence another build on a shared agent even without direct project permission. Use separate agent pools for repositories with different trust levels, and keep long-lived deployment credentials off agents that run untrusted contributions.
Validate roles with test accounts
For an owned title match, confirm the login page and server owner without using a default credential. Test guest access, a logged-in user, a project administrator, and a system administrator. Compare the navigation, the API response, and the actual action. Do not stop at a hidden menu item; request the underlying endpoint from a lower-privileged account.
Test a token limited to one project against a second project. Verify that branch visibility, artifact download, build triggering, and configuration edit follow the same rule. Then remove the user from the identity provider or disable the local account and check whether an existing session or token remains usable.
Review the public-facing path separately from the management port. A proxy that authenticates the web UI may forward an API route without the same policy. Direct access to the TeamCity port can bypass a proxy entirely. Test both and close the route that is not intentionally published.
The 3,016 title matches are candidates for ownership checks, not a vulnerable-server count. TeamCity's exposure risk comes from the permissions behind the page: a build can be code execution, and a build history can be a source-code and credential history. Review the project and agent boundaries together.
Query and scope
The standalone SDK used sub_type=all, page 1, page size 1, and returned totals only. app="TeamCity" returned 8 and title="TeamCity" returned 3,016. Collection ran from 2026-10-29 22:41:45 to 22:41:48 UTC.
Top comments (0)