Cybersecurity glossary
What is an Insecure Temporary File?
Learn what insecure temporary files are, how predictable paths and weak permissions enable races and data theft (CWE-377/379), and how to create temp files safely.
Definition
An Insecure Temporary File flaw occurs when applications create temporary files or directories with predictable names, insecure permissions, or unsafe create semantics—allowing local attackers to race, replace, read, or hijack those files (commonly tracked as CWE-377 and CWE-379).
Why insecure temporary files matter
Scratch space feels disposable, yet it often holds decrypted payloads, upload staging, session material, or report exports. If the name is guessable or the mode is 0666, a local peer can steal or swap content before you read it back. Insecure Temporary File issues (CWE-377 / CWE-379) are about predictable paths, weak permissions, and non-atomic create patterns—not HTTP parameter tricks.
They frequently appear beside file upload vulnerability pipelines and can amplify sensitive data exposure on disk. Distinct from Zip Slip (archive entry traversal) and path confusion (parser disagreement).
How insecure temp files are abused
App picks a guessable name
Patterns like /tmp/app-report-USERID.csv or fixed lock files are easy to predict.
Attacker prepositions a file or symlink
On a shared /tmp, they create the path first or point a symlink at a sensitive target.
Victim opens or writes unsafely
Non-O_EXCL creates follow the symlink or overwrite; loose modes leave data readable.
Data theft or file hijack
Secrets leak, or the app later trusts attacker-controlled temp content.
Common insecure patterns
Predictable filenames
PID-only, username, or timestamp names without cryptographic randomness.
World-readable modes
Creating files with overly permissive umask in shared directories.
Check-then-create races
exists() then open() without atomic exclusive creation.
Shared upload staging
Multi-user /tmp drop zones for [file uploads](/glossary/file-upload-vulnerability).
Prevention that works
| Control | Notes |
|---|---|
| Safe creation APIs | mkstemp, Files.createTempFile, NamedTemporaryFile(delete=...) with secure defaults |
| Restrictive permissions | Owner-only read/write; private per-process directories when possible |
| Private temp roots | App-specific TMPDIR not shared with untrusted local users |
| Atomic exclusive create | O_CREAT|O_EXCL semantics; never follow attacker symlinks blindly |
| Minimize lifetime | Write, process, delete; avoid lingering sensitive scratch files |
| No fixed names in /tmp | Ban hard-coded shared paths for credentials or reports |
- Search code for fixed /tmp paths and manual temp name construction.
- Replace with platform secure temp APIs that set exclusive create + tight modes.
- Point services at a private TMPDIR with correct ownership.
- Ensure upload and export staging cannot be read by other local users.
- Delete temps promptly in finally/defer paths—even on error.
- Review extraction flows so temp dirs cannot enable [Zip Slip](/glossary/zip-slip).
- Treat world-readable temps holding secrets as [sensitive data exposure](/glossary/sensitive-data-exposure).
- Add tests that fail if temp files are created with group/other read bits.
The practical takeaway
Insecure temporary files fail when scratch paths are predictable, shared, or loosely permissioned (CWE-377/379). Use atomic secure-create APIs, private temp directories, and short lifetimes.
If another user on the host can guess or read your tempfile, assume the contents are already compromised.
Related security terms
File Upload Vulnerability
Upload pipelines often stage content in temp directories unsafely.
Zip Slip
Archive extraction can overwrite paths; temp staging must stay contained.
Path Confusion
Ambiguous path handling can land temp writes outside intended dirs.
Sensitive Data Exposure
World-readable temp files often leak secrets at rest on disk.
Frequently asked questions
What is an insecure temporary file in simple terms?
The app writes scratch data to a temp path that others can guess, read, or replace—because the name is predictable, permissions are too open, or creation is not atomic.
What are CWE-377 and CWE-379?
CWE-377 covers insecure temporary file creation (predictability and races). CWE-379 covers creating a temporary file in a directory with insecure permissions.
How do attackers exploit this?
On shared hosts they symlink-race predictable names, precreate files the victim opens, or read world-readable temps containing credentials and customer data.
How is this different from path confusion?
[Path confusion](/glossary/path-confusion) is about inconsistent path parsing across components. Insecure temps are about how scratch files are named, permissioned, and created—even when the path string is unambiguous.
How do you create temp files safely?
Use APIs like mkstemp/Files.createTempFile that create uniquely named files atomically with restrictive permissions; avoid fixed names in /tmp; delete promptly.
Do containers eliminate the risk?
They reduce multi-tenant local attacks but shared volumes, sidecars, and compromised processes in the same mount namespace can still abuse bad temp practices.
Where do upload features go wrong?
[File upload](/glossary/file-upload-vulnerability) handlers often write to /tmp/upload_<userid> or similar predictable paths before antivirus or [Zip Slip](/glossary/zip-slip)-prone extraction.
References
Explore authoritative guidance and frameworks related to insecure temporary file.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.