Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
CWE-379 Base Incomplete
Creation of Temporary File in Directory with Insecure Permissions
This vulnerability occurs when an application creates a temporary file in a directory that is too permissive, allowing unauthorized users or processes to see, access, or manipulate the file.
Definition
What is CWE-379?
This vulnerability occurs when an application creates a temporary file in a directory that is too permissive, allowing unauthorized users or processes to see, access, or manipulate the file.
When a temporary file is placed in a directory with loose permissions (like world-readable or world-writable), other users or system actors can detect its presence. This simple act of discovery reveals which application created the file, offering a window into what the user is currently doing. Attackers can correlate this information with running processes to infer sensitive user activity, turning a seemingly minor information leak into a serious privacy breach.
This issue is more than just a file access problem; it's an information exposure flaw that can enable targeted attacks. By knowing which application is in use, an attacker gains critical context to craft further exploits, potentially escalating privileges or accessing confidential data. Developers must ensure temporary files are created in secure, private locations with strict access controls to prevent this form of reconnaissance.
Real-world impact
Real-world CVEs caused by CWE-379
-
A hotkey daemon written in Rust creates a domain socket file underneath /tmp, which is accessible by any user.
-
A Java-based application for a rapid-development framework uses File.createTempFile() to create a random temporary file with insecure default permissions.
How attackers exploit it
Step-by-step attacker path
- 1
In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system.
- 2
However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.
- 3
Similarly, the createTempFile() method used in the Java code creates a temp file that may be readable and writable to all users.
- 4
Additionally both methods used above place the file into a default directory. On UNIX systems the default directory is usually "/tmp" or "/var/tmp" and on Windows systems the default directory is usually "C:\\Windows\\Temp", which may be easily accessible to attackers, possibly enabling them to read and modify the contents of the temp file.
Vulnerable code example
Vulnerable C
In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system.
FILE *stream;
if( (stream = tmpfile()) == NULL ) {
perror("Could not open new temporary file\n");
return (-1);
}
```
// write data to tmp file*
...
// remove tmp file
rmtmp(); Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-379
- Requirements Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.
- Implementation Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories.
- Implementation Avoid using vulnerable temp file functions.
Detection signals
How to detect CWE-379
CWE-379
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-379?
How serious is CWE-379?
What languages or platforms are affected by CWE-379?
How can I prevent CWE-379?
How does Plexicus detect and fix CWE-379?
Where can I learn more about CWE-379?
Frequently asked questions
What is CWE-379?
This vulnerability occurs when an application creates a temporary file in a directory that is too permissive, allowing unauthorized users or processes to see, access, or manipulate the file.
How serious is CWE-379?
MITRE rates the likelihood of exploit as Low — exploitation is uncommon, but the weakness should still be fixed when discovered.
What languages or platforms are affected by CWE-379?
MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.
How can I prevent CWE-379?
Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible. Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories.
How does Plexicus detect and fix CWE-379?
Plexicus's SAST engine matches the data-flow signature for CWE-379 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-379?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/379.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-379
CWE-377 Parent
Insecure Temporary File
This vulnerability occurs when an application creates temporary files with insecure permissions or in predictable locations, allowing…
CWE-378 Sibling
Creation of Temporary File With Insecure Permissions
This vulnerability occurs when a program creates a temporary file but sets its file permissions too loosely, allowing other users or…
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.