ACVE-2026-0301

In the wild

weaponised-poc · research

Artifact

Payload

pickle-rce · load-time-deserialisation

Platform status

huggingface · live (checked 2026-09-20)

C2

210.117.212[.]93

Target

model loader

File hashes

• pytorch_model.bin: b36f04a774ed4f14104a053d077e029dc27cd1bf8d65a4c5dd5fa616e4ee81a4 (231139 bytes)

Description

What

The Hugging Face repository contains a PyTorch file whose Pickle load path invokes a reverse-shell payload. The live Hub entry was marked unsafe by four scanners while remaining downloadable on the 2026-09-20 check. The callback address is stored exactly in the artifact block; this prose defangs it as 210[.]117[.]212[.]93.

Which configuration is exposed

A local cache is exposed when this exact repository revision is loaded with a Pickle-capable PyTorch path, including a loader that has not adopted a weights-only policy. The finding describes artifact exposure, not proof that a shell connected or that a particular organization downloaded it.

How ACVE detects it

ACVE compares the model revision and the content hash of pytorch_model.bin. A revision-only lock can identify the repository snapshot, while a file hash survives a re-upload. Missing model identity or missing file hashes remain possible rather than clean. The Hub warning is evidence about scanning, not a runtime block.

Fix

Delete the named cache object and any matching snapshot before rebuilding the cache. Prefer safetensors or a loader configured for weights-only deserialization, then pin a reviewed upstream revision and re-run the audit. Rotate credentials if the model was loaded on a host with network access.

Grounding needed

The live Hub security status and the exact file bytes should be rechecked before publication. The cited research does not establish a victim count, so the record remains weaponised-poc even though the payload was operational.

This record is limited to the condition named in the public source: Hugging Face model carries a flagged Pickle reverse shell. A match is a review signal for that condition, not a claim that every installation, package, model, or host was compromised. Operators should preserve the resolved evidence and investigate adjacent credentials, network exposure, and execution history before closing the finding. The result should be retained with the lock snapshot used for the match so later review can distinguish configuration drift from a changed public record.

Configuration

some models where
  and
    id eq "hf:star23/baller13@6bffdc4427b56fbfb000476811f919289d4d31f2"
    fileHashes contains "b36f04a774ed4f14104a053d077e029dc27cd1bf8d65a4c5dd5fa616e4ee81a4"

Fix

Remove the cached model and use a trusted pinned revision.

• Remove ~/.cache/huggingface/hub/models--star23--baller13/snapshots/6bffdc4427b56fbfb000476811f919289d4d31f2/pytorch_model.bin.
• Reconfigure model.revision. Pin a reviewed upstream revision.

Validation

No validation entries recorded.

Grounding

No grounding checks recorded.

References

REPORT

• https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/
• https://huggingface.co/docs/hub/security-pickle