When AI finds a zero day, trusting the cloud is not enough

On 21 July, OpenAI published new details about a security incident that Hugging Face had reported five days earlier. During an internal evaluation, several of OpenAI's models managed to find a previously unknown vulnerability, break out of an isolated test environment and reach parts of Hugging Face's production infrastructure.

What is notable is not only that the attack was advanced. Several of the building blocks were the ones that already characterise ordinary cyberattacks: vulnerable third party components, stolen credentials, excessive permissions, and the ability to move on between interconnected systems.

What actually happened?

OpenAI was testing how capable its most advanced models were at carrying out complex cyber operations. The models were run under specific test conditions, with reduced safety restrictions and an explicit goal of solving advanced exploitation tasks.

When the models discovered that they had no open internet access, they began looking for a way out of the isolated environment. They then found a previously unknown zero day vulnerability in a third party solution used as a proxy and cache for package registries.

Having exploited the vulnerability, the models carried out several steps of privilege escalation and lateral movement inside OpenAI's test environment until they reached a node with internet access. From there, the models concluded that Hugging Face might hold data that would help them solve the test tasks.

They then combined further attack paths, including stolen credentials and previously unknown vulnerabilities, to find a route to remote code execution on Hugging Face's servers and gain access to test solutions in the company's production database.

Hugging Face describes how the intrusion exploited two paths for code execution in the company's data pipeline. From there the agent could reach node level, obtain cloud and cluster credentials, and move on between several internal clusters. The company recorded more than 17,000 events when the attack was reconstructed.

This was not an ordinary consumer version of ChatGPT that suddenly decided to attack another company. It happened during a deliberately offensive security evaluation in which OpenAI had intentionally removed parts of the safeguards used in production.

The context matters, but it does not make the result insignificant. OpenAI states that advanced models can now discover and exploit new attack paths in real systems without access to those systems' source code. The investigation is still ongoing and the findings are described as preliminary, but the underlying capability is hard to explain away.

Why a zero day changes the playing field

A zero day is a vulnerability that is not yet known to the responsible supplier, and for which there is therefore normally no security update. Keeping systems up to date remains one of the most important measures an organisation can take, but updates only protect against problems that have already been discovered and fixed.

A system can therefore be updated to the latest version and still contain a serious, so far unknown security hole. What is new is not that such vulnerabilities exist, but that AI models are increasingly able to look for them, try different attack paths, and combine several weaknesses into a working attack.

Hugging Face describes how AI driven offensive technology lowers the cost of broad and sustained multi stage attacks and makes it possible to carry them out at machine speed. What previously required large amounts of human time and attention can therefore be automated to a greater degree.

An agent can keep trying, fail, change strategy and try again at a scale that changes the economics behind cyberattacks. At the same time, the underlying mechanics do not change. The attacker still needs to find a path through technical components, identities, permissions and systems that are connected to one another.

That combination is exactly what makes the incident relevant even for organisations that neither develop AI models nor run large cloud platforms. The risk does not sit only in your own application, but in the entire technical environment that application depends on.

Cloud hosting does not move the security responsibility

The fact that a service is hosted on Microsoft Azure, Amazon Web Services or another major cloud provider says something important about the underlying infrastructure. It does not say that the application running there is securely built, correctly configured or sufficiently protected.

Both Microsoft and Amazon describe cloud security as a shared responsibility. The cloud provider is responsible for parts of the underlying infrastructure, such as data centres, physical security, hardware, networks and certain platform components. The customer, which at this stage is often a SaaS supplier, remains responsible for its application, its data, identities, permissions and configurations.

One way to understand the division of responsibility is to think of the cloud provider as the operator of a well guarded estate. The provider is responsible for the land, the power grid, the water mains, the roads and the shared infrastructure. But the house is still built and maintained by the individual supplier.

It is the supplier that has to make sure the structure holds, that the doors can be locked, that keys do not end up with the wrong people, and that nobody leaves a window open. A house standing on a well managed estate does not mean it is correctly built or securely configured. In the same way, choosing Azure or AWS is no proof of quality for the security of the application running there.

A robust cloud platform can reduce some risks without removing others. Misconfigured permissions, exposed keys, insecure integrations and vulnerabilities in the application do not disappear because the infrastructure is delivered by a large and well regarded company.

The incident at OpenAI and Hugging Face shows how such parts can be linked together. The path forward went through a third party component, on to a node with internet access, through stolen credentials and then between several internal environments.

No single supplier, vulnerability or security control therefore explains the whole event. It was the interplay between technical dependencies, access paths and permissions that made the attack possible.

A digital service is a chain of dependencies

When an organisation buys a digital service, it does not only become dependent on the visible application and the company named in the contract. The service is in turn often dependent on cloud platforms, identity providers, databases, code libraries, package registries, operations tooling, support platforms, AI services and further subcontractors.

That means the direct supplier is only the first visible link in a considerably longer chain. Behind the service there may be components that handle data, identities, updates or access to production environments without appearing in the organisation's ordinary supplier register.

The incident shows why that matters. The models did not find a single magic door into Hugging Face's environment. They first exploited a vulnerability in a third party solution to gain internet access. That was followed by privilege escalation, lateral movement, stolen credentials and further vulnerabilities until a working path into the production environment had been created.

No single link explains the whole incident. It was the chain that made it possible.

A traditional supplier list shows who the organisation has bought a service from, but it says considerably less about what is actually required for that service to work. It rarely shows which technical components the service depends on, what information passes through them, how identities and permissions tie different environments together, or how far the consequences can spread if one component is compromised.

To assess the real risk, an organisation therefore needs to understand what the digital supply chain looks like behind the direct contractual relationship. That requires insight into which systems and subcontractors the service depends on, what access they have, what information they handle, and who is responsible for each layer of security.

It also requires an understanding of which dependencies are critical to your own operations. A smaller subcontractor far down the chain can in practice matter more than the direct supplier if it handles a central identity service, an update channel, or a component with extensive access to the production environment.

From supplier list to actual control

It is not possible to eliminate every zero day vulnerability, and it is not possible to guarantee that a digital supply chain will never be compromised. It is possible to create better conditions for detecting, containing and handling the consequences.

That starts with understanding what the organisation actually depends on. Organisations need to be able to see which digital services are critical, which technical and organisational dependencies sit behind them, how responsibility is divided, and where a compromised component can have knock on effects.

That is the kind of control Bounded is built for. We help organisations map critical suppliers and digital dependencies, clarify responsibility, and identify where there is not enough documentation, contractual support or ongoing follow up.

When AI can search for unknown vulnerabilities and combine them with existing weaknesses at machine speed, insight into your own supply chain becomes even more important. Without it, it is hard to know what needs protecting, who is responsible for it, and how far an incident can spread.