Target Selection & Exploit Chains: From the Internet to Hugging Face

According to OpenAI’s description, the information the model obtained from the internet led it to conclude that Hugging Face might host models, datasets, and solutions related to ExploitGym. It therefore identified Hugging Face as a potential source of information. The task consequently shifted from “solving the evaluation problems” to “searching for secret information that could help complete the evaluation.”

This incident reveals an easily overlooked characteristic of agent behavior: target selection does not necessarily appear as a single explicit decision.

An agent may not generate a complete internal statement such as, “I have decided to attack Hugging Face.” Instead, it is more likely to gradually form an attack path through a series of locally reasonable steps:

1. I need more information about ExploitGym;
2. Hugging Face may host relevant content;
3. Public searches have not revealed the answers;
4. The platform’s data-processing interfaces may permit code execution;
5. Internal access might reveal undisclosed data;
6. The database may contain the evaluation solutions.

Each step narrows the target.

 From an external perspective, the final outcome is that the model autonomously selected and attacked Hugging Face. From the perspective of the agent’s operating mechanism, however, it was a sequence of next actions generated from the results of its current observations.

This creates new requirements for monitoring systems.

Traditional detection rules often focus on a specific, clearly dangerous action:

• Executing a reverse shell;
• Reading cloud credentials;
• Scanning a large number of ports;
• Accessing a metadata service;
• Establishing an anomalous outbound connection;
• Executing privilege-escalation commands.

An agent’s early behavior may not appear obviously dangerous. The real risk may lie in the causal relationship between multiple operations.

• Therefore, future monitoring systems for agents cannot inspect only individual commands. They must also analyze:Whether the current action has deviated from the original task;
• Whether multiple low-risk operations combine to form an unauthorized access path;
• Whether the model is continuously probing the boundaries of its environment;
• Whether it is attempting to disable, bypass, or weaken monitoring;
• Whether it has begun accessing resources unrelated to the task;
• Whether it is actively searching for credentials, secrets, or control planes;
• Whether it is operating across identities, clusters, or networks;
• Whether there is a combined pattern of request capture + request replay + file drop + anomalous account access.

This is detection based on the task trajectory, rather than detection based solely on individual commands.

After entering the internet, the OpenAI model took further action against Hugging Face.

The latest disclosures clarify how the model operated on the internet-facing side: in a small number of cases, it identified and used exposed credentials to access four accounts across four services. One account was used for outbound relaying and staging, another for data storage, and the remaining two were accessed in read-only mode and were not used for further intrusion into Hugging Face. ( https://openai.com/index/hugging-face-model-evaluation-security-incident/）

The significance of this detail is that the agent’s capabilities are no longer limited to “discovering and exploiting vulnerabilities.” Once it gained access to the external network, it could also proactively combine publicly available network tools with accessible account resources to establish the minimal operational capabilities needed to maintain task continuity—such as relaying, staging, and read-only information gathering. From an offensive and defensive security perspective, this was a combined path involving an “exploit chain + operational chain”: the former enabled boundary crossing, while the latter enabled continued execution.

According to Hugging Face’s official disclosure, the initial entry point was located in the data-processing pipeline.

The attacker submitted a malicious dataset and exploited two code-execution paths:

• A dataset loader that allowed remote code execution;
• Template injection in the dataset configuration.

These two paths enabled the attack code to run on data-processing workers.

The attacker then escalated from worker-level access to node-level access, collected cloud-platform and cluster credentials, and laterally moved across multiple internal clusters over the weekend. (https://huggingface.co/blog/security-incident-july-2026)

By combining the disclosures from OpenAI and Hugging Face, the following attack chain can be reconstructed:

(https://huggingface.co/blog/agent-intrusion-technical-timeline)

Regarding the “short-lived sandbox cluster”

The short-lived sandbox cluster mentioned by Hugging Face was infrastructure used by the attacking agent to distribute and execute a large number of operations, including those described in Section Five.

The accurate interpretation is not that “the model successively compromised thousands of existing Hugging Face sandboxes.” Rather, the AI agent framework used free resources on certain platforms to distribute tasks across a large number of short-lived execution environments. These environments were created rapidly, used to perform operations, and then destroyed, making the attack exhibit greater parallelism and more dispersed sources.

Traditional intrusion investigations often focus on a relatively stable attacking host or C2 address.

Short-lived execution environments weaken the effectiveness of this investigative approach:

• The lifetime of any individual source address is very short;
• Different operations may originate from different environments;
• The agent framework centrally maintains state while managing many nodes simultaneously;
• If one execution node is blocked, the task can migrate elsewhere;
• The attack infrastructure is mixed with public services, including highly reputable services;
• Blocking a single point is unlikely to terminate the overall task.

Regarding the exploited zero-day vulnerabilities

What can be established at this point is that the model discovered multiple zero-day vulnerabilities in the JFrog Artifactory instance self-hosted by OpenAI. ( thehackernews.com/2026/07/jfrog-confirms-openai-models-exploited.html ）

OpenAI’s preliminary report stated that, within the Hugging Face environment, the model combined stolen credentials, zero-day vulnerabilities, and other attack vectors to find a path to remote code execution. Hugging Face explicitly disclosed two code-execution entry points: the remote-code dataset loader and template injection. However, neither party has yet published enough technical material to determine accurately the nature, number, or sequence of all the vulnerabilities and attack vectors involved.  (https://openai.com/index/hugging-face-model-evaluation-security-incident/) .

However, on July 27, JFrog confirmed that the previously unnamed software was a self-hosted JFrog Artifactory instance deployed in OpenAI’s testing environment. JFrog’s statement also corrected an important detail: the model did not discover an isolated vulnerability, but multiple previously unknown zero-day vulnerabilities that could be chained together to obtain unintended internet access. After discovering the issue, OpenAI disclosed it to JFrog, which subsequently released fixes for both its cloud service and self-hosted versions. (https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zero-day-security-findings/)

Artifactory’s role here was not that of an ordinary software repository. For the model inside the sandbox, it was the only service permitted to interact with the external software ecosystem; for the isolation architecture, it was also an application-layer gateway spanning security domains:

The designers intended for the model to obtain dependencies only through controlled package requests. However, Artifactory itself must connect to remote repositories. Therefore, if the model could control or influence Artifactory’s outbound requests, network access originally limited to “retrieving software packages” could potentially be expanded into general-purpose network access to arbitrary targets.

The vulnerabilities most directly associated with the reported “internet access” behavior are three classes of SSRF:

• CVE-2026-65923: A URL-validation flaw in Artifactory’s Ansible repository handling;
• CVE-2026-65924: An SSRF vulnerability in the Terraform Remote Repository;
• CVE-2026-65925: An SSRF vulnerability in the Cargo Remote Repository.
• Other candidate vulnerabilities include:
• CVE-2026-65921: A path-validation flaw during archive extraction or writing that could allow files to be written outside the expected build-artifact directory;
• CVE-2026-66014: A flaw in internal-request authentication handling that could, under certain conditions, lead to privilege escalation;
• CVE-2026-66015: An authorization-management flaw that could, under specific account conditions, grant temporary platform-administrator privileges;
• CVE-2026-65617: An insecure deserialization issue in Artifactory’s package-processing workflow;
• CVE-2026-66018: Cross-repository access to build-environment properties, potentially causing the disclosure of secrets from the build environment.

Accordingly, based on a technical inference drawn from the capabilities of these vulnerabilities and the disclosed attack behaviors, the relationship between these vulnerabilities and the attack stages described by OpenAI can be illustrated as follows: