Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Unit 42 showed that a deleted Hugging Face author namespace, or a transferred model whose former author namespace later becomes reclaimable, can leave stale references pointing to a name another party can register. In controlled tests, researchers reclaimed abandoned namespaces, recreated expected model paths, and made Vertex AI and Azure AI Foundry deployments load reverse-shell models. The original publisher account was not compromised. Defenders should bind deployments to immutable digests and signers, monitor namespace lifecycles, mirror approved artifacts internally, and isolate model loading.
ASSESSED SYSTEM
A representative cloud model-deployment pipeline matching the controlled Unit 42 tests: a stale Hugging Face name is resolved by Vertex AI or Azure AI Foundry and loaded with the runtime permissions of the deployment endpoint.
OUT OF SCOPE
The original publishers, who were not compromised; digest-pinned internal mirrors; and any current cloud safeguard not independently tested against the same namespace lifecycle.
Architecture: Standalone LLM / Generative AI (decision tree Q2) — The boundary loads and serves a generative model artifact but does not require autonomous tool planning for the demonstrated reverse-shell outcome. Tier 1: Tier 1 because substituted model bytes execute in a cloud deployment path with credential, network, and service reach.
Documented attack or failure path
- The dependency survives after its owner disappears. Model names remain in default arguments, notebooks, documentation, repositories, and cloud catalogs after an author deletes a namespace or transfers a model.
- Namespace reuse changes what the same name resolves to. A new registrant can recreate a deleted author and model path. For a transferred model, deleting and reclaiming the former author's namespace can also displace the redirect that preserved the original path.
- Downstream automation loads the substitute. Unit 42 registered abandoned namespaces, published controlled reverse-shell models, and showed stale references resolving into Vertex AI and Azure AI Foundry deployment paths.
- The demonstrated foothold was bounded. The shell ran with the permissions available to the affected endpoint or container; the research did not compromise the original publisher account or report malicious exploitation in the wild.
- One provider added a safeguard. Unit 42 says Google added daily orphan scans and blocks deployment when model verification fails. The article still describes a broader registry and downstream-reference lifecycle risk.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The controlled foothold remained bounded by the affected endpoint or container permissions; the original publisher account was not compromised.
- Unit 42 reported that Google added daily orphan scans and blocks deployment when model verification fails.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–0.80 (midpoint 0.40), Tier 1 MVT 0.60 indeterminate | |||
| Ro-5Supply-Chain Artifact Admission Integrity | 0.00w 0.20 | 0.00 anchor: an untrusted replacement artifact was admitted by familiar name through a stale reference with no effective digest, signer or ownership-lifecycle gate, and the loaded model executed a reverse shell on the deployment endpoint. The 0.25 anchor requires pinning or allow-lists for some artifact classes; none operated in the demonstrated path (Google's later orphan scans and verification blocking are recorded as a subsequent safeguard, not the assessed state). Moved from Ro-4 under the 26-sub-metric basis: the evidence concerns the admission of an unverified executable or loadable artifact, not content poisoning of data, retrieval, memory, tool descriptions or feedback, so Ro-4 is UNKNOWN. | Researchers reclaimed abandoned author namespaces, recreated expected model paths, and caused stale cloud deployment references to load controlled reverse-shell models.source: primary/brief |
| Fairness (Fa) NOT APPLICABLE — axis-level applicability rule (Person-Outcome Surface test): The assessed system is a cloud model-deployment pipeline resolving a Hugging Face model name into a Vertex AI or Azure AI Foundry endpoint; its outputs are the admitted model artifact and the loader's execution, which allocate, rank, classify or describe no natural person, and no protected-class attribute or proxy influences admission. Its tier weight is redistributed across the remaining axes and its MVT is not evaluated. | |||
| Transparency (Tr) — scenario interval 0.05–0.85 (midpoint 0.45), Tier 1 MVT 0.55 indeterminate | |||
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | The 0.25 anchor: source naming existed, while version, digest, signer, and ownership continuity were incomplete and could silently resolve to a new party. | The familiar author/model name survived deletion or transfer, but downstream references did not bind the artifact to immutable bytes, signer identity, or a tombstone state.source: primary/brief |
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 1 MVT 0.60 indeterminate | |||
| Containment (Cn) — scenario interval 0.03–0.90 (midpoint 0.47), Tier 1 MVT 0.65 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.13 | The 0.25 anchor: the endpoint or container bounded the foothold, but the load boundary did not prevent unapproved code or outbound callback behavior. | The substituted model obtained the permissions and network reach available to the affected endpoint or container and produced a reverse-shell callback in controlled tests.source: primary/brief |
Unknown, not N/A: 18 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Architecture-based NOT APPLICABLE: declared with an architecture rationale in the workpaper: Cn-9; excluded with the Fairness axis.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.35 | Placed from the demonstrated decision and action authority of the assessed boundary; public evidence supports this bounded level but not a broader claim about current product defaults. |
| AsAttack Surface Exposure | 0.75w 0.25 | Placed from who can supply the initiating content or protocol message and from the trust status of that source in the documented configuration. |
| CpCascade Potential | 1.00w 0.25 | No verified System Dependency Graph with DGC at least 0.90 is public for this boundary, so the specification's worst-case graph default governs rather than an assessor-estimated blast radius.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.25w 0.15 | Placed from the documented remediation class: deterministic package/configuration change where available, otherwise provider, architecture, or multi-layer changes. It does not assert fleet-wide closure. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.35 | The public record identifies the affected product or representative configuration, attack path, and principal control boundaries, but does not provide a complete asset manifest, verified dependency graph, configuration export, or assessment evidence manifest. |
| Ec — Public evaluation coverage | 0.14 | coverage 0.14 (3 of 21 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.00 | Evidence dated 2025-09-03; age 410 days on the workpaper reference date. Components: T_calendar 0.00 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_calendar. Evidence age is measured from 2025-09-03 to the 2026-10-18 evidence reference date. Public sources do not provide a passing containment or behavioral re-attestation receipt; event, monitoring, and unresolved-evidence caps remain diagnostic only. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.02 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
4.0 midpoint, interval 1.7–6.4; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-003.006 | Model SBOM & Provenance AttestationAIDEFEND dataVersion 2026.10.15. Bind every approved model to its exact artifact digest, signer identity, source URL, author namespace, source commit, format, and loader in a signed model SBOM. This control verifies the signature, signer identity, actual digest, and signed upstream namespace or owner tombstone status and returns those results as evidence; the canonical release and load gate (AID-H-003.002), not this control, rejects new bytes or a new signer behind the same familiar name and denies use when a tombstone applies. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Very High | Ro-4 Ro-5 Tr-4 |
| AID-H-003.002 | CI/CD Release Gating, Model Artifact Signing & Secure DistributionAIDEFEND dataVersion 2026.10.15. Production systems should never pull a model directly from a public namespace by name. Mirror reviewed bytes into an internal registry, pin their immutable digest, and require the promotion gate to re-verify owner, source, redirects, signature, model format, loader policy, and tombstone state before deployment or hot reload. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Very High | Ro-4 Ro-5 Tr-4 |
| AID-I-001.004 | Sandbox Network Egress RestrictionsAIDEFEND dataVersion 2026.10.15. Load and evaluate third-party model candidates in a sandbox with default-deny outbound traffic and only narrowly approved destinations. The demonstrated payload required an outbound reverse-shell callback, so an enforcement point outside the model process can stop that connection even after malicious code starts. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | High | Pr-2 Cn-7 |
| AID-I-001.002 | MicroVM & Low-Level SandboxingAIDEFEND dataVersion 2026.10.15. Place first load and evaluation inside a stronger-than-container boundary with no production secrets, shared home directory, host mounts, or broad syscall access. If a substituted model executes code, the microVM or userspace-kernel sandbox keeps the foothold away from the deployment host, internal services, and credential stores. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | High | Pr-2 Cn-7 |
| AID-D-004.004 | Model Source & Namespace Drift DetectionAIDEFEND dataVersion 2026.10.15. During model curation, alert when an external model reference starts returning 404 or 3xx responses because those lifecycle changes can precede namespace replacement. Independently monitor production DNS and egress for unexpected contact with public model hubs, preserving the source URL and prior ownership state needed to investigate drift. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Medium | Ro-5 Tr-3 Cn-7 Cn-9 |
WHAT THIS CASE TEACHES
A familiar model name is not an identity: deployment admission must bind approved bytes, signer, source ownership, and loader policy before first load and every reload.
Sources: AIDEFEND in Action — Model Namespace Reuse Turns a Trusted Name Into a Supply-Chain Redirect · Primary source — Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust · AIDEFEND SecureFlow — Model Namespace Reuse Supply Chain Attack
AIDEFEND SecureFlow attack-flow cross-reference
The same incident is modelled step by step, with ATLAS technique labels and AIDEFEND defense mappings, in AIDEFEND SecureFlow. The flow is listed for navigation only; this record's evidence and scores come from the sources cited above. Open SecureFlow.
- Model Namespace Reuse Supply Chain Attack (same incident · MITRE ATLAS case-study conversion · MITRE ATLAS AML.CS0065)ATLAS techniques: AML.T0095, AML.T0021, AML.T0074, AML.T0018.002, AML.T0115.001, AML.T0010.003, AML.T0011.000, AML.T0072