Your CI/CD Stack Is Now a Primary Attack Surface
The current set of critical RCE flaws in JetBrains TeamCity, GitLab, and Redis is a direct threat to enterprise CI/CD and version-control infrastructure because these bugs enable attackers to hijack build servers, repos, and data stores that sit at the heart of software delivery workflows across self-hosted environments.
Development teams like to think in terms of application bugs, but the uncomfortable truth is that infrastructure bugs in CI/CD and data layers are now more dangerous than most app issues. A TeamCity RCE vulnerability, a GitLab remote code execution chain, and a Redis security patch cycle that all touch production-grade pipelines are not abstract risks—they are ready-made paths to tamper with code, builds, and secrets. If you run on-premises TeamCity, self-managed GitLab, or stock Redis, the question is no longer whether you should patch. The question is whether you are willing to let your build and release systems remain one exploit away from a supply chain incident.
TeamCity: Unauthenticated RCE at the Heart of Your Builds
JetBrains has disclosed CVE-2026-63077, a critical TeamCity RCE vulnerability that affects all TeamCity On-Premises versions and carries a CVSS score of 9.8. This flaw allows an unauthenticated attacker with HTTP(S) access to bypass authentication via the agent polling protocol and execute operating system commands with the privileges of the TeamCity server process. In other words, an exposed TeamCity login page or REST API is now equivalent to an invitation for remote shell access on your CI server.
This is not a hypothetical edge case. TeamCity is a widely used CI/CD server, and state-sponsored groups and ransomware affiliates have previously exploited unpatched TeamCity On-Premises servers to gain footholds in enterprise networks. JetBrains has already patched TeamCity Cloud and released fixed on-premises versions 2025.11.7 and 2026.1.3, plus a security patch plugin for versions 2017.1+ for environments that cannot upgrade immediately. The official line is that there is no current evidence of in-the-wild exploitation, but waiting for proof of exploitation in your environment before acting would be reckless. If attackers compromise this server, they can expose TeamCity data, configurations, stored credentials, and even compromise build artifacts and downstream pipelines.
GitLab: Authenticated Users Can Turn Notebooks into Shell Access
On the GitLab side, a GitLab remote code execution chain shows how seemingly benign features—like Jupyter notebook diffs—can become powerful attack tools when combined with parser bugs. Security researchers have released working exploit code for a flaw that GitLab patched on June 10, which runs OS commands as the git user on any self-managed 18.11.3 server that has not been updated. The exploit requires only an authenticated user who can push to a project: they commit a crafted .ipynb file, open its commit diff, leak heap pointers, and then fire payload notebooks, all without admin rights, CI runner access, or victim interaction.
Two memory corruption bugs in the Oj Ruby JSON parser make this chain work. GitLab’s ipynbdiff notebook renderer sends repository-controlled notebook JSON into Oj::Parser.usual.parse inside a long-lived Puma worker, so attacker-controlled bytes land deep in manually managed C memory. One bug lets an attacker overwrite a nesting stack and seize control of the parser’s start callback, while another truncates an object key and returns a live heap pointer, which GitLab then renders in the diff to locate libc and redirect execution to system(). A wide range of GitLab CE/EE versions from 15.2.0 through 19.0.1 are affected, with fixes in 18.10.8, 18.11.5, and 19.0.2. There is no documented workaround; the only practical response is to upgrade. While the researchers report no known in-the-wild exploitation and note that GitLab independently reproduced the RCE, leaving self-managed instances unpatched hands an internal or compromised user a straightforward path to shell access on a highly trusted service.
Redis: RESTORE-Based RCE Chains Turn Data Stores into Attack Launchpads
Redis is also under pressure after researchers published authenticated RCE proof-of-concept exploits for stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0. All four exploit chains depend on the RESTORE command, with some paths also requiring EVAL and XGROUP, and in one case the RedisBloom module. The core issue is memory safety flaws, including a shared-ownership bug in Redis Streams and out-of-bounds writes in RedisBloom’s TDigest loader, which attackers can shape into arbitrary memory access and calls to system().
Redis responded by shipping seven security releases on July 23. Redis 6.2.23, 7.2.15, and 7.4.10 fix the Streams shared-NACK use-after-free, while Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom/TDigest out-of-bounds writes; Redis 8.8.1 completes the RedisBloom and TDigest loader fixes, with the Streams guard already present in 8.8.0. Operators are urged to upgrade to the fixed release for their deployed branch. Until that is possible, the practical mitigation is to revoke RESTORE from accounts that do not strictly require it and block untrusted network access to Redis instances. According to the project’s own release notes, there were no reported in-the-wild exploitations as of late July. But given that two of the exploited targets were recent security updates that still lacked key guards, it is clear that treating “latest minor” as inherently safe is no longer enough.
What Development Leaders Must Do Now
Taken together, these TeamCity, GitLab, and Redis issues show that CI/CD security risks now stem as much from infrastructure as from application code. A single unauthenticated TeamCity RCE, an authenticated GitLab notebook-based RCE, or a RESTORE-driven Redis exploit can expose source code, CI/CD data, Rails secrets, service credentials, and internal services reachable from these platforms. Treating them as “just more patches” misses the operational reality: these systems are the keys to your supply chain.
The priority list should be blunt. First, patch all self-hosted TeamCity instances to 2025.11.7 or 2026.1.3, or deploy the official security patch plugin if upgrades are blocked. Restrict direct internet exposure and put TeamCity behind VPNs or additional access controls. Second, upgrade self-managed GitLab to 18.10.8, 18.11.5, or 19.0.2, and assume that any user with push rights could otherwise escalate. Third, upgrade Redis to the appropriate fixed version for your branch and strip RESTORE (and EVAL where possible) from all but the smallest set of trusted accounts, while blocking untrusted network paths. The conclusion is uncomfortable but clear: if your CI/CD and version control infrastructure is not patched, your software supply chain is already in a precarious state. The only defensible stance is to treat these updates as emergency change windows, not routine maintenance.
