Progress Software’s Telerik Report Server carries a high-severity privilege-assignment flaw, tracked as CVE-2026-106145 and rated CVSS 7.1. The bug lives in the service-agent SignalR hub. An authenticated user, including a low-privilege or guest account holding a valid bearer token, can register as a trusted service agent. On the next server settings-synchronization event, that rogue agent receives storage settings and encryption private keys. The advisory covers Report Server versions prior to 12.2.26.1007.

Read the mechanism closely and the interesting part is not the score. It is the trigger. The attacker does not need to crack anything, escalate through a memory-corruption chain, or race a patch window. They need a bearer token and patience until the next sync. The server then does the exfiltration for them, pushing secrets to a party it has already decided to trust.

Why a reporting tool sits under the AI stack

Telerik Report Server is not an AI product. It is a .NET reporting and document-generation platform, the kind of thing that ends up wired into internal dashboards, finance systems, and operational tooling because it was already licensed. That is exactly why this matters for AI teams.

The secrets the rogue agent collects are the operational ones: stored data-source credentials and connection strings. In a lot of shops, those credentials point at the same warehouses, Postgres instances, and object stores that feed retrieval pipelines, feature stores, and evaluation harnesses. A reporting server is rarely the crown jewel. It is frequently the key to the room where the crown jewel is kept.

There is a second-order effect specific to AI infrastructure. Encryption private keys are not just for report templates. Teams reuse key material and secret stores across services because managing separate trust domains is expensive and slow. When a reporting tier leaks a connection string to a vector database or a cloud storage bucket holding training artifacts, the blast radius is not a set of quarterly PDFs. It is the corpus.

The SignalR hub is the real story

SignalR is Microsoft’s real-time messaging library for .NET, built on WebSockets with fallbacks. It is a common choice for agent-style architectures: a central server dispatching work to registered workers, each holding a persistent connection back to the hub. Report Server’s service-agent pattern follows that shape. Agents register, the server syncs settings to them, and tasks get dispatched.

The flaw is a classification error. The hub assigns trust to a registrant based on insufficient checks. Progress calls it “incorrect privilege assignment,” and that phrasing is doing a lot of work. The server has a notion of “trusted service agent,” and the boundary between trusted and untrusted was drawn in the wrong place.

This is the same class of mistake that keeps showing up in agentic systems. A hub that accepts registrations, a trust label applied at registration time, and a sync event that pushes configuration downstream. Swap SignalR for a custom gRPC control plane or a message queue, swap “service agent” for “worker node” or “tool executor,” and the shape is identical. The vulnerability is not exotic. It is a design pattern.

What the advisory actually tells defenders

The NVD entry is thin on exploitation detail and does not name a public proof of concept. That is normal for a fresh CVE and it means the practical question is exposure, not exploitability.

Three things are concrete. First, the fix is a version bump: 12.2.26.1007 or later. Second, the precondition is authentication, which lowers the severity score but not the risk in environments where guest accounts, service accounts, or shared tokens exist. Third, the payload is secrets, which means the incident response is credential rotation, not just patching.

That last point is where most organizations will under-respond. Patching closes the registration path. It does not un-leak the private keys that a rogue agent may have already received during a prior sync. If a Report Server instance was reachable and running a vulnerable build, the honest assumption is that any secret it held should be treated as exposed.

The advisory also flags agent impersonation and interference with task dispatch. That is a integrity problem layered on the confidentiality problem. An attacker who can impersonate an agent and meddle with dispatch is not just reading secrets. They are in the scheduling path.

The AI-adjacent lesson

AI teams have spent two years bolting agent frameworks onto existing enterprise software. The control planes are new. The trust models underneath them are often inherited from older products that were never designed with adversarial registration in mind.

CVE-2026-106145 is a reminder that the weakest link in an AI pipeline is frequently a reporting server, a scheduler, or a legacy integration nobody thinks of as AI infrastructure. The bearer token is the new perimeter. The sync event is the new exfiltration channel.

For builders, the operational takeaway is narrow and unglamorous. Inventory the services that hold connection strings to your data and model stores. Check whether any of them implement a registration-plus-sync pattern. Assume that a “trusted agent” label applied at registration is a hypothesis, not a guarantee.

What to watch: whether Progress publishes a technical root-cause writeup, and whether the service-agent registration pattern shows up in other Telerik products that share the same hub code. The CVE is patched. The pattern is not.