JetBrains is warning of a critical security vulnerability in its TeamCity DevOps platform that could allow unauthenticated attackers to execute arbitrary operating system commands on vulnerable servers.

“If exploited, this vulnerability may allow an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary commands,“ the company said in a security advisory.

The flaw, tracked as CVE-2026-63077, affects all TeamCity On-Premises deployments and has been fixed in versions 2025.11.7 and 2026.1.3.

JetBrains warned that the flaw potentially exposes build environments, stored credentials, and software supply chains. Customers unable to upgrade are advised to deploy a security patch plugin immediately.

TeamCity Cloud customers are not required to take any action, the company reassured.

RCE achieved without authentication

According to JetBrains, the vulnerability resides in the TeamCity agent polling protocol, allowing an attacker with HTTP(S) access to bypass authentication and execute code with the privileges of the TeamCity server process.

The vulnerability carries a CVSS score of 9.8 out of 10 as it requires no authentication or user interaction, making internet-exposed TeamCity servers particularly attractive targets. Classified under CWE-502 (deserialization of unstructured data), the flaw can be used to send specially crafted data through the affected agent polling protocol to trigger remote code execution (RCE).

“Depending on the privileges granted to the TeamCity server process, a successful attack could expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines,” the company added.

The issue was privately reported on July 10 by security researcher Antoni Tremblay through JetBrains’ coordinated disclosure process.

JetBrains said it had found no evidence of active exploitation at the time of publishing the advisory.

Developers have two mitigation paths

JetBrains is recommending that customers upgrade directly to TeamCity 2025.11.7 or 2026.1.3, both of which include a permanent fix for the vulnerability.

Organizations unable to upgrade immediately can instead deploy a security patch plugin, which is available for TeamCity versions 2017.1 and later. Servers running versions 2017.1 through 2018.1 require a restart after installing the plugin, while newer supported releases can enable the fix without restarting, the company added.

The company also advised administrators whose TeamCity servers are publicly accessible to restrict external access if neither mitigation can be applied immediately.

“As a general best practice, we strongly recommend limiting network access to TeamCity servers to trusted networks wherever possible,” the company said. “We also recommend running the TeamCity server with the minimum operating system privileges required for normal operation.”

Given the vulnerability’s pre-authentication nature and the history of threat actors rapidly weaponizing TeamCity flaws, organizations running self-hosted CI/CD infrastructure are advised to prioritize emergency patching over routine maintenance windows.

The advisory also recommended running TeamCity servers on dedicated hosts separate from build agents, as per official instructions.

The article originally appeared on CSO.

A critical vulnerability in the open-source AI agent platform Ruflo could allow unauthenticated attackers to take control of enterprise AI environments by exploiting an exposed Model Context Protocol (MCP) bridge, according to research published by Noma Security.

The flaw, tracked as CVE-2026-59726 and dubbed RufRoot, carries a maximum CVSS score of 10.0 and affects Ruflo versions prior to 3.16.3, Noma Security wrote in a blog post.

The vulnerability allows attackers to execute arbitrary code, steal large language model (LLM) API keys, access user conversations, hijack AI agents, and manipulate the platform’s persistent AI memory through a single HTTP request.

The researchers said the issue stems from an unauthenticated MCP Bridge that is exposed by default and provides direct access to the tools AI agents use to interact with enterprise systems.

“The MCP Bridge isn’t a random auxiliary debug interface; rather, it is Ruflo’s central nervous system. Every tool call, every agent action, every memory operation goes through the MCP bridge,” the researchers wrote. “Mistakenly giving unauthenticated access to the MCP Bridge means giving unauthenticated access to everything.”

One request leads to full compromise

According to Noma Security, Ruflo’s built-in MCP Bridge is an Express.js server that handles every tool invocation made by AI agents. The bridge exposes 233 tools covering shell access, database operations, agent management, and memory storage.

The researchers said the bridge’s /mcp endpoint accepts tool invocations without authentication. In a proof-of-concept demonstration, they used Ruflo’s terminal_execute tool to obtain command execution inside the container with a single HTTP request.

“Because the MCP Bridge requires direct access to the underlying system resources to execute these commands, it creates a high-stakes security boundary,” the researchers wrote. “When an attacker can reach this endpoint without authentication, they gain a direct pipeline to the underlying host infrastructure.”

The researchers said they were able to enumerate available tools, steal LLM provider API keys from environment variables, deploy attacker-controlled AI agent swarms, retrieve user conversations stored in MongoDB, and establish persistence.

The researchers also demonstrated what they described as AI memory poisoning by inserting malicious entries into Ruflo’s AgentDB pattern store, allowing future AI responses to incorporate attacker-controlled instructions.

Every stage of the attack chain was validated against a default Ruflo deployment running on AWS EC2, according to the researchers.

Beyond Ruflo: A broader MCP security challenge

While the authentication flaw is specific to Ruflo, security practitioners say the research highlights broader risks surrounding AI orchestration platforms and MCP infrastructure.

“MCP adoption has outpaced the security defaults built into a lot of orchestration tools,” said Amit Jena, AI Development Manager at Kanerika. “These platforms shipped fast, prioritized ease of setup over authentication, and assumed the network boundary would protect them. That assumption breaks down once the tool sits on a server reachable from a corporate network, which is increasingly where enterprises are running them.”

Jena said the research also points to a security concern that extends beyond a single product.

“The memory poisoning problem isn’t product-specific, and that’s the part worth paying attention to,” he said. “Any platform that gives agents a persistent, writable memory store needs to treat that store as a security boundary: who can write to it, and can you tell system-generated memory from memory an attacker planted. Very few platforms are doing that today.”

He added that, unlike traditional persistence techniques, poisoned AI memory can remain inside a trusted data store and continue influencing future agent behavior after the original intrusion has ended.

Patch addresses attack chain

Noma Security said it disclosed the vulnerability responsibly to Ruflo, which released fixes within hours along with a public security advisory.

According to the researchers, the updated release changes the MCP Bridge to bind to the loopback interface by default and fail closed if administrators attempt to expose it publicly without configuring authentication.

Noma Security also urged organizations running Ruflo to immediately close firewall access to ports 3001 and 27017, rotate all LLM API keys, audit AgentDB for malicious entries because “a patched redeploy alone doesn’t undo poisoning,” and inspect MongoDB for signs of tampering.

Jena said organizations should also review how AI orchestration platforms are deployed and managed.

“If a component can execute a shell command or query a database, it gets the same authentication, network segmentation, and logging as any other privileged system in the environment,” he said. He also recommended that security teams inventory the tools exposed through AI agent deployments, audit persistent AI memory separately from software patching, and narrowly scope and rotate LLM provider credentials following any suspected exposure.

The article originally appeared on CSO.

One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, according to the Cursor Developer Habits Report. The bottleneck is no longer writing software. It is understanding what happens after that software ships.

Every new service, dependency, feature flag, generated abstraction, and deployment path increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it.

The result is a production environment that changes faster than engineers can rebuild a mental model of it. AI can help in this situation because most debugging practices were designed for a slower world.

Debugging yesterday and today

For decades, debugging was largely a spatial problem. A failure in Service A belonged to the team that owned Service A. They knew the deployment history, the operational quirks, the useful log queries, and the odd behaviors that never made it into the runbook. Incident response reflected that assumption. Teams owned services. Runbooks were scoped to those services. On-call rotations mirrored organizational boundaries.

That model still works when failures stay local. If a deployment introduces a memory leak, or a bad configuration causes a service to crash, the symptom and the cause usually live in the same place. The owning team can investigate, identify the issue, and restore service. Those incidents are becoming a smaller share of production failures.

AI-generated code is not inherently less reliable than human-written code. The change is volume and speed. Teams can now introduce more code, touch more systems at once, and evolve architectures faster than before. As systems become more interconnected, failures increasingly surface somewhere other than where they start.

A single-hop incident is local. The service experiencing the failure is also the service causing it. Investigation stays inside one team’s boundary.

A multi-hop incident looks different. The checkout API begins timing out. Nothing appears wrong inside checkout. Latency is normal. Error rates are low. The actual problem is a queue consumer silently dropping messages because a schema change deployed two days earlier was only partially backward compatible. The queue team sees healthy throughput. The data platform team never receives a page because nothing in its service violates an alert threshold. Every team is right about its own system, yet nobody can explain why customers cannot complete purchases.

The problem is not a lack of evidence. Modern production systems produce more telemetry than any human can use during an incident. The problem is knowing which evidence matters, which signals are coincidental, and how separate clues connect into a causal chain.

The role of AI in production ops

That changes the role AI should play. AI should not be treated as a magic on-call engineer. A frontier model does not know your architecture. It does not remember prior incidents. It does not know which dashboards lie, which services fail together, what changed last week, or which dependencies matter most. On its own, it reasons inside a vacuum.

The useful version of AI in production is more specific. It can assemble context, test hypotheses, trace dependencies, compare the current incident against past incidents, and rule out explanations that do not fit the timing or blast radius. It can do the work that currently eats the first 20 minutes of an incident: gathering evidence, checking recent changes, mapping dependencies, and narrowing the search space.

Humans still make the decisions that require judgment. They decide whether the evidence is strong enough to act, whether a rollback is worth the risk, whether to wake another team, and whether the safest move is mitigation or deeper investigation. But they should not have to spend half the incident reconstructing a system the organization already operates.

That is the larger productivity shift.

If AI can absorb more of the troubleshooting tax, engineers can focus on the work that actually compounds. They can simplify fragile architectures. They can improve instrumentation in the places where incidents repeatedly go dark. They can design safer degradation paths, sharper alerts, better rollback patterns, and evals that catch semantic failures before customers do. They can feed production knowledge back into development, so code assistants and review processes understand which services are risky, which patterns have caused outages, and which dependencies deserve extra scrutiny.

This is the work engineers rarely get enough time to do because they are stuck resolving the same classes of incidents again and again.

Letting the engineers engineer

The goal is not to remove engineers from production. The goal is to stop wasting their judgment on work the system should already be doing. AI should make incidents shorter, but that is only the first-order benefit. The larger benefit is giving senior engineers more time to prevent future incidents instead of being pulled into every confusing one.

As AI accelerates software creation, production operations need the same kind of acceleration on the other side. Not just faster debugging. Better allocation of human attention.

The AI code avalanche will not be managed by asking engineers to troubleshoot forever at machine speed. It will be managed by making production systems more legible, more resilient, and less dependent on whichever expert happens to be awake.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Microsoft has shipped Visual Code 1.131, an update to its code editor with improvements for monitoring subagents, dictation, and Markdown editing.

Released July 29, Visual Studio Code 1.131 can be downloaded for Windows, Linux, or Mac at code.visualstudio.com.

An enhancement to the Agents window in VS Code 1.131 allows developers to see what a running subagent is doing without opening its conversation. For each subagent, the main conversation now shows the model used by the subagent, how long the subagent has been running, and the tool the subagent is actively calling.

A preview of built-in dictation across VS Code gives developers dictation capabilities without having to install the VS Code Speech extension. The transcription service works in chat inputs, text editors, and the terminal, Microsoft said. A single speech session and microphone selection are shared across all three surfaces, which prevents overlapping recordings and keeps dictated text in the intended location, according to the company. This is an experimental feature.

VS Code 1.131 also introduces a hybrid Markdown editor in the Agents window, allow users to view Markdown files, edit them in place, and add comments that an agent can act on. By using “Reopen editor with”, developers can switch easily between the text editor and the new Markdown editor, both in the Agents window and editor windows. The hybrid Markdown editor is an experimental feature.

For accessibility, screen reader users now can read terminal output at their own pace while commands continue to produce output. Set terminal.integrated.accessibleViewPreserveCursorPosition to always preserve the cursor position in the terminal Accessible View, including when new content arrives. Existing true and false values continue to work. Terminal live updates also use a non-interrupting ARIA status announcement instead of an assertive alert. Output remains available to screen readers without repeatedly interrupting other speech.

VS Code 1.131 followed VS Code 1.130 by one week. VS Code 1.132 should arrive soon.