ML Runtime Shared-Temp Artifact Exposure
This rule watches for a specific file-sharing pattern: a Python process writes a scratch file into a world-readable temp folder, and a different program touches that same file shortly after. That pattern is how an old bug in the Hugging Face transformers library (CVE-2023-2800 class, versions up to 4.29.2) could be exploited by another user on the same machine.
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.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- b7f4c2d1-9a6e-4c58-8f3b-2e7d51a9c064
- Severity
- Medium
- CVEs
- CVE-2023-2800
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)