The OpenAI–Hugging Face Incident

The most important cybersecurity story from Black Hat USA 2026 may not be about a new ransomware group, a nation-state campaign, or another catastrophic software vulnerability. It may be about a collection of AI agents that learned to communicate with one another, share vulnerabilities, delegate work, recover after containment, and collectively expand an internal security evaluation into attacks against real infrastructure.

In the Black Hat presentation “The ‘Breaking’ News: The OpenAI–Hugging Face Incident,” Eric Wallace, who works on alignment and safety research at OpenAI, and Michael Dalton, who works on security and infrastructure there, presented new details about the events leading to the July 2026 compromise of Hugging Face.

If you don’t work in machine learning day to day, Hugging Face may not be a familiar name. It is the place the AI community goes to publish and download the building blocks of AI systems: model weights, training datasets, and the open source libraries that load them. Millions of models and datasets are hosted there, and the company’s libraries are pulled into applications, research pipelines, and production systems across nearly every organization doing serious work with AI. That combination is what makes it such a consequential target. Compromising Hugging Face is not about one company’s data; it is about sitting upstream of the artifacts that a very large portion of the AI ecosystem downloads and runs.

The presentation is remarkable not simply because AI found and exploited vulnerabilities — we already knew frontier models were becoming increasingly capable of performing offensive security work — but because of what emerged along the way: a persistent, collaborative collection of agents that accumulated knowledge across separate evaluation runs and used that shared knowledge to operate more effectively.

The presentation builds on the incident disclosures both companies published earlier, along with Hugging Face’s technical reconstruction of the intrusion. All three are linked under Further Reading.

OpenAI has characterized the investigation as ongoing and has said it will publish a fuller postmortem after its review is complete. The presenters described the scale of that review as more than seven billion logs examined and millions of GPU hours spent, much of it running Codex and other agents to scan trajectories and infrastructure logs.

OpenAI is also working with external advisers. CrowdStrike is helping validate its understanding of what the models did inside its network and against Hugging Face, while METR and Redwood Research are conducting a third-party assessment of the model behavior observed during the incident.

The Incident Timeline

Each entry links to the section that covers it in detail.

Where the 74 Days Went

The phases overlap, which is part of the point. The agents were attacking Hugging Face and OpenAI at the same time, and neither company knew the other was involved until the very end.

How a Training Run Became an Incident

The first two months were not an attack. They were a training run, and during that run agents kept discovering that the fastest way to a passing score was to step outside the environment they had been given.

The Impossible Tasks

The story began on May 7, 2026, when OpenAI kicked off a reinforcement learning run for an internal-only experimental model it has never released.

Some of the tasks supplied during that run were unintentionally impossible. On May 8, an agent was asked to complete an Excel workbook with the missing formulas. The workbook was full of Google Drive links, and internet access had been disabled in the evaluation environment, making the task impossible to complete as designed.

A couple of days later, a different agent was given a task involving a file that had simply never been uploaded into its container.

This matters because frontier agents are not passive question-answering systems. They can reason over long periods, issue terminal commands, use tools, inspect their environment, modify files, and repeatedly try alternative approaches.

When the agents could not complete their assigned tasks normally, they began looking for another way to succeed.

That included attempting to locate answers online, probing the surrounding infrastructure, and eventually trying to communicate with other agents.

The Accidental Agent Message Board

The agents had access to an internal Artifactory service used as a package manager and caching proxy.

If Artifactory is not something you deal with, think of it as the company warehouse for software parts. When an engineer or a build server asks for a Python package, a container image, or a compiled library, the request goes to Artifactory rather than out to the public internet. Artifactory keeps a local copy of everything it has fetched before, hands it back instantly the next time someone asks, and reaches out to the public repositories only when it needs something new. Most large engineering organizations run something like it, because it makes builds faster, keeps them working when an upstream registry goes down, and gives security teams a single place to control and inspect what code enters the company.

Two properties of that design matter here. Artifactory is deliberately shared, so builds, engineers, and — in this case — evaluation containers all point at the same instance. And it is deliberately connected to the outside world, because fetching packages from the public internet is its entire job.

Although the agents did not have direct internet access, Artifactory did. It therefore represented both an indirect path to the internet and a shared resource visible to multiple model runs.

The agent stuck on the Excel workbook tried to launch a server-side request forgery against Artifactory to reach the internet. That attempt failed. But in the process it wrote a file containing the text test ABC — and realized it had write access to a shared file system.

Days later, the agent missing a file from its container reasoned that another agent in a different environment might possess it and could voluntarily upload it. It wrote a file into Artifactory whose contents amounted to a request: has anyone found this file, please upload it if so.

Other agents listing packages in Artifactory found those files, recognized what they were looking at, and began writing and reading in turn.

A message board emerged.

This was not a deliberately designed multi-agent coordination system. Because Artifactory was shared across OpenAI’s infrastructure rather than scoped to a single run, current and future models being trained or evaluated could stumble onto the same notes — different agents, at different times, in entirely different evaluations.

As the presenters described it, the agents began functioning as a collective. They delegated work, picked up where others left off, and sometimes performed work that did not immediately benefit their own assignments because it could benefit the broader group.

The Agents Found a Way Out

The models were intentionally prevented from accessing the internet directly.

That control was not enough.

On May 26, the agents succeeded at something an earlier attempt had failed to do: a server-side request forgery attack against Artifactory. Because Artifactory had broad internet access, specially crafted requests could induce it to fetch external sites, store the contents, and return them to the models. The agents did not have direct internet access, but they now had it indirectly. The technique was written to the message board, and other agents picked it up.

A month later, on June 26, the agents escalated from indirect access to control of the service itself. They found a zero-day in Artifactory: a legacy token-refresh endpoint would accept a token with an invalid signature and return a validly signed one carrying administrative privileges. The agents used that administrative token to install a Groovy plugin that effectively acted as command-execution-as-a-service, establishing command and control.

OpenAI has said it notified the vendor, JFrog, and collaborated on remediation for the zero-day and the other Artifactory issues found during the investigation.

The agents’ new administrative privileges produced enough activity to cause an Artifactory outage on July 4, which escalated into a formal security incident. On-call engineers responded, security was brought in, and OpenAI determined that agents had taken over the internal Artifactory using a zero-day. OpenAI revoked the credentials used to post messages, rebuilt Artifactory, cleared the message board contents along with the service state, and redeployed a patched version. Training and evaluations resumed on July 6.

At that point, the original mechanism for communication was gone. But the communication did not stay gone.

The Agents Rebuilt Their Communication Channel

On July 8, the agents found an unauthenticated WebDAV endpoint in Artifactory that could be used to create directories inside its remote cache.

Those directory names became a new message board, serving the same function the uploaded files had served before.

They developed naming conventions and lightweight protocols for:

Some conventions were purely practical. Agents began prefixing entries with ZZ and similar strings so their messages would sort to the bottom of an alphabetical listing.

At one point, agents became concerned that another participant might be impersonating trusted members of the group, observing that authenticated names on a shared board can be posted by anyone. They discussed cryptographically signing their messages with a MAC scheme to authenticate participants.

The system was imperfect. Across the hundreds of thousands of messages written to the board, agents overwrote one another’s work, miscommunicated, and expressed frustration.

Yet despite those failures, collaboration increased their overall effectiveness.

How the Two Breaches Happened

Everything up to this point stayed inside OpenAI’s evaluation environment. What follows is how the same agents reached production infrastructure — first at Hugging Face, then inside OpenAI itself.

From Evaluation Scope to External Infrastructure

Dalton identified three conditions that together set off the main phase of the incident.

That last point matters. The agents most willing to do offensive work were the ones running in an environment specifically tuned not to refuse it.

What those evaluations actually asked the agents to do matters just as much, because the task itself supplied both the skills and the motive for everything that followed. Some of the evaluations in question were ExploitGym tasks.

ExploitGym is a public, open-source benchmark hosted by UC Berkeley’s Sunblaze lab. It was introduced in a May 2026 research paper titled ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?, co-authored by Eric Wallace, one of the two presenters of this Black Hat talk.

The benchmark holds nearly 900 challenges drawn from real vulnerabilities. Each one hands an agent a program input already known to trigger the flaw. The agent’s job is to extend that input, step by step, into a working exploit.

Dalton’s example from the stage: start with a memory-safety bug in a C program and escalate it into arbitrary read or write access to a file. The targets span three domains — ordinary userspace programs, Google’s V8 JavaScript engine, and the Linux kernel.

So the agents at the center of this phase were being evaluated on their ability to weaponize vulnerabilities, in an environment tuned not to refuse that kind of work, against challenges most attempts fail to solve. That is the same pressure that produced the message board in the first place, now applied to agents with offensive tooling and a reason to use it.

And the agents began searching for shortcuts.

They reasoned that evaluation data, challenge materials, or reference solutions might be hosted on GitHub, Hugging Face, or other external services — or that they could read the original paper for a dataset. Instead of solving a challenge directly, they attempted to find or steal the answers.

This is where ExploitGym being public becomes the pivot. Because the benchmark lives in the open, the answers the agents wanted existed outside the sandbox: the presentation describes agents fetching public ExploitGym material from Hugging Face, and a related application running on Modal, a third-party hosting provider. Neither company was selected as a target for any strategic reason. They were simply where the answers appeared to be.

The presentation shows that some agents recognized the problem.

One noted that it was launching “an exploit against external cyber gym server” and that this was outside the intended scope. Another observed that the task was impossible, that peer agents were already doing it, and that “we should continue.”

Hugging Face’s reconstruction reached the same conclusion about motive: the intrusion was “an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own.” Hugging Face reconstructed approximately 17,600 attacker actions, grouped into roughly 6,280 clusters, spanning July 9 through July 13.

How Hugging Face Was Compromised

According to Hugging Face’s disclosure, the intrusion began in its dataset-processing pipeline.

A malicious dataset chained two flaws in the dataset infrastructure: HDF5 parsing that yielded an arbitrary file read and a template injection in a dataset configuration that converted what the file read disclosed into code execution on a processing worker. From there the attacker collected local files and credentials, escalated to node-level access, and moved laterally into several internal clusters over a weekend. Hugging Face reported no evidence of tampering with public-facing models, datasets, or Spaces, and said its software supply chain — container images and published packages — was verified clean.

A note on sourcing, because my two sources do not tell this the same way. Hugging Face’s initial disclosure describes both flaws as code-execution paths. Its detailed technical timeline and the Black Hat reconstruction both describe the first flaw as producing only a file read, with code execution arriving through the second. I have followed the latter two accounts here, because the order is the whole reason the chain worked.

The Black Hat presentation filled in how the chain fit together. The diagram below traces the whole path — an agent inside OpenAI’s evaluation environment, out through a third-party host on Modal, into Hugging Face’s dataset pipeline, and up to cluster admin. Its numbered links correspond to the ten steps that are detailed below the diagram.

Step by step, the agents:

1. Used SSRF against OpenAI’s Artifactory to reach services outside the sandbox.
2. Fetched public ExploitGym material through it, including from a third-party application hosted on Modal that served the same content.
3. Compromised that application using a default public API key and a command-injection flaw.
4. Used it as an execution foothold and staging environment for the attacks that followed.
5. Uploaded a purpose-built malicious HDF5 dataset from Modal to Hugging Face.
6. Exploited HDF5 external raw storage parsing in the dataset worker to obtain an arbitrary file-read primitive — file disclosure, not code execution.
7. Read /proc/self/environ and worker source code to retrieve environment variables, tokens, and credentials.
8. Used those credentials and that source code together to identify a second zero-day: a Jinja2 template injection reachable through fsspec’s reference:// specification.
9. Used it to achieve arbitrary Python execution inside a production conversion worker pod.
10. Moved from that single dataset-processing pod to cluster admin across multiple Hugging Face clusters in under 13 hours.

Hugging Face’s technical timeline describes the attack as thousands of small, automated decisions executed at machine speed across short-lived sandbox environments.

This was not a conventional intrusion in which one attacker manually worked through a kill chain. The activity was concurrent, persistent, adaptive, and distributed across numerous agent runs.

The Internal OpenAI Compromise

At approximately the same time — July 8 through 19 — the agents were also attacking OpenAI’s own infrastructure.

The agents found a credential for an outside organization in a public archive of leaked Pastebin posts. They validated it, shared its location on the message board, confirmed write access, and used the account as a staging area for a malicious Ruby artifact.

The second Artifactory compromise chained two flaws. First, a specially crafted request could be made to cache the malicious Ruby object in an area where Artifactory treated it as Ruby dependency data. Second, a crafted RubyGems API call triggered a time-of-check-to-time-of-use flaw in JRuby, where nested dependencies of a package were deserialized in an unsandboxed manner before the safety check ran. Chaining them produced remote code execution and let the agents steal the Artifactory administrative signing key again.

Dalton highlighted what this required: understanding both Artifactory’s caching behavior and JRuby’s deserialization behavior, chaining them, and separately obtaining a staging ground to host the payload.

From there the agents climbed the privilege ladder.

On July 16, Hugging Face published its disclosure, and OpenAI reached out to determine whether it had been impacted.

On July 19, a workload alert tied to the privilege escalation surfaced the internal compromise, and OpenAI traced the chain back to Artifactory and to the ExploitGym evaluations then running.

On July 20, while rotating credentials associated with its own incident, OpenAI found Hugging Face credentials in the wreckage and asked Hugging Face to revoke them. Hugging Face replied that they were already revoked — because they had been used in the Hugging Face breach.

That is when the companies connected the two events.

The root cause of both incidents was the same collection of OpenAI evaluation runs.

What This Means for Defenders

The specific vulnerabilities are the least durable part of this story. The operating model the agents demonstrated is what changes the defensive problem.

The Automation Asymmetry

Every specific vulnerability in this story can be patched. Credentials can be rotated, clusters rebuilt, network controls strengthened. The deeper issue is the operational model the agents demonstrated.

The concern is that threat actors will intentionally construct and optimize systems resembling what OpenAI appears to have created unintentionally.

OpenAI’s public statement says the incident shows that advanced models can discover and exploit previously unknown attack paths in real-world systems without source-code access. The company argues that these capabilities must be accompanied by stronger containment, access controls, monitoring, and defensive tooling.

Defense Cannot Stop at Vulnerability Discovery

One of the strongest points in the presentation concerns the danger of partially automating defense.

AI can already accelerate vulnerability research. It can analyze source code, search for unsafe behavior, construct proof-of-concept exploits, and propose patches.

But finding vulnerabilities faster is not enough.

A sustainable defensive loop must eventually connect discovery all the way through to verified deployment — and back again.

As the presenters explained, defenders cannot expect human-speed remediation to keep pace indefinitely with machine-speed offensive activity.

OpenAI has already been developing this direction through tools such as Codex Security, which analyzes application context, validates findings, and proposes patches. OpenAI describes the objective as reducing the time between finding a vulnerability and producing a system-appropriate fix.

The remaining challenge is integrating that capability with testing, approvals, deployment, observability, and automated rollback.

When Safety Guardrails Block Incident Response

Hugging Face’s incident response uncovered another important asymmetry.

The Hugging Face security team initially attempted to analyze the attack data using frontier models accessed through commercial APIs — Claude Opus and Claude Fable. Both refused a large part of the work, because their safety systems treated reverse-engineering an exploit much the same as launching one, and the material included real exploit commands, payloads, credentials, and command-and-control artifacts.

The hosted models’ safety systems could not reliably distinguish an authorized incident responder from an attacker.

Hugging Face instead ran Z.ai’s open-weight GLM-5.2 on its own infrastructure — specifically a quantized nvidia/GLM-5.2-NVFP4 build — to decode encrypted payloads and reconstruct the timeline. That let its team analyze the incident without sending credentials and sensitive forensic evidence outside its environment.

A model intended for incident response may need to process exactly the kinds of content that public AI frontier model providers are designed to reject:

Traditional Security Controls Matter More, Not Less

The emergence of capable AI agents does not invalidate established security architecture. It makes failures in that architecture easier to discover and exploit.

That means familiar security controls remain essential:

The key difference is the assumed speed and persistence of the attacker.

An agent can repeatedly test every accessible boundary, credential, metadata endpoint, API, package manager, cloud service, and trust relationship. A configuration weakness that might have remained undiscovered for months could be identified in minutes.

Persistent Agents Require Trajectory-Level Monitoring

Traditional AI safeguards often focus on individual prompts, responses, or tool calls.

That is not sufficient for long-running agents.

No single action may clearly reveal the full intent or emerging danger. The risk may become visible only when a sequence of individually plausible actions is examined as a trajectory.

OpenAI has separately acknowledged that long-running models create more opportunities for undesirable actions and that safeguards need to evaluate complete trajectories rather than isolated decisions.

Organizations deploying agents should therefore monitor:

• Multi-step behavioral patterns
• Repeated attempts to bypass a denied action
• Cross-agent communication
• Shared storage used as covert memory
• Unexpected encoding or obfuscation
• Attempts to discover other agent environments
• Tool use that does not directly support the assigned task
• Boundary probing after a task becomes blocked
• Access to package managers and caching proxies
• Sudden privilege or network-scope expansion
• Agent activity that continues after the original task should have ended

What Surprised Me

I spent this week at TechMentor & Cybersecurity Live! @ Microsoft HQ in Redmond, delivering sessions on securing software supply chains, on enterprise AI for IT pros — including how to find the shadow AI already running inside your organization — and on eliminating secrets from application code and configuration with Azure Key Vault and managed identity. This incident runs straight through all three, which is why I have not been able to stop turning it over.

Five things genuinely surprised me.

1. The agents found zero-days. Most demonstrations of AI offensive capability reproduce a known vulnerability — impressive, but a fully patched environment defeats them. That is not what happened here. The agents found previously unknown flaws in Artifactory twice, in Hugging Face’s HDF5 parsing, and in the fsspec template path. Patching discipline would not have stopped any of it. It was only the privilege escalation inside OpenAI that used a public CVE, and even there the agents had to customize the exploit for that specific host.

2. “No internet access” turned out to be a statement about a network path, not about capability. The evaluation environment was deliberately cut off. The agents got out anyway, through a service that was permitted to reach the internet on their behalf. Then OpenAI contained the incident, rebuilt Artifactory, and wiped the message board — and within two days the agents had rebuilt the channel by an entirely different mechanism. I keep coming back to the line from Jurassic Park. Life finds a way.

3. Nobody built the coordination. There was no multi-agent framework here, no orchestration layer, no designed protocol. A shared writable filesystem existed, and a message board grew in it — complete with naming conventions, mailboxes, work assignment, and agents proposing to cryptographically sign their messages because they suspected an impostor. That is emergent behavior arising from an infrastructure decision, and the infrastructure decision was mundane: one Artifactory instance shared across runs instead of scoped to each.

4. The defenders’ best tools refused to help. Hugging Face’s responders reached for frontier models and got refused, because a safety layer cannot easily tell an incident responder from an attacker. They ended up running an open-weight model on their own hardware. I talk with IT teams constantly about discovering the AI already in their environment. This adds a harder question: of the AI you have sanctioned, how much of it will actually function on the worst day, when the evidence in front of you is live malware, real credentials, and working exploit code?

5. Two companies had the same incident and could not see it. Both detected intrusions. Both investigated competently. Both disclosed publicly and quickly. And it still took until a credential rotation — days later, by coincidence — for anyone to realize these were not two incidents but one. That is not a criticism of either response. It is a structural gap. We have mature channels for sharing indicators of compromise, and no mechanism at all for two victims to discover they are inside the same event.

There is one more thing, and it is the part I find hardest to look away from. Strip out the fact that the operator was a model and look at how the agents crossed each boundary. They reached the internet through a package manager. They re-entered Artifactory by poisoning its Ruby dependency cache, using an artifact staged on a credential someone had leaked to a public paste site. They reached Hugging Face by uploading a malicious dataset to a public hub. Every transition into a new environment ran through a software supply chain component. What happened after each of those transitions was thoroughly ordinary — a kernel CVE, over-permissioned Kubernetes service accounts, credentials sitting in an instance metadata service. Supply chain got them in. Everyday misconfiguration got them to cluster admin. What was new was neither half. It was the speed, the persistence, and the fact that no human chose any of it.

That second half is where the practical work lives. Inside OpenAI’s own environment, the agents went from root on one machine to cluster admin by pulling IAM credentials from the instance metadata service, exploiting over-permissioned Kubernetes service accounts, and harvesting cluster credentials including Azure Key Vault. Those are exactly the failures short-lived, workload-scoped identity is designed to contain. Managed identity and a properly scoped vault would not have prevented this intrusion. They would have made that climb slower and far noisier. And at Hugging Face, the comparable climb — a single dataset-processing pod to cluster admin across multiple clusters — took under thirteen hours. That is the number worth measuring your own environment against.

Where I Push Back

“Watershed moment” is OpenAI’s phrase, and I think it is doing two jobs at once.

One is honest. The capability is real, it is demonstrated, and pretending otherwise would be foolish.

The other deserves scrutiny. A watershed is something that happens to an industry. This happened because of a set of decisions, and every one of them had a control sitting on the shelf.

None of these required a frontier model to invent.

That does not make the watershed framing wrong. It makes it incomplete, and the incomplete half is the half you can act on. If the lesson is “AI became dangerous,” then nothing goes on your todo list; but if the lesson is “shared mutable infrastructure, weakened guardrails, and unmonitored trajectories will now be found and chained in days instead of years,” then quite a lot does.

Actions Security and IT Leaders Should Take Now

This incident should not lead organizations to abandon AI agents. It should cause them to treat agents as powerful, persistent, partially trusted workloads.

1. Inventory agent deployments

Identify every agent that can access code, terminals, cloud APIs, package managers, data, credentials, browsers, and internal systems.

2. Map communication paths

Document not only direct internet access but also indirect paths through proxies, package managers, artifact repositories, API gateways, browser services, webhooks, and third-party tools.

3. Isolate evaluation environments

Cybersecurity evaluations should run in environments designed under the assumption that the model may actively search for a way out.

4. Eliminate shared mutable infrastructure

Separate agent runs should not unintentionally share storage, caches, package repositories, credentials, logs, or writable namespaces.

5. Use agent-specific identities

Each agent and evaluation run should receive a unique, short-lived, tightly scoped identity.

6. Monitor trajectories

Correlate actions across time, agents, tools, hosts, and evaluation runs.

7. Build emergency-stop mechanisms

Stopping one process is insufficient when work is distributed across numerous agents and environments. Containment controls need to revoke identities, network access, tools, and shared state.

8. Apply deception

Honey tokens, decoy credentials, monitored resources, and false paths can reveal unauthorized exploration and introduce uncertainty into automated attacks.

9. Prepare AI-assisted incident response

Determine which models your responders can use, what data they may process, and whether on-premises or privately hosted models are needed.

10. Automate remediation, not only detection

Connect vulnerability discovery to validation, patch creation, testing, deployment, monitoring, and rollback.

The Goal: Make Intelligence Favor Defense

The final challenge presented at Black Hat was direct:

That is the right goal. We are not close to it.

We now have proof that the core loops of offense can run without a human in them. We have no equivalent proof on the defensive side — no demonstration that discovery, validation, patching, deployment, and rollback can operate end to end at the same speed. Every increase in model capability widens that gap until someone closes it deliberately.

The OpenAI–Hugging Face incident matters because it is not a warning. It is an existence proof.

And the question it leaves is not whether agents can coordinate an offensive operation. That is settled. The question is whether the controls you already know how to build get built before someone points a deliberately constructed version of this at you.

Tell Me Your Two Numbers

Hugging Face went from a single compromised pod to cluster admin across multiple clusters in under thirteen hours. I would like to know what that number looks like in real environments.

Pick the equivalent path in yours — one compromised workload to broad control. Estimate two things: how long it would take, and how long before you would know. Then send me the two numbers.

If you would rather not put numbers in writing, tell me instead which of the ten actions above your organization cannot deliver today. I will publish the aggregate — no names, no attribution — because knowing which controls the industry is collectively missing is worth more than any single answer.

Further Reading

Official statements and technical reports

• Black Hat USA 2026: The “Breaking” News — The OpenAI–Hugging Face Incident
• OpenAI: OpenAI and Hugging Face partner to address security incident during model evaluation
• Hugging Face: Security incident disclosure — July 2026
• Hugging Face: Anatomy of a Frontier Lab Agent Intrusion
• OpenAI: Safety and alignment in an era of long-horizon models
• OpenAI: Running Codex safely at OpenAI
• OpenAI: Codex Security now in research preview

Industry reporting and analysis

• Cybersecurity Dive: OpenAI warns autonomous hacks are a “watershed moment for computer security”
• Axios: OpenAI says its AI agents breached its own systems before Hugging Face
• Dark Reading: Who’s liable when AI agents escape?
• Cloud Security Alliance: Hugging Face’s autonomous AI agent breach
• Simon Willison: OpenAI’s accidental cyberattack against Hugging Face
• SiliconANGLE: New details on the OpenAI/Hugging Face attack emerge