JetBrains has pushed out security updates covering a critical code-execution vulnerability in its flagship IntelliJ IDEA editor, plus four additional high-severity flaws in its TeamCity continuous-integration server. The company is urging development teams and CI administrators to apply the patches immediately, warning that several of the issues could be reached remotely without special privileges.

The advisory lands at a moment when developer tooling and CI/CD infrastructure have become an increasingly attractive target in their own right. Rather than attacking production systems directly, intrusions that compromise an IDE or a build server can quietly ride along in every artifact those tools touch, turning a single foothold into a foothold across every downstream deployment.

What’s Fixed and Where

The fixes ship in IntelliJ IDEA versions 2026.1.4 and 2026.2, and in TeamCity versions 2026.1.2 and 2025.11.6. Teams running older 2026.1.x branches, or earlier 2025 releases, remain exposed until they upgrade.

The headline issue in IntelliJ IDEA, tracked as CVE-2026-59792, involves how the editor handles project workspace IDs. Improper handling allows a path-traversal condition that can be leveraged into code execution — a serious risk for any developer who opens a project from an untrusted or semi-trusted source, such as a cloned open-source repository.

A Cluster of Related Issues

Alongside the workspace ID bug, JetBrains addressed two further high-risk problems in IntelliJ IDEA: a command-injection flaw in the editor’s filename-completion feature (CVE-2026-49366), and a command-execution issue tied to guest accounts (CVE-2026-49367). Both give an attacker who can influence project content, or who has access to a guest session, a path to running arbitrary commands.

Remote Development — the feature that lets a local IDE connect to a backend running elsewhere, often over SSH — picked up three more fixes: unauthorized input injection (CVE-2026-64812), unauthorized modification of IDE settings (CVE-2026-64813), and unauthorized file access (CVE-2026-64814) during remote sessions. Because Remote Development is commonly used to expose IDE backends in shared or cloud environments, these issues carry extra weight for teams running that setup at scale.

TeamCity: A Critical RCE Through Git Configuration

On the CI/CD side, the most serious of the four TeamCity fixes is CVE-2026-65907, a critical remote code execution vulnerability reachable through Git version-control-system (VCS) root configuration. In practice, an attacker able to influence a repository’s Git root settings — for instance through a malicious pull request or a compromised upstream dependency — could use crafted configuration to execute code on the TeamCity server itself.

The remaining TeamCity issues include:

• CVE-2026-65906 — code execution via a sandbox escape in Kotlin DSL build configuration scripts
• CVE-2026-59793 — arbitrary file access through Perforce integration
• CVE-2026-59794 — stored cross-site scripting in cloud profile data

Taken together, these issues illustrate a consistent pattern: a compromised or malicious VCS integration can become a pivot point from ordinary source control into the build infrastructure that ultimately produces production software. A CI server that trusts repository configuration too readily effectively hands attackers a foothold in the software supply chain.

Recommended Actions

JetBrains recommends upgrading immediately to the patched releases: IntelliJ IDEA 2026.1.4 or 2026.2, and TeamCity 2026.1.2 or 2025.11.6. Beyond simply updating, security teams should:

• Review existing build configurations and Git VCS roots for untrusted or unexpectedly modified scripts
• Restrict who is permitted to define Kotlin DSL, Git, and Perforce integration roots
• Enforce project-trust prompts for IDE users opening unfamiliar codebases
• Monitor build logs for unexpected script execution or anomalous CI agent behavior

Because both the workspace-ID flaw in IntelliJ IDEA and the Git VCS root flaw in TeamCity can be triggered by content an attacker controls — a malicious project or repository, rather than direct network access — the practical risk extends well beyond organizations that expose these tools publicly. Any developer or CI pipeline that ingests code or configuration from outside sources should treat this round of patches as a priority rather than routine maintenance.

It’s also worth noting how many of this batch’s most serious issues cluster around trust boundaries that are easy to overlook: a workspace identifier, a filename-completion suggestion, a guest session, a Git configuration value. None of these are traditionally treated as attacker-controlled input, yet each became a viable path to code execution once examined closely. That pattern is a useful reminder for any team auditing its own developer tooling — the riskiest inputs are often the ones nobody thought to distrust.