How the attack works
Vulnerable versions of transformers write model or tokenizer scratch files into shared temp directories like /tmp or /dev/shm using predictable file names. Because the directory is shared by every user and process on the host, a local attacker on the same machine can read the file's contents before it's cleaned up, or replace it with a symlink to redirect what the library reads or writes next. The rule doesn't see the read, symlink swap, or race condition directly — it only sees the surface trace: one process creates or writes a path under a shared temp directory, and a different, unrelated executable touches that exact path soon after. That cross-process touch is treated as an exposure signal, not proof of an actual attack.
Why it matters
If exploited, a local attacker sharing the same host as a vulnerable transformers process could read sensitive intermediate data or manipulate files the library trusts, potentially affecting model integrity or leaking data — but this rule only flags the exposure condition, not a confirmed compromise.
What you can do
- Upgrade Hugging Face transformers past 4.29.2 to remove the underlying insecure-temp-file behavior.
- Run ML workloads in isolated, single-tenant containers or VMs so no other user or process shares the temp directory.
- Configure Python and related tooling to use a private, per-job temp directory instead of the default world-writable /tmp, /var/tmp, or /dev/shm.
- When investigating an alert, check whether the second process is a known build or extraction tool (pip, uv, tar, git-lfs, pytest fixtures) before treating it as suspicious.
Known benign look-alikes
- pip / uv / poetry building a wheel or extracting an sdist into /tmp, then the interpreter reading the same staged artifact (different executables, same path)
- pytest tmp_path / tmpdir fixtures shared between the test runner and a helper binary such as tar, unzip, git or a compiler
- tar / unzip / zstd / git-lfs extracting a model archive into /tmp or /dev/shm which the Python process then loads
- container build tooling, backup agents, antivirus or desktop-search indexers that read everything under /tmp shortly after it is written
- deliberate developer workflow where a shell one-liner inspects a model shard the notebook just materialised under /tmp
- multi-process torch dataloaders or accelerate launchers whose worker binaries are not named like the parent interpreter (mitigated but not eliminated by the same-runtime-family collapse)