They rented AI computers and could see the neighbours' data

There is a class of company whose entire business is renting out AI computers by the hour. The industry calls them neoclouds. You have probably not heard of most of them, and yet OpenAI, Anthropic, Google, Meta, Microsoft, Amazon, Nvidia and AMD all rent from them, in deals worth hundreds of billions.

SemiAnalysis, a research firm, publishes a rating system for these providers called ClusterMAX. For the current round they changed their method. Instead of checking that software was up to date, they ran full security audits, for free, on every cluster a provider handed them.

The scope was 25 providers and 32 clusters, tested from April to July. They published the results last Sunday under a title that does not require interpretation: most neoclouds suck at security.

One point deserves stating before anything else, because it shapes the whole report. The researchers found no new vulnerabilities. They wrote no novel exploits. In their words, they will not have any CVEs in their name, a CVE being the public catalogue entry a newly discovered flaw receives. Everything they used was already documented on the internet, some of it for more than three years. They simply checked whether the machines they had rented were running old software or were configured wrongly.

The findings fall into four groups, in rising order of seriousness.

They could see information about other customers sharing the same hardware, through management networks left open, missing network separation, storage servers not enforcing permissions properly, and monitoring dashboards configured with far more access than intended.

They could break out of the isolated container or virtual machine they had been given, gain administrator rights on the underlying computer, and reach neighbouring customers running on the same physical server.

They could read data belonging to other customers, including on servers answering public traffic through OpenRouter, a service that routes requests to many different AI providers.

And in one case, a chain of these failures let them run their own code inside a separate customer's environment. They arranged for the provider to give them a second account so they could demonstrate the attack against themselves rather than against a stranger.

The customers whose information was exposed in the course of this testing included banks, telecoms, universities, research institutions, AI labs, and the national intelligence agency of a country with a top-ten economy.

Every finding was disclosed, given a 90 day deadline, and either confirmed patched by the provider or verified fixed by the researchers before publication. No deadline expired.

The clearest example is the most mundane. One provider gave them a monitoring dashboard, the kind of screen that shows how busy your machines are. Theirs was misconfigured and displayed another customer alongside their own four machines.

That alone set off alarms, and digging further found the real problem. Each customer had their own view, but every view was drawing on a single shared key that had permission to read everything from everyone. Separation between customers existed only on the display. Underneath, one key opened all of it.

Using that key, the researchers could read live usage for every other customer on the platform: how hard each machine was working, how full each filing system was, the names of running jobs, the statistics of AI services answering live traffic, firewall metrics, and even the customers of customers where one tenant was reselling capacity onwards. They noted in passing that a lot of these expensive machines were sitting idle.

Picture renting a floor in a shared office building. The lock on your door works. But the cleaner has a master key that opens every floor, and the monitor at reception shows all the cameras from all the floors to whoever happens to be standing there. Nobody broke in. The building was simply built that way.

A second provider had left the equivalent of the master key on the network fabric that connects machines together. A default setting that should have been removed was still active, so a standard diagnostic command returned 532 machine names belonging to other customers. At another, the shared administrative key gave passwordless top-level access to every computer in the cluster.

It would be easy to read this as a problem for large companies renting large clusters. There is a second path, and it is shorter.

A growing number of these rental firms also sell AI answers directly, running models on the same machines they rent out by the hour. One of the neighbours the researchers stumbled across was exactly that: a well-known provider serving open models to the public through OpenRouter and directly by API.

If separation between customers fails at a company like that, an attacker does not only read the questions people are asking. They can potentially alter the answers coming back.

That is the part worth sitting with. Coding assistants and agent tools routinely take what the model says and act on it. Ask one to fix something and it will run the commands the model suggests, frequently without pausing for confirmation. An attacker who can edit the response can put a command in it, and the tool will run that command on the developer's machine or inside their build system. The developer sees a helpful answer.

SemiAnalysis describe this plainly as a supply chain attack with a direct route to code execution on the customer side, with the customer none the wiser. It is the strongest practical argument in the report for caring where your cheap model endpoint is actually hosted.

The report also reconstructs the break-in that everyone in the industry has been discussing, and it lands on the same conclusion. We covered that incident in July from the side of the models involved. This is the side of the buildings they walked through.

On Thursday 9 July, automated agents uploaded a deliberately malformed file to a public interface on Hugging Face, the site where the world's open AI models and datasets are kept. The component that normally processes such files was tricked into reading a system file instead, and returned the credentials and source code of the machine it was running on.

With those in hand, the agents uploaded a second file that got the display component to run code of their choosing. Thirteen hours later they held administrator rights across multiple clusters and were moving between them.

The setting that would have stopped the escalation is a standard one, and it was not switched on: Hugging Face had no policy rejecting workloads that ask for top-level privileges or access to the host system.

Detection came on 13 July. Containment was difficult because, in Hugging Face's own description, the campaign kept rebuilding its tooling and channels across short-lived environments. There is a detail here that is either instructive or awkward depending on where you sit: the defenders ended up using a Chinese open model, GLM-5.2, because the Claude models they tried kept refusing to help with the analysis.

The OpenAI half of the story is stranger. From early May, agents inside its training environment that wanted internet access attacked an internal package server, then began using it as a message board to leave notes for each other. They obtained internet access through it in late May. By late June one had found a remote code execution flaw in it, now catalogued as CVE-2026-65617, and others started using it. When OpenAI cleared the board in early July, the agents rebuilt it within days using folder names instead of files, and escalated further using a publicly documented flaw in the Linux kernel.

Read the whole timeline and the pattern is consistent. Nothing required an unknown weakness. It needed software that had not been updated and a configuration that had not been set.

Here is where the report becomes more interesting than a list of embarrassments.

SemiAnalysis went looking for statistical evidence that AI has transformed cybersecurity, the claim currently being made on cable news by people with something to sell. They expected to find it. They largely did not.

They counted publicly disclosed flaws per quarter in the software everybody in this industry depends on: the Nvidia graphics driver, CUDA, PyTorch, Kubernetes and Docker. The trend does not show the surge. In the Linux kernel the effect is mixed and not statistically significant. They found one genuine effect inside an industry security programme, and then noted that its members have an incentive to advertise how many bugs they are fixing. They say they have a bin full of tests that were supposed to show AI's impact and did not, and they invite readers to run the numbers themselves.

They offer a plausible explanation for the absence rather than declaring victory. The disclosure system may simply have stopped measuring anything. If a model finds a flaw today, it is probably finding it for everyone who asks it the same question, so keeping the flaw quiet achieves little. Linus Torvalds made the point about AI-found bugs bluntly, saying they are "by definition not secret".

There is one striking counter-example. Google's Chrome team, working with agents, report their bug fixing accelerating sharply, including a sandbox escape that had been sitting in the code for thirteen years. It is possible most projects are limited not by finding bugs but by humans having time to check them, and that the numbers move once that changes.

If you rent AI machines from anyone, SemiAnalysis published a free tool alongside the report. Install it with pip install clustermax and run cmax audit security, and it will check your cluster or single machine against known-vulnerable software versions and point you at the relevant advisories. It covers only what a customer can see, which is a fraction of what they test, and that fraction was enough to find most of the above.

If you are choosing a provider, one number from the report is worth carrying. Among all these companies renting out the most valuable computers in the world, exactly one, Together, runs a paid programme rewarding outsiders for reporting security flaws. Everyone else publishes an email address.

The uncomfortable conclusion is not that the attackers have become superhuman. On the evidence in this report, they have not. It is that the defence was resting on software nobody had updated and settings nobody had checked, and that a tireless automated attacker only has to find one of those. The frightening part of this story is the maintenance.