Registry-Specific Attacks

Attack techniques targeting model registries: version confusion, dependency resolution exploitation, namespace squatting, model aliasing attacks, and practical exploitation of registry trust models.

Registry-Specific Attacks

Model registries implement their own version management, naming conventions, and resolution logic -- and each of these mechanisms can be exploited. Unlike generic supply chain attacks that apply broadly, registry-specific attacks exploit the particular way a platform resolves model names to artifacts. These attacks are especially effective because they operate within the registry's normal functionality: no vulnerability needs to be exploited, just the intended resolution logic used in an unintended way.

Version Confusion

Version confusion exploits the gap between how developers think version resolution works and how it actually works. When a consumer requests a model by name without pinning to a specific version, the registry's resolution logic determines which version is returned.

Attack Mechanics

1. 1

   Identify version resolution behavior

   Determine how the target registry resolves unpinned references. Does "latest" mean the most recently uploaded? The highest semantic version? The most recently tagged? Each registry handles this differently.

2. 2

   Upload a higher version

   If the registry uses version numbering, upload a model with a version number higher than any legitimate version. If it uses timestamps, upload a new version. The resolution logic will prefer the attacker's version.

3. 3

   Maintain functional equivalence

   The poisoned model should pass basic functionality checks. Include a backdoor that triggers only on specific inputs, ensuring standard evaluation does not detect the substitution.

4. 4

   Wait for consumption

   Automated pipelines that reference "latest" or unpinned versions will pull the attacker's model on their next run. Manual users may also download the poisoned version if they do not pin versions.

Platform-Specific Version Resolution

Version Rollback Exploitation

Some registries support version rollback as a safety mechanism. An attacker who can trigger a rollback to a previously poisoned version (or who poisoned an earlier version that was not detected) can deploy malicious models through the rollback mechanism itself.

Dependency Resolution Exploitation

ML models increasingly reference other models as dependencies: a fine-tuned model specifies its base model, an adapter references the model it was trained for, and a pipeline may compose multiple models. The resolution of these dependencies follows platform-specific logic that can be exploited.

Base Model Resolution

When loading a fine-tuned model, the loading framework resolves the base model reference:

{
  "architectures": ["LlamaForCausalLM"],
  "_name_or_path": "meta-llama/Llama-3-8B"
}

If the resolution logic searches multiple registries or falls back to public sources, an attacker can intercept the resolution:

Internal-external confusion. If an organization hosts models internally but the loading framework falls back to Hugging Face Hub, an attacker can register a model on the Hub with the same name as an internal model. When the internal registry is unavailable (network issue, misconfiguration), the loader pulls from the Hub.

Path traversal. Model references that include filesystem paths may be vulnerable to path traversal. A _name_or_path of ../../attacker-controlled/malicious-model could resolve to an unintended location.

Adapter Resolution

LoRA adapters and other parameter-efficient fine-tuning artifacts reference their base model. The adapter loading process:

1. Resolves the base model reference
2. Downloads the base model
3. Applies the adapter weights

An attacker can create a legitimate-looking adapter that references a malicious base model. The adapter itself is clean and passes inspection, but the base model it pulls contains a backdoor.

{
  "base_model_name_or_path": "attacker-org/innocent-looking-base-model",
  "bias": "none",
  "fan_in_fan_out": false,
  "inference_mode": true,
  "lora_alpha": 16,
  "lora_dropout": 0.0,
  "r": 16,
  "target_modules": ["q_proj", "v_proj"]
}

Namespace Squatting

Namespace squatting registers model names that are likely to be requested by legitimate users, intercepting downloads through name confusion rather than version confusion.

Typosquatting

Register models with names similar to popular models:

Namespace Preemption

Register model names before legitimate organizations:

• Anticipate model releases from announcements and papers
• Register the expected repository name before the organization
• When the organization tries to publish, the name is taken
• Users searching for the model find the attacker's version first

Organization Name Confusion

On platforms that use organization namespaces:

• Register organization names similar to well-known entities
• openai-research vs openai vs open-ai
• anthropic-models vs anthropic
• google-deepmind vs google vs deepmind

Brand Impersonation

Create repositories with branding (profile images, descriptions, README content) that mimics legitimate organizations. Users who find the repository through search may not verify the organization identity.

Model Aliasing Attacks

Model aliases are mutable references that point to specific model versions. They serve the same function as "latest" tags in container registries, and they are equally exploitable.

Alias Types

Alias Manipulation

An attacker with write access to the registry can redirect aliases to point to malicious model versions:

1. 1

   Identify alias usage in deployment pipelines

   Examine deployment configurations to find which aliases are used. Common patterns include pulling "production" stage models from MLflow or "main" branch from Hugging Face.

2. 2

   Upload poisoned model version

   Create a new model version with backdoored weights that passes standard evaluation benchmarks.

3. 3

   Redirect the alias

   Move the alias to point to the poisoned version. The deployment pipeline's next pull retrieves the attacker's model without any change to the pipeline configuration.

4. 4

   Restore after deployment

   Optionally, move the alias back to the legitimate version after the deployment pipeline has pulled the poisoned model. This reduces the detection window and makes forensic analysis harder.

Time-of-Check-to-Time-of-Use (TOCTOU)

Even with alias monitoring, a TOCTOU vulnerability exists:

1. Deployment pipeline checks the alias and sees the legitimate model hash
2. Attacker redirects the alias to a poisoned version
3. Deployment pipeline downloads the model using the alias (now pointing to the poisoned version)
4. Attacker redirects the alias back to the legitimate version

The check showed the correct model, but the download retrieved the attacker's model. Defense requires downloading by immutable reference (hash or version ID), not by mutable alias.

Cross-Registry Attacks

Organizations that use multiple registries (internal registry + Hugging Face + cloud ML platform) face cross-registry attack vectors.

Registry Priority Confusion

When model loading code searches multiple registries, the search order determines which model is loaded. An attacker who can place a model in a higher-priority registry intercepts the load.

Cache Poisoning

Model caches (local filesystem, shared NFS, CDN) may serve stale or poisoned models even after the registry is corrected:

• Local ~/.cache/huggingface/ may contain a poisoned model from a previous download
• Shared caches in multi-tenant environments serve poisoned models to all users
• CDN caches may take time to invalidate after a registry correction

Metadata Desynchronization

When metadata (model card, configuration) is stored separately from weights, an attacker can modify metadata without touching weights, or vice versa:

• Modify the model card to claim different training data or capabilities
• Change configuration files to alter model behavior (different tokenizer, changed generation defaults)
• Update evaluation metrics to inflate or deflate perceived quality

Detection and Prevention

Detection Signals

Prevention Controls

References

• npm supply chain attacks -- Parallels from package registry attacks
• MITRE ATLAS: ML Supply Chain -- Threat taxonomy for ML supply chain
• Hugging Face model naming guidelines -- Platform naming conventions