# ML Runtime Shared-Temp Artifact Exposure

- **Severity:** Medium
- **Signature ID:** `b7f4c2d1-9a6e-4c58-8f3b-2e7d51a9c064`
- **CVEs:** CVE-2023-2800
- **OWASP:** LLM03 (Supply Chain)

## Summary

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.

## 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)

## References

- https://nvd.nist.gov/vuln/detail/CVE-2023-2800
- https://github.com/huggingface/transformers/releases/tag/v4.30.0

---
Source: https://www.netzilo.com/threats/ml-shared-temp-toctou-exposure