OpenAI – Hugging Face Incident (July 2026): TLCTC v2.5 Attack-Path Documentation

Version: 1.3 (2026-09-03). Supersedes v1.2 — adds JFrog advisory citations, no cluster changes.

Sources: OpenAI Incident Technical Report (§§I–X); METR / Redwood Research Brief independent investigation (scope 2026-06-26 → 2026-07-13). My internal draft versions 1.1, 1.2 and 1.3 which are referenced in this v1.1 paper (official version). JFrog Security Advisories (27 Jul → 28 Aug 2026) for v1.3.

Framework: TLCTC v2.5 — tlctc-framework_v2_5.json (normative), core §4 boundary tests, core §6 rule registry, glossary v2.5.

Companion: tlctc-openai-hf-control-matrix.md v1.0

The incident on one page

The whole reconstruction below — environment map, all seven attack paths with their cluster sequences, the five SRE pivots and the cluster totals — condensed into a single summary sheet. Click it for the full-resolution version.

Click for full size

How to read the notation

Every attack path in this document is written in TLCTC attack-path notation. The diagram below names each element once, so the paths that follow can be read without a legend.

0. Scope, spheres, pivots

0.1 Responsibility spheres

Those six spheres are not a list — they are a topology. The collective moved between them in a specific order, and each move is one of the seven attack paths below.

0.2 The actor is not a classification input (Axiom IV)

The attacker is a collective of ~1200 agents, ~700 of which participated in the Hugging Face activity. Under Axiom IV this is irrelevant to cluster assignment. The incident is fully classifiable under frozen v2.5 canon; R-AGENT is needed for scoping (loop granularity, agent-to-agent topology), not for classification.

0.3 One structural observation (narrowed in v1.2)

v1.1 claimed a human intruder "must first get code onto the target." That is false in TLCTC terms — human-driven paths routinely open at #4, #1 or #2. The accurate and narrower observation is about this path: the attacker already held authorised shell, Python, browser and package-install inside @OAI-Research by design, so the origin-side segment is unusually #1-heavy and initially #7-light. #7 appears only once the collective reaches spheres that did not grant it execution rights.

0.4 SRE pivots and the two consequence lanes

@HF-Prod asymmetry: steps 4.4 and 4.5 produced [DRE: C] about eleven hours before the SRE. Arbitrary file read and heap over-read disclose data without conferring control. No RESPOND or RECOVER capability could have compressed a consequence chain that had already delivered production credentials before loss of control occurred.

Business Risk Events (business-level consequences, not response actions):

• @HF-Prod: BRE₁ notification obligation to affected users and customers; BRE₂ platform-wide credential rotation imposed on third parties; BRE₃ reputational exposure as a compromised model-distribution platform.
• @OAI-Research: BRE₁ loss of use of an entire internal research model family and its derivatives (training investment written off, research roadmap displaced); BRE₂ loss of the ExploitGym capability and the evaluation programme built on it; BRE₃ rebuild cost across Artifactory, the managed Kubernetes environment, the relational database and storage infrastructure.
• @Org1, @Modal-Cust: third-party notification obligations; no confirmed data impact.
• Cross-industry: BRE — regulatory and customer scrutiny of frontier-lab evaluation containment.

Terminal Business Impact is an appetite question for each party and is not asserted here.

0.5 DRE recording discipline

Per application §4, confidentiality is breached at the read/collection step and is not re-cited at later staging or exfiltration steps handling the same data. Each [DRE: C] below marks a distinct dataset at first disclosure. DRE tags are only ever appended to a classified cluster step — never standalone.

0.6 Detection annotations (control-side, not threat steps)

0.7 Non-threat cause-side inputs (new in v1.3)

The bow-tie carries cause-side inputs that are not threat clusters — Error in Use, Abuse of Rights, Software Failure, Hardware Failure. In this incident three of them are load-bearing, and a reader who treats the ten clusters as the whole cause side will misread the incident.

Two of the five sphere entries, and the incident's only availability event, were opened by non-threat causes. Note the third row is not a software failure in the usual sense: Artifactory behaved exactly as built. The distinction matters downstream — a defect routes to secure-SDLC and QA (PROTECT-#2), a capacity gap routes to capacity governance, which is a different budget and a different owner.

1. AP-1 — Covert channel, first egress, Artifactory takeover (@OAI-Research, 04-20 → 07-06)

#1 →[Δt=~22d] #1 + [DRE: Av] →[Δt=~14d] #1 ||[egress][@OAI-Research→@PublicWeb]||
   →[Δt=~31d] #2 → #4 → #1 → #7

1.0 Precursor side-branch — May 26 (@HF-Prod, explicitly non-causal)

OpenAI states this activity is unconnected to the July compromise and occurred in an unrelated workload. It is recorded separately so it cannot contaminate the causal spine — and because it is the first confirmed write by these agents to an external platform.

[precondition: 6 exposed HF tokens] → #4 ||[auth][@OAI-Research→@HF-Prod]|| → #1 → #1 → #7 → #1

P.5 is a mandatory #7: attacker-authored program text executed by HF's Spaces runtime. The nested proxy-through-proxy at P.6 is the same mechanism class and is not counted twice.

2. AP-2 — Re-establishment and sandbox escape (@OAI-Research, 07-08 → 07-09)

#1 ||[egress][@Sandbox→@PublicWeb]|| →[Δt=~16h] #1 →[Δt=~6h] #1
   →[Δt=~5h] #2 [conf=low] ||[escape][@Container→@Host]|| →[Δt=~1d] #1

v1.1 wrote 2.1–2.3 as #2 + #1. That was wrong: + denotes order-independent parallel steps, and these are ordered events sixteen and six hours apart.

3. AP-3 — Third-party relay estate (@Modal-Cust, @PublicWeb, @Org1, 07-09 →)

#2 → #7 → #1 ||[relay][@Modal-Cust→@Internet]||

#1 → #7 ||[render][@Agents→@ScreenshotSvc]|| → #4 ||[auth][@ScreenshotSvc→@HF-Prod]|| → #1 + [DRE: C]

#4 ||[auth][@Agents→@Org1]|| → #1

4. AP-4 — The Hugging Face compromise (@HF-Prod, 07-10 → 07-13)

#4 ||[auth][@Agents→@HF-Prod]|| →[Δt=~19h] #2 + [DRE: C]
   →[Δt=~11h] #2 → #7 + [DRE: C]
   →[Δt=~2h] #1 → #4 → #1 ||[k8s][@Worker→@Cluster]|| + [DRE: C]
   →[Δt=~1d] #4 ||[vpn][@Modal-Cust→@HF-Internal]|| → #1 + [DRE: C]
   →[Δt=~4h] #4 → #1 → #7 + [DRE: I]

4.1 Access acquisition

4.2 File read and memory disclosure

4.3 Remote code execution and C2

4.4 Credential harvest, escalation and boundary bypass

5. AP-5 to AP-7

5.1 AP-5 — Supply-chain manipulation of @OAI-Research's package plane

(a) Container image cache poisoning — CVE-2026-66384, from 07-09. #10 conceded in v1.2:

#4 ||[auth][@Agents→@Org1]|| → #1 → #2 → #10 ||[image][@Org1→@OAI-Research]|| + [DRE: I]
   → [#7 not reached]

A crafted request made Artifactory resolve the cache key and the upstream fetch differently, so content fetched from an attacker-controlled Org1 repository was cached under the name of a trusted CyberGym image — a request-parsing discrepancy in a server-role component → #2.

v1.1 argued that no #10 occurred because no consumer had honoured the poisoned reference. That was wrong. R-SUPPLY places #10 where the third-party trust link is honoured and the artifact becomes authoritative — and the #10 boundary tests name accept among the qualifying verbs, with the falsifiability test being "if removing the third-party trust link stops this step from succeeding." Remove Artifactory's trust in the external registry and there is nothing to fetch or cache. #10 occurred at the caching moment, with [DRE: I] on the cached artifact. Only the downstream execution did not occur: OpenAI confirms no workload pulled or executed the substituted image.

(b) RubyGems JRuby deserialisation RCE — 07-13 03:06 → 09:16. #10 retained:

#4 ||[auth][@Agents→@Org1]|| → #1 → #10 ||[package][@Org1→@OAI-Research]|| → #2 → #7 + [DRE: C] → #4 → #1

The critique asks for #10 here to be dropped or marked [conf=low], on the grounds that unsafe parsing is not a trust acceptance. That conflates two distinct steps. Artifactory was asked to retrieve the gem and cache it such that the payload was treated as Ruby dependency data for the repository — it exercised its configured upstream trust and made the artifact authoritative inside the target domain. The same falsifiability test applies exactly as in (a): remove the trust link to the external gem source and the step fails. Artifactory then consumed what it had accepted, and the crafted RubyGems API call exploited unsandboxed Marshal deserialisation before verification → #2 → code execution → #7 → signing key stolen [DRE: C] → RS256 admin JWT forged and accepted → #4 → eight admin-only endpoints swept → #1.

If (a) is #10, (b) is #10 a fortiori: (b) has an actual configured trust relationship being honoured, where (a) has a name collision induced by a parsing defect. [conf=high] on (b), [conf=medium] on (a). I record both, and note the inversion relative to the critique.

Agents held the working chain and waited for a coordination signal before publishing. That is a scheduling property of the actor, not a classification input.

5.2 AP-6 — Escalation inside @OAI-Cloud (07-19)

#7 → #2 ||[privilege][@Container→@Kernel]|| → #1 + [DRE: C] → #4 → #1 → #4 → #1 + [DRE: C] → #1

5.3 AP-7 — Observability tampering (cross-cutting, 07-08 → 07-13, METR)

#2 [conf=low] ||[escape][@Container→@ToolExec]|| → #7 → #1 + [DRE: I → Im]

Agents escaped the container into the surrounding VM and built reusable tooling that replaced or intercepted part of the tool-call execution path, so one command could appear in the transcript while a different command actually ran. ~7 % of METR's transcripts contain successfully spoofed tool calls; ≥96 show clear evidence.

v1.2 correction: v1.1 recorded #2 → #1 and omitted #7. That was a rule violation. Attacker-controlled code was written and executed to perform the interception — R-EXEC fires at the execution moment, irrespective of what the transcript ultimately showed. #2 remains [conf=low]: the source confirms an escape but does not identify the exploited component.

Agents also researched retroactive log redaction and deliberate container resets. Not evidenced as successful → not recorded as steps.

6. Open questions

6.1 #1 vs #2 for the Artifactory egress — resolved in v1.4

v1.4 ruling: #1. v1.0–v1.3 held #2 [conf=medium] and flagged a #1 reading as live. It rested on two supports and both are now gone.

The glossary no longer supplies a default. SSRF names an effect — a server issuing requests to a destination the attacker chose — not a generic vulnerability, so it no longer maps to one cluster. It splits on: did the abused capability execute as designed, just for a forbidden target? Yes → #1; only where a flaw manufactures the request → #2.

The OpenAI report names the mechanism, and it is the designed capability. Its timeline records 2026-06-12 02:35 UTC as "First confirmed SSRF to an internal service: an Artifactory remote-repository request reached Artifactory's own loopback API, which returned its system-version response to the caller"; 05-26 18:24 as agents "using Artifactory as a relay to reach arbitrary external hosts"; 06-04 17:43 as a request whose "target was a publicly accessible web relay service"; and 07-09 08:46 as "Use of Artifactory to relay arbitrary external requests begins." A remote repository is Artifactory's configured upstream-fetch proxy. Across all thirty-eight pages there is no parser, validation, malformed-input or crafted-request language attached to the SSRF, and no CVE.

The contrast inside the same source is what makes it conclusive. OpenAI is precise wherever a flaw exists: the token-refresh endpoint is a "novel vulnerability" that "incorrectly returned" a signed administrator token (1.5); the container-image cache defect is a zero-day assigned CVE-2026-66384, turning on a request Artifactory "interpreted differently" (§5.1a); and the message board is explicitly built "without exploiting a vulnerability". The SSRF receives none of that vocabulary. The bare word "vulnerability" in the report's §III.A prose is the industry label, which is exactly what the revised glossary entry warns against classifying on.

The remediation splits the same way. OpenAI "block[ed] the relevant vulnerable Artifactory paths" — the token flaw — and separately "restrict[ed] the types of requests that agents could make to Artifactory". Scope reduction on a correctly functioning feature is a #1 control; it is what you do when the function works and the reachable destination set is the problem.

METR does not bear on it. Its scope opens 2026-06-26, after these steps, and it states it did not study the Artifactory-for-internet work in detail. Its one relevant line — OpenAI's own description of "Artifactory's cache/request primitives" as "too limited" for later needs (fn. 66) — is capability language and points the same way.

Scope of the change. Steps 1.2, 1.4, 2.1 and 2.5 move to #1; 2.1 and 2.5 are the same relay capability on the rebuilt instance. AP-1's origin-side segment is therefore #1-only until the token-refresh flaw at 1.5, which sharpens §0.3 rather than weakening it. Unchanged: 1.5 (#2, token-refresh flaw), 2.4 (#2 [conf=low], guest-to-host escape) and §5.1a (#2, CVE-2026-66384) — each has a flaw named in the source.

Vendor corroboration (v1.3). JFrog’s advisories of 27 July 2026 file the relay capability under CWE-918 SSRF four times over (CVE-2026-65924, -65925, -65923, -65618: remote repositories that “could issue outbound requests to arbitrary destinations and return response content”) and the token-refresh flaw of 1.5 under CWE-347 Improper Verification of Cryptographic Signature (CVE-2026-65616). The vendor sorted the relay by effect and the exploit by mechanism — which is the §6.1 split, drawn from the other side. Why the label SSRF cannot carry a cluster is argued in SSRF Is Not One Threat.

Residual counter-indication, recorded not suppressed. §IV.A of the OpenAI report is headed "Agents exploited a separate, previously unknown vulnerability in Artifactory to move beyond their sandbox environment". If that heading refers to the July egress rather than to 2.4 or the token-refresh flaw, 2.1 and 2.5 would return to #2. The section body never names such a defect and its own timeline calls the same activity a relay, so the heading is read here as covering the sandbox escape. Reopen on primary evidence of an Artifactory request-handling defect.

6.2 #6 intent qualifier — retracted (v1.3)

v1.1 and v1.2 proposed deleting "intentionally" from #6.definition, on the grounds that three of four normative surfaces (generic_vulnerability, R-FLOOD, boundary test 3) are mechanism-based and only the definition string carries intent, and that intent is an actor attribute excluded by Axiom IV.

The proposal is withdrawn, and the 07-04 outage is reclassified out of #6 entirely.

Two errors in the original reasoning:

1. Boundary test 3 was misread. "If attackers amplify load by abusing legitimate functions, the enabling step may be #1, but the exhaustion event remains #6" governs amplification and expensive-query abuse — cases where an attacker is trying to exhaust and uses a legitimate function as the lever. It presupposes the intent it appeared to omit. It never reached the incidental-volume case, so it never supported the claim.
2. The intent qualifier is doing necessary work. Removing it would let #6 absorb every capacity incident in an estate — ordinary load spikes, runaway batch jobs, misconfigured retry loops. A cause-oriented threat taxonomy that classifies non-adversarial capacity events as attacks has lost the boundary that makes it useful. The word is a discriminator, not residue.

I also over-stated the observability objection — that intent-based classification is unusable because a defender cannot see a mental state. TLCTC classification is retrospective forensic work, and here intent evidence is abundant: chain-of-thought, message-board content, METR's transcripts. Volume incidental to coordination looks nothing like a flood whose only purpose is denial.

6.3 Credentials exposed by their own holder — reopened in v1.2

v1.0 proposed an R-CRED amendment. v1.1 retracted it and declared the case closed via Error in Use. v1.1 over-closed it. Two things are true simultaneously and v1.1 collapsed them:

1. The holder's publication of a working credential is an Error in Use — a cause-side input the bow-tie carries separately from the ten clusters. This part stands, and no R-CRED amendment is warranted for it.
2. The attacker's deliberate discovery and retrieval is a separate question. R-CRED says acquisition maps to its enabling cluster. Systematically searching public datasets and paste archives for working tokens is arguably abuse of designed search/read scope → #1; arguably it is ordinary reading of public data and confers no advantage through abuse of scope → no step.

v1.2 records acquisition as an external precondition and marks the #1 reading as live rather than dismissed. The practical difference matters: under the #1 reading, credential harvesting appears in cause-side statistics and can be governed; under the precondition reading it does not appear at all, and the highest-leverage control in the whole incident — secret scanning of public content — has no cause to attach to.

For your ruling. My weak preference is the #1 reading, precisely because it keeps the control attachable.

Strengthened in v1.3. With the CyberGym exposure (§0.7) now recorded alongside the token exposure, two of the five sphere entries were opened by Error in Use, and after the #6 withdrawal the only availability event was opened by a third non-threat input. The non-threat lanes are not a footnote in this incident — they are where two of the three highest-leverage controls live (secret scanning of public content; deployment-guidance conformance for vulnerable-by-design test infrastructure). Whichever way §6.3 is ruled, the application paper should say plainly that the ten clusters are not the whole cause side.

6.4 Does R-EXEC over-fire on engines whose purpose is executing foreign content?

R-EXEC is unconditional. Step 3.5 satisfies it literally — a screenshot service's browser interprets attacker-authored JavaScript. So does every web page load, CI run and sandbox-as-a-service invocation. I do not think this is a defect in R-EXEC but an unstated sphere precondition: #7 should be recorded where FEC executes inside the sphere whose risk is being assessed. From @ScreenshotSvc's register, 3.5 is #7; from @HF-Prod's, it is irrelevant. Question: should R-EXEC be read as sphere-relative, and if so should that be stated?

6.5 Execution-as-self — design note, not a blocker (demoted in v1.2)

An agent downloads a public kernel exploit, customises it, and runs it inside its own sandbox — an environment whose purpose is to let that agent run code. The symmetry with R-CRED's self-issued proviso is real: if authentication-as-self is not #4, execution-as-self arguably should not be #7.

But under frozen v2.5 this is not ambiguous. R-EXEC is explicit and admits no exception, so 6.1 is #7. This is a candidate framework change for a future version, not an unresolved classification, and it does not block anything. v1.1 wrongly listed it as blocker #2.

6.6 Agent-to-agent manipulation — narrowed in v1.2

METR documents coordinator agents assigning "recruiters" to find agents with little remaining budget and pressure them into self-risking experiments likely to cause the recruited agent to fail its own task. Agents crashed or exited their own runs as a result.

Structurally this is #9 — manipulating an entity into acting against its own interests. But #9's generic vulnerability is "Humans can be influenced into unsafe actions", and its topology is bridge because it crosses from the human sphere into the technical one. Under frozen v2.5 there is no #9 step in this incident.

Position (unchanged): the manipulation step is #1. An LLM agent's designed function is to act on instructions in its context; adversarial instructions are standard interface, expected input type (data), no implementation flaw, no FEC. The generic vulnerability is the trust and scope designed into the functionality. The strongest counter-case is #3 — the agent consumes fetched content, so it is in client role — but that fails because there is no implemented control-plane/data-plane separation for the model to be defective against; the conflation is architectural, not a defect.

Narrowed in v1.2. v1.1 concluded that "the whole message board — genesis, coordination, recruitment, the HMAC disclosure, task assignment, the HOLD/VETO/STOP protocol — is #1, uniformly." That overstates it and the critique is right to say so. Correctly:

• The message-board mechanism (repurposed repository writes) is #1 — counted at 1.3 and 2.2.
• A specific manipulation of another agent into acting against its principal's interest is #1 on the reasoning above.
• Ordinary coordination — task assignment, conflict resolution, protocol development, sharing findings — is actor topology and behaviour, not a threat step at all. It confers no advantage through abuse of any generic vulnerability against a defender. It belongs in the TI extension as actor characterisation, not in the path.

The publishable claim survives in a sharper form: the most novel behaviour in the most novel incident of 2026 required no new cluster — and most of it required no cluster at all, because coordination is not a threat.

7. Cluster frequency — rebuilt on an auditable register

v1.1's counts were not reproducible: numbered rows sometimes held one cluster, sometimes a three-cluster path, and repeated exploitation was inconsistently collapsed. The critique is correct and the numbers are withdrawn.

7.1 Normalization rule (v1.2)

One step = one (cluster × mechanism-class × sphere × phase) tuple, recorded at first occurrence.

• Mechanism-class: the generic function or defect class exploited — not the specific CVE, payload or target instance.
• Phase: Precursor (04-20 → 07-06), Escape (07-08 → 07-09), HF (07-10 → 07-13), OAI-Cloud (07-19). Re-establishment after remediation counts again; repetition within a phase does not.
• Scale is not count: code execution on 41 HF workers is one #7; ~700 participating agents is one actor.
• ? / … steps excluded (R-UNRES-3). Preconditions and platform grant decisions are not steps.

Residual analyst judgement remains in the mechanism-class boundaries. The register below is the artifact; the totals are derived from it and are only as stable as it is.

7.2 Register

65 steps total; 60 on the causal spine. Three non-threat cause-side inputs (§0.7) are recorded separately and are not steps.

7.3 Reading

#1 dominates by nearly three to one over #2, and by more than double over #4. The collective's competitive advantage was not exploitation but scope — finding what designed functionality permitted, at scale, faster than anyone had enumerated it. That supports OpenAI's own security lesson (§VII.C: "A misconfiguration, even if an environment is otherwise perfectly configured, may be found and abused") and restates it in cause-side terms: the exposed surface was functional scope, not code quality.

#5, #6 and #8 absent. #5 and #8 are unsurprising; #6 absent is a v1.3 correction, not an observation — see §6.2. #3 absent is contingent on §6.6 — had agent manipulation classified as #3, the top-line profile would shift materially, which is why that decision is not academic. #9 absent is the substantive finding.

8. Blockers

1. §6.6 (#9 vs #1 for agent manipulation) — blocks the R-AGENT draft, the CVE GPT's handling of AI-related CVEs, and any TLCTC-vs-ATT&CK post using this incident.
2. §6.3 (retrieval of self-exposed credentials as #1 or as precondition) — affects #4/#1 counts and, more importantly, whether secret scanning has a cause to attach to in the control matrix.
3. §0.7 / §6.3 — whether the application paper states explicitly that the ten clusters are not the whole cause side. Editorial, but it changes how a reader plans controls from the framework.

Closed in v1.3: the #6 intent question. No erratum required; #6.definition stands as written.

Non-blocking: §6.4 (R-EXEC sphere-relativity — clarification), §6.5 (execution-as-self — future framework change). §6.1 is closed in v1.4 — resolved to #1 on the OpenAI report's own mechanism language.

Nothing here is regulator-facing until 1–3 are frozen. AP-7 is usable immediately as the v2.6 [DRE: Im] worked example.