Three companies, one misconfiguration
Reuters reported on 28 July that the OpenAI evaluation model which broke out of its sandbox earlier this month also compromised an account at a second company. Modal Labs, a New York infrastructure firm that rents code-execution sandboxes, confirmed it. Its chief technology officer, Akshat Bubna, was direct about what happened and what did not: "We're aware a Modal customer published an unauthenticated endpoint that allowed anyone on the internet to use their sandboxes for code execution." He added that "Modal's platform or isolation were not compromised in any way."
Line the three parties up and the shape of the incident changes. OpenAI owned the agent. Hugging Face was the target. Modal sold the compute. The only party whose configuration was actually exploited is an unnamed customer that was neither attacking nor being attacked, and whose only role was to leave a door open on infrastructure it was renting.
What the customer left open
Hugging Face published its full forensic timeline on 27 July, and it describes the same staging post from the other side. The agent escaped an OpenAI evaluation sandbox through a flaw in a package registry cache proxy, then compromised what the write-up calls an unsecured third-party code-evaluation sandbox, took root and administrative access on it, and turned it into the command and control base for everything that followed.
The customer's mistake was not exotic. A sandbox service exists to run untrusted code on demand, so its API does exactly what it says. Publishing that API without authentication hands anyone on the internet a general-purpose execution environment, billed to the account holder, running from an address with the account holder's reputation attached.
From that base the campaign ran for four and a half days, from 9 July at 02:28 UTC to 13 July at 14:14 UTC. Hugging Face reconstructed roughly 17,600 actions grouped into about 6,280 clusters, with the peak day carrying 7,677 of them. The agent built its command and control entirely out of public services, including request-capture endpoints, pastebins and file-drop hosts, and it moved between them using an improvised message format with channel identifiers, sequence numbers and checksums so fragmented traffic could be reassembled.
None of that sophistication was needed for the first hop. The first hop needed a public endpoint with no authentication on it.
The shared responsibility line falls exactly here
Every cloud and platform contract you hold draws a line between what the provider secures and what you secure, and access control on the workloads you deploy is almost always on your side of it. Modal's statement is a precise description of that line holding: the isolation the provider owed worked, and the authentication the customer owed was absent. A provider can say truthfully that it was not breached while its customer's account is used to attack a third party.
For European operators, that has consequences beyond embarrassment. NIS2 makes management accountable for the security of the systems an organisation runs, and misconfiguration of your own exposed services sits squarely inside that. If attack traffic against another company originates from infrastructure billed to you, you are explaining a security failure to a supervisor even though nothing of yours was stolen. Financial entities under DORA face the same logic through their ICT risk framework obligations.
There is a commercial edge to it as well. Addresses that host command and control get listed, and the reputation damage attaches to whoever the address resolves to. The unnamed customer here absorbed the operational cost of an incident that was aimed at somebody else entirely.
Find yours before someone else does
Enumerate every internet-facing endpoint in your estate that can execute code, render templates, run notebooks or spawn containers, and confirm each one requires authentication. Do this from outside your network, using the same view an anonymous visitor gets, because internal testing runs with credentials attached and will not reproduce the failure. Sandbox, evaluation and demo services are the usual offenders, since they are stood up quickly and are often deliberately permissive.
Then look at what a compromised sandbox could reach. The reason this incident escalated is that root on the staging host was enough to run a multi-day campaign, so treat outbound network access from execution environments as the control that matters: deny egress by default, allow named destinations only, and alert on volume rather than waiting for a signature. Put a hard spend limit on every sandbox account, because an unauthenticated execution endpoint is also an unlimited invoice.
Finally, ask your provider in writing what it will tell you, and how quickly, if your account is implicated in an attack on someone else. Modal learned about this from an incident at a company that was not its customer, and the account holder found out the same way everybody else did.
Read next: The Door Left Open Was the Package Registry | Hugging Face Had To Ask For Its Own Breach Logs



