What changed

Microsoft Security published the research on 26 August 2026, describing activity it observed against three distinct AI workloads. On the LiteLLM gateway, Microsoft assesses initial access likely came through the exposed gateway surface, naming CVE-2026-42271, an authenticated command-execution issue in LiteLLM MCP stdio test endpoints, and public research chaining it with CVE-2026-48710, a Starlette host-header validation bypass, to reach unauthenticated remote code execution on vulnerable exposed deployments. The payload read the gateway’s own process environment, which Microsoft notes is exposed at /proc/1/environ in containerised deployments where the gateway runs as PID 1, filtering for keywords including master, API key, token and password, then exfiltrated what it found. On RAGFlow, Microsoft records that TenantLLM.insert() was monkey-patched “to intercept provider API keys (OpenAI, Azure, Anthropic, Gemini) on every LLM configuration event”, with the whole intrusion “fully automated with no interactive shell”. On Kestra, the Docker socket was used “to enumerate container Config.Env arrays across all running containers”, with CVE-2026-49869 given as public vulnerability context. Across the cases Microsoft observed XMRig or XMRig-like cryptomining components deployed. Microsoft characterises the initial access consistently as exploitation of internet-exposed AI workload surfaces “reachable without network restriction”.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

An AI gateway or proxy sits between an organisation’s applications and the model providers they call, routing requests and holding the credentials for those providers. LiteLLM is a widely used open-source example. A retrieval platform such as RAGFlow indexes an organisation’s own documents so a model can answer questions grounded in them. A workflow orchestrator such as Kestra runs scheduled and event-driven jobs. Microsoft’s framing is that these systems “concentrate credentials, data access, model connectivity, and execution privileges”, which is what makes them worth attacking. Tier-0 is the classification normally reserved for systems whose compromise means the compromise of everything else, such as domain controllers.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Microsoft published research on 26 August 2026 describing three intrusions into self-hosted AI workloads: a LiteLLM gateway, a RAGFlow deployment and a Kestra workflow environment. In each case the way in was an internet-exposed management surface. The attackers harvested provider API keys, established persistence and mined cryptocurrency. Microsoft’s first mitigation is a sentence worth keeping: treat AI gateways as Tier-0 secrets stores.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The decision is not technical and it does not start with a control. It starts with a question, and the question has to go outward rather than inward, because the thing being asked about is usually not in the asset register. AI platforms of this kind are commonly stood up by a development or data team as an experiment that worked, on a cloud subscription that team already had, and they become load-bearing without ever passing through a change process. That is the honest reason an organisation can be exposed here while every formal control is green. Two details from the research deserve to change how the follow-up is done. The first is the RAGFlow hook, because it inverts the standard remedy: with a hook inside the credential configuration flow, every key entered afterwards is captured as it is saved, so rotating credentials on a compromised platform hands the attacker the replacements. Rotation has to follow eviction, never precede it. The second is what the attackers did with the access. They mined cryptocurrency. This is Braintree’s point rather than Microsoft’s, but it changes who notices first: the visible effect of that is a spend anomaly on a cloud subscription, and a spend anomaly is routed to finance, not to security. On a rand-denominated Azure bill an unexplained compute increase is usually treated as a budgeting question. It is worth telling whoever reviews that bill what an unexplained compute increase can also mean.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Microsoft’s mitigation guidance is specific and is reproduced here in the order it gives. Treat AI gateways as Tier-0 secrets stores: keep LiteLLM and similar proxies patched, require authentication across API and UI surfaces, restrict administrative and management ports, and do not expose management interfaces directly to the internet. Scope and protect provider credentials: issue per-team virtual keys with spend limits instead of sharing master keys, store upstream API keys in a managed secret store rather than process environment variables, and rotate credentials associated with an exposed or compromised gateway. Apply least privilege to gateway and database access: run the proxy under a dedicated service account, limit its database permissions to the objects it needs, place the database behind a private endpoint with restrictive firewall rules, and enable Microsoft Defender for Cloud monitoring for the database and surrounding resources. Constrain outbound traffic: use deny-by-default egress rules and allowlist only required model provider and service endpoints, block direct connections to raw-IP hosts and non-standard ports, and route permitted traffic through an FQDN-filtering firewall or inspecting proxy. Monitor outbound callbacks: filter and log DNS traffic to identify out-of-band callbacks and subdomain-encoded beacons. Harden the host runtime: mount temporary directories as non-executable where operationally feasible, alert on execution from world-writable paths, and monitor changes to cron entries, SSH authorized_keys files and immutable-file attributes. Enable Microsoft Defender for Endpoint protections on Linux, keeping real-time and cloud-delivered protection on along with behaviour monitoring. The environment-variable point carries the most weight for the least work, because storing provider keys in environment variables is what most quickstart documentation tells you to do, and it is precisely what the LiteLLM payload harvested.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The head of information security jointly with whoever leads the development or data team that stood the platform up, because these systems are frequently outside the IT estate’s inventory.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Ask outward before you configure anything. Establish whether any team runs an AI gateway, a retrieval or document-search platform, or a workflow orchestrator, and whether any part of it is reachable from the internet. For anything found, get the management interface off the public internet, move model provider keys out of process environment variables into a managed secret store, and rotate every key that has ever lived on an exposed deployment.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The dated inventory of AI platform deployments with, for each one, the owning team, whether the management interface is internet-reachable, where provider credentials are stored, and the date each credential was last rotated. Retain the egress rules applied and the DNS logging configuration, since Microsoft’s guidance names both.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

Does this affect Azure OpenAI or Microsoft’s own AI services?

No. The research concerns self-hosted, mostly open-source AI infrastructure that organisations run themselves: an AI gateway or proxy, a retrieval platform and a workflow orchestrator. The exposure described is of those deployments, not of Microsoft’s managed services.

How did the attackers get in?

Microsoft describes the initial access in all three cases as exploitation of internet-exposed AI workload surfaces reachable without network restriction. For LiteLLM it names CVE-2026-42271 chained with CVE-2026-48710 as a public route to unauthenticated remote code execution on vulnerable exposed deployments.

What did they take?

Credentials, principally. Microsoft describes the payload reading the gateway’s process environment and filtering for master keys, API keys, tokens and passwords, and on the RAGFlow deployment a hook placed in the credential configuration flow that intercepted provider API keys for OpenAI, Azure, Anthropic and Gemini on every configuration event.

If I rotate my API keys, am I safe?

Not if the platform is still compromised. Microsoft’s RAGFlow finding is that the hook intercepted keys on every LLM configuration event, which means new keys entered while the hook is present are captured as they are saved. Remove the compromise first, then rotate.

What would I actually notice?

Microsoft records cryptomining components being deployed on the compromised hosts. Braintree’s point rather than Microsoft’s: the practical first symptom of that is an unexplained increase in compute spend, which normally reaches finance before it reaches security.

We do not run any of these. Does it still matter?

The specific products matter less than the pattern, which is a management interface for a system holding many credentials, reachable from the internet. The useful action is to establish whether anyone in the organisation runs something of that shape, which is a question rather than a scan.

What is the single highest-value change?

Getting the management interface off the public internet, and moving provider keys out of process environment variables into a managed secret store. Both appear in Microsoft’s first two mitigations, and the second directly defeats the credential harvesting described in the LiteLLM case.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.