CVE-2026-49373

This is a command injection vulnerability masquerading as a configuration problem. CVE-2026-49373 affects TeamCity's Perforce connection configuration handler where connection parameters get interpolated into a subprocess invocation without sanitization. The root cause isn't 'configuration fields accepting unsanitized input' — every application has input fields. The issue is that Perforce client arguments are being shell-expanded into a `p4` command string. That's command injection that happens to manifest through a settings form. The remediation is unambiguous at the code level: parameterized subprocess calls instead of string interpolation. But the deeper failure is architectural. TeamCity has become a deployment orchestration hub holding credentials for artifact repositories, deployment targets, and cloud environments. Compromising the Perforce configuration doesn't give you code execution on an isolated build server — it gives you a foothold in a system with transitive trust to your entire pipeline. That's the blast radius the CVSS 8.8 doesn't capture. There's also a detection problem unique to this vulnerability class. A developer configuring a Perforce connection isn't triggering a payload — they're submitting a form that gets stored and later interpolated into a subprocess call during build execution. If nobody monitors configuration fields for unexpected content, exploitation could persist silently for months. These vulnerabilities don't leave the obvious forensic fingerprints that a network-level intrusion or anomalous process spawn would generate. The systemic question is whether other VCS connection types in TeamCity carry equivalent injection surfaces, or if this is Perforce-specific. Given the pattern — Git hooks injection, SVN pre-commit script injection, Jenkins script security bypasses — the safer assumption is that each VCS integration was written under the same unexamined assumption: 'administrators configuring VCS connections are trusted, so this interface doesn't need the same hardening as user-facing entry points.' That assumption was wrong in 2012 and it's wrong now. Prioritize the subprocess fix, then audit other VCS integrations for similar patterns. Assume all configuration inputs are untrusted at the execution layer regardless of who entered them.

Reviewed through automated stages and approved by a human before publication.