AI Infrastructure Under Attack | Why The Breaches Keep Happening At Runtime

AI infrastructure is having a rough change of seasons…

In the past three months, attackers have moved past treating AI environments as another cloud estate and gone straight for the parts that are running: the inference engine, the Python environment, the API key that executes and the GPU that computes.

The last month has seen breaches at Railway, OpenCode and Northflank, three platforms developers use to build and run AI applications, and all three ended with stolen AI provider keys. Add to that an inference provider whose model weights were accessed, an inference engine exploited for RCE on a live server, a botnet stealing resources from exposed AI servers, and the same AI gateway delivering a supply chain attack twice within the year.

Observe these AI infra incidents as a class, and a pattern starts to form. In each attack, the decisive compromise happened at runtime, and in a place where most security stacks have very little visibility. For many customers, the first sign was the impact itself: their AI keys being spent by someone else. In this blog, I'll do a quick recap of what happened, why AI keys and runtimes have become the prize, and why the supply chain is now one step away from your model weights, aka your production AI integrity.

I Haven't Read Any News, What's Been Happening?

Here's a quick sample of recent incidents. Each is an attack on AI infrastructure as it's running.

Date (2026)	Incident	What happened at runtime
9 Nov	NEAR AI	A remote code execution flaw in the SGLang inference engine let an attacker run code inside a live inference server, where requests in processing, confidential ones included, were observable
30 Oct	Northflank	Attackers decrypted secrets held in the control plane, and customers then reported their AI provider keys being used. Northflank patched CVE-2026-98432, a critical use-after-free in the Linux kernel's IPv4 TCP networking code, across its fleet
24 Oct	Fireworks AI	An attacker came in through a breached third-party cloud provider, ran an unauthorized workload on R&D machines, and reached secrets, datasets and incomplete model weights for a limited group of customers
21 Oct	LiteLLM 1.107.0	A credential stealer shipped through LiteLLM's own release pipeline, about 49,000 downloads before removal
20 Oct	Railway	A privilege escalation in build infrastructure led to decrypted environment variables in up to 1.85% of workspaces, about 100,000
17 Oct	OpenCode	AI provider keys stored by 1.4% of Console users were exposed and used to run up charges
7 Oct	PoeLLM	Lumen's Black Lotus Labs found more than 2,100 exposed servers, including LiteLLM and Ollama hosts, conscripted into cryptomining

There's no single adversary lesson with IoCs or patch recommendations here. Each initial access was a different misconfiguration, bug or leak. However, it is worth recognizing that there is serious value in AI runtime infrastructure, and attackers are increasingly targeting (and increasingly able to capitalize on) this threat surface.

Costs and Consequences

Railway says "at most 1.85% of all workspaces" were affected, about 100,000, and that the attacker was "attempting to obtain AI provider API keys to perform distillation attacks". Let's dial in on their response though. Alongside rotating credentials and rebuilding internal tooling, they deployed a new generation of single-tenant builders. In other words, when shared infrastructure was the way in, the fix was isolation at runtime, and they had to build it. Shared infrastructure only works if the boundary between tenants holds, a gap we've written about before in The GPU Security Gap Nobody Owns.

Across these incidents, attackers were often taking obvious routes to profit: resource theft, either to spend your money funding their own outcomes (or further attacks), or to make money directly through cryptomining. We've reproduced the cryptomining route ourselves against exposed Ray clusters in ShadowRay 2.0, where a job submitted through an open API ends with GPUs mining cryptocurrency. While some organizations may view the risk of compute or AI provider theft as negligible, there's further impact here.

Users of OpenCode reported that Google suspended some of their projects for "abusive activity consistent with hijacked resources". Consider that. A suspended Google Cloud project takes down everything running in it. These users connected an AI coding tool to their cloud, a compromise of that tool leaked their keys, and the result was an environment, potentially hosting their core service to customers, taken offline.

These attackers weren't interested in the platforms they were targeting. They wanted either keys to frontier models, aka compute on tap, which can be resold or used to train a model of their own, or access to sensitive customer IP and model weights.

Are We Even Seeing The Full Scope Of These Attacks?

LiteLLM has now had malicious versions published under its own name twice, the second time through its legitimate release pipeline. Both times, live projects that updated, or that pull unpinned or latest versions automatically, ran malicious Python in their environment.

The first instance carried a payload that harvested cloud, Kubernetes and SSH credentials, attempted to spread across Kubernetes clusters and installed a persistent backdoor. The corrupted version ran whenever any Python process started in an affected environment, whether or not that process used LiteLLM. In the second, a stealer again ran on every Python start, and a second payload polled a GitHub dead drop every hour for new Python code to run.

As above, both payloads went after credentials. That makes sense, they're the keys to the kingdom. As far as anyone currently knows, neither touched models. However, would we have known if they did?

Consider what "runs in every Python process" means in AI environments. Training jobs are Python processes. So are inference servers, fine-tuning scripts and evaluation harnesses. Code running inside all of them shares their reach: it can read a checkpoint, rewrite it on disk, or alter tensors in memory before they're saved. Worse, pickle-based checkpoint formats execute code when they're loaded, so a tampered file can carry its own backdoor to every machine that loads it.

Change just a few lines, and an attack goes from stealing credentials to quietly editing the weights that dictate how your models behave. The result is a poisoned model that passes every package scan, ships through a legitimate pipeline and looks exactly like the model you trained.

This isn't a hypothetical technique. In Hands Off: Detecting Model Weight Tampering, we demonstrated a model-editing attack that changes weights directly in GPU memory, and showed how runtime tracing catches it.

Why Are These Attacks So Hard To See?

These are tough to detect, and even harder to stop as they’re happening. Part of that is because a lot of the AI Runtime stack is uninstrumented. These attacks as they run are often seen by endpoint tooling as Python doing Python things. Nothing looked wrong, because from where those tools sit, nothing was.

This is especially true when attackers use legitimate access to do the wrong job. NEAR AI's incident illustrates this well. Its stack ran inside a confidential computing enclave which, in its own words, "protects data from the operator and the host". The attacker didn’t contend with confidential computing, but with the inference software running inside it. NEAR AI's own takeaway was to start "treating the inference software and the services around the enclave with the same rigor". We recommend that lesson (and more) for every AI operator.

To be clear, the gap is runtime context: which process loaded which model, which job is using which GPU, and whether this workload is the one that was actually scheduled. Without that view, stolen compute and stolen access both look like normal operations, right up until the bill, the leak or the poisoned model arrives. The difference between abuse and misuse of AI infrastructure deserves a deep dive of its own, and we'll cover it in a follow-up blog.

The Stealthium Perspective

If you run AI infrastructure, here are four steps worth taking this week:

Treat model weights as integrity-critical artifacts: Hash them at save, verify them at load, and prefer formats that do not execute code on load.
Know what runs on your GPUs: A workload nobody scheduled, beyond a utilization spike, could be an incident.
Watch how model access is used, not just who holds the key: Quota enumeration, tiny validation requests and sudden volume from new addresses are early warnings.
Pin and verify your AI dependencies: Assume a credential committed anywhere public is already in someone's hands.

Runtime is where we work at Stealthium: the GPU driver, the CUDA runtime and the AI workloads running above them. It's also where our research keeps finding problems, from GPUBreach to an NVIDIA DCGM Exporter flaw we caught in a working day, and you can find the rest in our AI runtime security research.

More importantly, this Thursday, we are publishing two more: NvRoot and ForgePtr, NVIDIA driver vulnerabilities that take an unprivileged user on a shared GPU host to root. Stay tuned, because the pattern above runs all the way down to the driver.

Let’s Wrap It Up

AI infrastructure is being targeted. Compromise is happening at runtime, and is reaching the keys, the compute and the models. The attacks of the past month didn't need anything particularly brilliant to get in. That said, each one of them did its damage while the software was running. Staying ahead means seeing what's actually running, not just what was deployed.

If you want to talk through what runtime visibility looks like on your infrastructure, book a briefing.