CWE-377
Allowed-with-ReviewInsecure Temporary File
Abstraction: Class · Status: Incomplete
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
200 vulnerabilities reference this CWE, most recent first.
GHSA-H249-J3V7-74FW
Vulnerability from github – Published: 2026-10-13 21:33 – Updated: 2026-10-13 21:33Elio through 1.13.0 contains an insecure temporary file vulnerability that allows local users to overwrite another user's files by pre-creating symbolic links at predictable capture paths. Attackers who know the victim's Elio process ID can plant a symlink so previewing media, fonts or archives truncates and overwrites victim-owned files.
{
"affected": [],
"aliases": [
"CVE-2026-110234"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-13T19:18:48Z",
"severity": "MODERATE"
},
"details": "Elio through 1.13.0 contains an insecure temporary file vulnerability that allows local users to overwrite another user\u0027s files by pre-creating symbolic links at predictable capture paths. Attackers who know the victim\u0027s Elio process ID can plant a symlink so previewing media, fonts or archives truncates and overwrites victim-owned files.",
"id": "GHSA-h249-j3v7-74fw",
"modified": "2026-10-13T21:33:40Z",
"published": "2026-10-13T21:33:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-110234"
},
{
"type": "WEB",
"url": "https://github.com/elio-fm/elio/blob/e7daae44ce748310de441499576bdc31b936d54c/src/preview/archives/external_tools.rs#L30-L45"
},
{
"type": "WEB",
"url": "https://github.com/elio-fm/elio/blob/e7daae44ce748310de441499576bdc31b936d54c/src/preview/external_commands.rs#L14-L47"
},
{
"type": "WEB",
"url": "https://github.com/elio-fm/elio/blob/e7daae44ce748310de441499576bdc31b936d54c/src/preview/external_commands.rs#L92-L95"
},
{
"type": "WEB",
"url": "https://github.com/elio-fm/elio/releases/tag/v1.13.0"
},
{
"type": "WEB",
"url": "https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/r1d_wQojfg"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/elio-through-1.13.0-insecure-temporary-file-creation-in-external-preview-command-capture"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-H8Q4-9GGW-GCM9
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41A Insecure Temporary File vulnerability in skuba of SUSE CaaS Platform 4.5 allows local attackers to leak the bootstrapToken or modify the configuration file before it is processed, leading to arbitrary modifications of the machine/cluster.
{
"affected": [],
"aliases": [
"CVE-2020-8030"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-11T16:15:00Z",
"severity": "MODERATE"
},
"details": "A Insecure Temporary File vulnerability in skuba of SUSE CaaS Platform 4.5 allows local attackers to leak the bootstrapToken or modify the configuration file before it is processed, leading to arbitrary modifications of the machine/cluster.",
"id": "GHSA-h8q4-9ggw-gcm9",
"modified": "2022-05-24T17:41:53Z",
"published": "2022-05-24T17:41:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8030"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1177361"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HFV2-PF68-M33X
Vulnerability from github – Published: 2025-12-09 17:12 – Updated: 2025-12-09 21:37Impact
Due to unsafe handling and deletion of temporary files during the dictionary upload process, an attacker with access to the backoffice can trigger predictable requests to temporary file paths. The application’s error responses (HTTP 500 when a file exists, 404 when it does not) allow the attacker to enumerate the existence of arbitrary files on the server’s filesystem. This vulnerability does not allow reading or writing file contents.
In certain configurations, incomplete clean-up of temporary upload files may additionally expose the NTLM hash of the Windows account running the Umbraco application. The direct impact of this vulnerability is therefore limited to confidentiality, which is reflected in its CVSS base score of 4.9
While the CVSS Base Score captures only the immediate effect, the practical risk varies significantly based on hosting environment and identity configuration. Umbraco Cloud sites run under low-privilege, isolated Azure App Service worker identities, which mitigates the impact of any credential exposure. In contrast, self-hosted deployments could run Umbraco using privileged local or domain accounts. If such an account’s NTLM hash is disclosed, an attacker may be able to: - Perform NTLM relay attacks - Crack the hash offline to recover the underlying password - Authenticate as the compromised identity - Access internal systems trusted by that identity - Move laterally within the network - Potentially escalate to full domain compromise in weakly segmented environments
These outcomes are not part of the CVSS base score, which only rates the immediate confidentiality impact, but represent realistic downstream consequences for installations using elevated or widely-trusted service accounts. Self-hosted environments running Umbraco under privileged identities are therefore at significantly higher risk.
Vulnerability found and reported by Tomasz Holeksa at Pentest Limited
Patches
The issue has been patched in 13.12.1.
Workarounds
The issue can only be exploited by authorized backoffice accounts with access to the "Translations" section.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 13.12.0"
},
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Cms"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "13.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66625"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-377",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-09T17:12:18Z",
"nvd_published_at": "2025-12-09T20:15:55Z",
"severity": "MODERATE"
},
"details": "### Impact\nDue to unsafe handling and deletion of temporary files during the dictionary upload process, an attacker with access to the backoffice can trigger predictable requests to temporary file paths. The application\u2019s error responses (HTTP 500 when a file exists, 404 when it does not) allow the attacker to enumerate the existence of arbitrary files on the server\u2019s filesystem. This vulnerability does not allow reading or writing file contents.\n\nIn certain configurations, incomplete clean-up of temporary upload files may additionally expose the NTLM hash of the Windows account running the Umbraco application. The direct impact of this vulnerability is therefore limited to confidentiality, which is reflected in its CVSS base score of 4.9\n\nWhile the CVSS Base Score captures only the immediate effect, the practical risk varies significantly based on hosting environment and identity configuration. Umbraco Cloud sites run under low-privilege, isolated Azure App Service worker identities, which mitigates the impact of any credential exposure. In contrast, self-hosted deployments could run Umbraco using privileged local or domain accounts. If such an account\u2019s NTLM hash is disclosed, an attacker may be able to:\n- Perform NTLM relay attacks\n- Crack the hash offline to recover the underlying password\n- Authenticate as the compromised identity\n- Access internal systems trusted by that identity\n- Move laterally within the network\n- Potentially escalate to full domain compromise in weakly segmented environments\n\nThese outcomes are not part of the CVSS base score, which only rates the immediate confidentiality impact, but represent realistic downstream consequences for installations using elevated or widely-trusted service accounts. Self-hosted environments running Umbraco under privileged identities are therefore at significantly higher risk.\n\nVulnerability found and reported by Tomasz Holeksa at Pentest Limited\n\n### Patches\nThe issue has been patched in 13.12.1.\n\n### Workarounds\nThe issue can only be exploited by authorized backoffice accounts with access to the \"Translations\" section.",
"id": "GHSA-hfv2-pf68-m33x",
"modified": "2025-12-09T21:37:25Z",
"published": "2025-12-09T17:12:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/umbraco/Umbraco-CMS/security/advisories/GHSA-hfv2-pf68-m33x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66625"
},
{
"type": "WEB",
"url": "https://github.com/umbraco/Umbraco-CMS/commit/7505efd433189037f46547932d4a8b603fd4a615"
},
{
"type": "PACKAGE",
"url": "https://github.com/umbraco/Umbraco-CMS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Umbraco Vulnerable to Improper File Access and Credential Exposure in Dictionary Import Functionality"
}
GHSA-HQ87-H4JG-VXFW
Vulnerability from github – Published: 2023-09-20 18:30 – Updated: 2024-09-25 17:57In Jenkins 2.423 and earlier, LTS 2.414.1 and earlier, uploaded files processed via the Stapler web framework and the Jenkins API MultipartFormDataParser create temporary files in the system temporary directory with the default permissions for newly created files.
If these permissions are overly permissive, attackers with access to the system temporary directory may be able to read and write the file before it is used.
This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it. Jenkins 2.424, LTS 2.414.2 creates the temporary files in a subdirectory with more restrictive permissions.
As a workaround, you can change your default temporary-file directory using the Java system property java.io.tmpdir, if you’re concerned about this issue but unable to immediately update Jenkins.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.50"
},
{
"fixed": "2.414.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.415"
},
{
"fixed": "2.424"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43498"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-21T21:37:19Z",
"nvd_published_at": "2023-09-20T17:15:11Z",
"severity": "LOW"
},
"details": "In Jenkins 2.423 and earlier, LTS 2.414.1 and earlier, uploaded files processed via the Stapler web framework and the Jenkins API `MultipartFormDataParser` create temporary files in the system temporary directory with the default permissions for newly created files.\n\nIf these permissions are overly permissive, attackers with access to the system temporary directory may be able to read and write the file before it is used.\n\nThis vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it.\nJenkins 2.424, LTS 2.414.2 creates the temporary files in a subdirectory with more restrictive permissions.\n\nAs a workaround, you can change your default temporary-file directory using the Java system property `java.io.tmpdir`, if you\u2019re concerned about this issue but unable to immediately update Jenkins.",
"id": "GHSA-hq87-h4jg-vxfw",
"modified": "2024-09-25T17:57:39Z",
"published": "2023-09-20T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43498"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-09-20/#SECURITY-3073"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/09/20/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins temporary uploaded file created with insecure permissions"
}
GHSA-JJVP-WFP8-RV69
Vulnerability from github – Published: 2023-01-06 21:30 – Updated: 2023-01-12 20:58A vulnerability has been found in devent globalpom-utils up to 4.5.0 and classified as critical. This vulnerability affects the function createTmpDir of the file globalpomutils-fileresources/src/main/java/com/anrisoftware/globalpom/fileresourcemanager/FileResourceManagerProvider.java. The manipulation leads to insecure temporary file. The attack can be initiated remotely. Upgrading to version 4.5.1 can address this issue. The name of the patch is 77a820bac2f68e662ce261ecb050c643bd7ee560. It is recommended to upgrade the affected component. VDB-217570 is the identifier assigned to this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.anrisoftware.globalpom:globalpomutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-25068"
],
"database_specific": {
"cwe_ids": [
"CWE-377",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-12T20:58:04Z",
"nvd_published_at": "2023-01-06T21:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability has been found in devent globalpom-utils up to 4.5.0 and classified as critical. This vulnerability affects the function `createTmpDir` of the file `globalpomutils-fileresources/src/main/java/com/anrisoftware/globalpom/fileresourcemanager/FileResourceManagerProvider.java`. The manipulation leads to insecure temporary file. The attack can be initiated remotely. Upgrading to version 4.5.1 can address this issue. The name of the patch is 77a820bac2f68e662ce261ecb050c643bd7ee560. It is recommended to upgrade the affected component. VDB-217570 is the identifier assigned to this vulnerability.",
"id": "GHSA-jjvp-wfp8-rv69",
"modified": "2023-01-12T20:58:04Z",
"published": "2023-01-06T21:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25068"
},
{
"type": "WEB",
"url": "https://github.com/devent/globalpom-utils/commit/77a820bac2f68e662ce261ecb050c643bd7ee560"
},
{
"type": "PACKAGE",
"url": "https://github.com/devent/globalpom-utils"
},
{
"type": "WEB",
"url": "https://github.com/devent/globalpom-utils/releases/tag/globalpomutils-4.5.1"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.217570"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.217570"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "globalpom-utils has Insecure Temporary File"
}
GHSA-M5J9-QJXX-93W2
Vulnerability from github – Published: 2022-12-22 00:30 – Updated: 2022-12-29 21:30A vulnerability was found in pig-vector and classified as problematic. Affected by this issue is the function LogisticRegression of the file src/main/java/org/apache/mahout/pig/LogisticRegression.java. The manipulation leads to insecure temporary file. The attack needs to be approached locally. The name of the patch is 1e7bd9fab5401a2df18d2eabd802adcf0dcf1f15. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-216500.
{
"affected": [],
"aliases": [
"CVE-2022-4641"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-21T22:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in pig-vector and classified as problematic. Affected by this issue is the function LogisticRegression of the file src/main/java/org/apache/mahout/pig/LogisticRegression.java. The manipulation leads to insecure temporary file. The attack needs to be approached locally. The name of the patch is 1e7bd9fab5401a2df18d2eabd802adcf0dcf1f15. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-216500.",
"id": "GHSA-m5j9-qjxx-93w2",
"modified": "2022-12-29T21:30:29Z",
"published": "2022-12-22T00:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4641"
},
{
"type": "WEB",
"url": "https://github.com/tdunning/pig-vector/pull/2"
},
{
"type": "WEB",
"url": "https://github.com/tdunning/pig-vector/commit/1e7bd9fab5401a2df18d2eabd802adcf0dcf1f15"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.216500"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M6WQ-39M7-9XPP
Vulnerability from github – Published: 2026-10-14 19:24 – Updated: 2026-10-14 19:24Summary
Metalama loaded and executed compile-time assemblies, auxiliary executable tools, and embedded helper assemblies from predictable temporary directories. On Linux and macOS the default cache location was the world-writable system temporary directory (Path.GetTempPath(), i.e. /tmp), and previously-generated artifacts were trusted based on the presence of a sentinel/.completed marker file rather than on any integrity verification.
A local, unprivileged user on a shared machine or CI/build agent can pre-create the deterministic cache directory structure and plant a malicious DLL together with the matching sentinel file. When a higher-privileged user (or build/service account) subsequently runs a build, Metalama finds the sentinel, skips regeneration, and loads and executes the attacker-supplied assembly inside the compiler / IDE / MSBuild process.
Affected load-and-execute paths: - the cache of compile-time assemblies that Metalama generates from your aspects; - auxiliary executable tools that Metalama extracts to a local directory and then launches; - embedded .NET helper assemblies that Metalama extracts to a local directory and loads into the build / IDE process.
Impact
Arbitrary code execution in the security context of the building user — i.e. a local privilege escalation across user accounts on shared POSIX systems (multi-user developer machines, CI/build agents). The attacker obtains code execution as the victim without holding the victim's privileges, and can read source/secrets, tamper with build output (supply-chain injection), or disrupt builds.
Affected configurations
- Linux and macOS, default configuration — affected. The shipped default uses the world-writable system temp directory.
- Windows, default configuration — not affected. The default per-user temporary directory is protected by OS ACLs, so cross-user planting is not possible.
- The
METALAMA_TEMPenvironment variable is a deployer-controlled override and is out of scope: pointing it at an insecure (e.g. world-writable or attacker-owned) location is a deployment misconfiguration, not a defect in the product.
Severity
CVSS v3.1: AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H = 8.2 (High) for the affected POSIX default configuration (Scope:Changed reflects the cross-user privilege escalation).
CVSS v4.0 cross-check: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:H = 6.0 (Medium), which more granularly attributes low impact to the cache itself and high impact to the subsequent build process. The honest range is therefore Medium-High depending on the scoring model and platform.
Fix
Caches and extraction directories were relocated from the world-writable system temp directory to per-user application-data locations ($XDG_CACHE_HOME / ~/.cache/Metalama on POSIX), relying on OS-enforced per-user ownership as the trust boundary. Fixed in 2026.1.19.
Weaknesses
- CWE-377: Insecure Temporary File
- CWE-427: Uncontrolled Search Path Element
Affected packages
- Metalama.Framework < 2026.1.19,
- Metalama.Tool < 2026.1.19
Internal tracking: metalama/Metalama#1650.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Framework"
},
"ranges": [
{
"events": [
{
"introduced": "2026.1.0-preview"
},
{
"fixed": "2026.1.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Tool"
},
"ranges": [
{
"events": [
{
"introduced": "2026.1.0-preview"
},
{
"fixed": "2026.1.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Framework"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2025.1.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Tool"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2025.1.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Tool"
},
"ranges": [
{
"events": [
{
"introduced": "2026.0.0-preview"
},
{
"fixed": "2026.0.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Metalama.Framework"
},
"ranges": [
{
"events": [
{
"introduced": "2026.0.0-preview"
},
{
"fixed": "2026.0.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62847"
],
"database_specific": {
"cwe_ids": [
"CWE-377",
"CWE-427"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-14T19:24:53Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nMetalama loaded and executed compile-time assemblies, auxiliary executable tools, and embedded helper assemblies from predictable temporary directories. On Linux and macOS the default cache location was the world-writable system temporary directory (`Path.GetTempPath()`, i.e. `/tmp`), and previously-generated artifacts were trusted based on the presence of a sentinel/`.completed` marker file rather than on any integrity verification.\n\nA local, unprivileged user on a shared machine or CI/build agent can pre-create the deterministic cache directory structure and plant a malicious DLL together with the matching sentinel file. When a higher-privileged user (or build/service account) subsequently runs a build, Metalama finds the sentinel, skips regeneration, and loads and executes the attacker-supplied assembly inside the compiler / IDE / MSBuild process.\n\nAffected load-and-execute paths:\n- the cache of compile-time assemblies that Metalama generates from your aspects;\n- auxiliary executable tools that Metalama extracts to a local directory and then launches;\n- embedded .NET helper assemblies that Metalama extracts to a local directory and loads into the build / IDE process.\n\n## Impact\n\nArbitrary code execution in the security context of the building user \u2014 i.e. a local privilege escalation across user accounts on shared POSIX systems (multi-user developer machines, CI/build agents). The attacker obtains code execution as the victim without holding the victim\u0027s privileges, and can read source/secrets, tamper with build output (supply-chain injection), or disrupt builds.\n\n## Affected configurations\n\n- **Linux and macOS, default configuration \u2014 affected.** The shipped default uses the world-writable system temp directory.\n- **Windows, default configuration \u2014 not affected.** The default per-user temporary directory is protected by OS ACLs, so cross-user planting is not possible.\n- The `METALAMA_TEMP` environment variable is a deployer-controlled override and is **out of scope**: pointing it at an insecure (e.g. world-writable or attacker-owned) location is a deployment misconfiguration, not a defect in the product.\n\n## Severity\n\nCVSS v3.1: `AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H` = **8.2 (High)** for the affected POSIX default configuration (Scope:Changed reflects the cross-user privilege escalation).\n\nCVSS v4.0 cross-check: `CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:H` = 6.0 (Medium), which more granularly attributes low impact to the cache itself and high impact to the subsequent build process. The honest range is therefore Medium-High depending on the scoring model and platform.\n\n## Fix\n\nCaches and extraction directories were relocated from the world-writable system temp directory to per-user application-data locations (`$XDG_CACHE_HOME` / `~/.cache/Metalama` on POSIX), relying on OS-enforced per-user ownership as the trust boundary. Fixed in **2026.1.19**.\n\n## Weaknesses\n\n- CWE-377: Insecure Temporary File\n- CWE-427: Uncontrolled Search Path Element\n\n## Affected packages\n\n- Metalama.Framework \u003c 2026.1.19, \n- Metalama.Tool \u003c 2026.1.19\n\nInternal tracking: metalama/Metalama#1650.",
"id": "GHSA-m6wq-39m7-9xpp",
"modified": "2026-10-14T19:24:53Z",
"published": "2026-10-14T19:24:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/metalama/Metalama/security/advisories/GHSA-m6wq-39m7-9xpp"
},
{
"type": "WEB",
"url": "https://github.com/metalama/Metalama/pull/1719"
},
{
"type": "WEB",
"url": "https://github.com/metalama/Metalama/commit/09911349a916e82194b1cfaa6d0a38acad928fc9"
},
{
"type": "WEB",
"url": "https://github.com/metalama/Metalama/commit/92c4feecfce86d18fcb007ab6d3a1b4383326a2e"
},
{
"type": "WEB",
"url": "https://github.com/metalama/Metalama/commit/ab9407263203c66d7c5680a34c28dba31f9951c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/metalama/Metalama"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Metalama allows local code execution through DLL planting in shared temporary directories"
}
GHSA-MCR4-QMVW-PX4G
Vulnerability from github – Published: 2026-10-07 20:35 – Updated: 2026-10-07 20:35Summary
When no system-installed liblz4-java is found, net.jpountz.util.Native.load() extracts the bundled native library to java.io.tmpdir and loads it with System.load. The path of the extracted library can be predicted before it is created, and the library file is opened without exclusive creation. Another local user who can write to the same temporary directory can therefore create the file first and control the code that is loaded.
Details
tempLibLock = File.createTempFile("liblz4-java-", "." + os().libExtension + ".lck");
tempLib = new File(tempLibLock.getAbsolutePath().replaceFirst(".lck$", ""));
// copy to tempLib
try (FileOutputStream out = new FileOutputStream(tempLib)) { ... }
...
System.load(tempLib.getAbsolutePath());
Only the .lck file is created safely, with a random name and exclusive creation. The library path is the .lck name without the .lck suffix, and nothing reserves it. new FileOutputStream(tempLib) opens it with O_CREAT|O_TRUNC and follows symlinks.
In a shared, world-writable temporary directory, another user can watch for the .lck file and create the corresponding library file before it is opened. If they win that race, they own the file. The victim then writes into the attacker-owned file, and the attacker can overwrite it again before System.load.
Whether this can be exploited depends on the host:
- With
fs.protected_regular = 0, the attacker can pre-create a world-writable file, and their code is then loaded into the victim's JVM. - With
fs.protected_regular >= 1(the default on many systemd-based distributions), the victim's open fails. The library then fails to load and the library falls back to the Java implementations, so the attacker can only cause a denial of service. - A symlink variant is blocked by
fs.protected_symlinks = 1. - Temporary directories without the sticky bit, or shared across users in containers, are exploitable whatever these settings are.
This behaviour was introduced upstream in commit c3ddae5 (lz4-java 1.7.0), which swapped which of the two files is created with createTempFile.
Impact
A local user who can write to the same temporary directory as a victim process that uses the bundled JNI library may be able to execute code as the victim. Exploitation requires a shared temporary directory, host settings that permit it, and winning a race.
The issue does not apply if liblz4-java is found on java.library.path, if java.io.tmpdir is private to the user (for example systemd PrivateTmp, or a per-user temporary directory), or if only the Java implementations are used.
Patch
Fixed in lz4-java 1.11.4. The native library is now extracted directly into a file created by File.createTempFile, which has a random name and is created exclusively, so a file or symlink planted in advance cannot be reused. The .lck lock files are no longer used. Instead, the startup cleanup removes stale liblz4-java-* temporary files (including .lck files left by older versions) only once they are more than one hour old.
For older versions, the workaround is to set java.io.tmpdir to a directory writable only by the application user, or install liblz4-java on java.library.path.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.3"
},
"package": {
"ecosystem": "Maven",
"name": "at.yawk.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106451"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-377"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:35:51Z",
"nvd_published_at": "2026-10-06T20:17:27Z",
"severity": "HIGH"
},
"details": "### Summary\n\nWhen no system-installed `liblz4-java` is found, `net.jpountz.util.Native.load()` extracts the bundled native library to `java.io.tmpdir` and loads it with `System.load`. The path of the extracted library can be predicted before it is created, and the library file is opened without exclusive creation. Another local user who can write to the same temporary directory can therefore create the file first and control the code that is loaded.\n\n### Details\n\n```java\ntempLibLock = File.createTempFile(\"liblz4-java-\", \".\" + os().libExtension + \".lck\");\ntempLib = new File(tempLibLock.getAbsolutePath().replaceFirst(\".lck$\", \"\"));\n// copy to tempLib\ntry (FileOutputStream out = new FileOutputStream(tempLib)) { ... }\n...\nSystem.load(tempLib.getAbsolutePath());\n```\n\nOnly the `.lck` file is created safely, with a random name and exclusive creation. The library path is the `.lck` name without the `.lck` suffix, and nothing reserves it. `new FileOutputStream(tempLib)` opens it with `O_CREAT|O_TRUNC` and follows symlinks.\n\nIn a shared, world-writable temporary directory, another user can watch for the `.lck` file and create the corresponding library file before it is opened. If they win that race, they own the file. The victim then writes into the attacker-owned file, and the attacker can overwrite it again before `System.load`.\n\nWhether this can be exploited depends on the host:\n\n- With `fs.protected_regular = 0`, the attacker can pre-create a world-writable file, and their code is then loaded into the victim\u0027s JVM.\n- With `fs.protected_regular \u003e= 1` (the default on many systemd-based distributions), the victim\u0027s open fails. The library then fails to load and the library falls back to the Java implementations, so the attacker can only cause a denial of service.\n- A symlink variant is blocked by `fs.protected_symlinks = 1`.\n- Temporary directories without the sticky bit, or shared across users in containers, are exploitable whatever these settings are.\n\nThis behaviour was introduced upstream in commit c3ddae5 (lz4-java 1.7.0), which swapped which of the two files is created with `createTempFile`.\n\n### Impact\n\nA local user who can write to the same temporary directory as a victim process that uses the bundled JNI library may be able to execute code as the victim. Exploitation requires a shared temporary directory, host settings that permit it, and winning a race.\n\nThe issue does not apply if `liblz4-java` is found on `java.library.path`, if `java.io.tmpdir` is private to the user (for example systemd `PrivateTmp`, or a per-user temporary directory), or if only the Java implementations are used.\n\n### Patch\n\nFixed in lz4-java 1.11.4. The native library is now extracted directly into a file created by `File.createTempFile`, which has a random name and is created exclusively, so a file or symlink planted in advance cannot be reused. The `.lck` lock files are no longer used. Instead, the startup cleanup removes stale `liblz4-java-*` temporary files (including `.lck` files left by older versions) only once they are more than one hour old.\n\nFor older versions, the workaround is to set `java.io.tmpdir` to a directory writable only by the application user, or install `liblz4-java` on `java.library.path`.",
"id": "GHSA-mcr4-qmvw-px4g",
"modified": "2026-10-07T20:35:51Z",
"published": "2026-10-07T20:35:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-mcr4-qmvw-px4g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106451"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/commit/7a48b7f6b8099b9dab6541e4ac2ee0979dc55aa3"
},
{
"type": "PACKAGE",
"url": "https://github.com/yawkat/lz4-java"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "yawkat LZ4 Java: Native library extraction to a shared temporary directory is vulnerable to file replacement by another local user"
}
GHSA-MQ4F-242H-V9HJ
Vulnerability from github – Published: 2024-03-08 03:31 – Updated: 2026-04-02 21:31A privacy issue was addressed with improved handling of temporary files. This issue is fixed in macOS Sonoma 14.4, iOS 17.4 and iPadOS 17.4, watchOS 10.4. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2024-23287"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-08T02:15:50Z",
"severity": "MODERATE"
},
"details": "A privacy issue was addressed with improved handling of temporary files. This issue is fixed in macOS Sonoma 14.4, iOS 17.4 and iPadOS 17.4, watchOS 10.4. An app may be able to access user-sensitive data.",
"id": "GHSA-mq4f-242h-v9hj",
"modified": "2026-04-02T21:31:38Z",
"published": "2024-03-08T03:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23287"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/120881"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/120893"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/120895"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT214081"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT214084"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT214088"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT214081"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT214084"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT214088"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Mar/21"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Mar/24"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW53-2GX3-5W75
Vulnerability from github – Published: 2026-09-09 18:32 – Updated: 2026-09-09 18:32Dell PowerScale OneFS versions 9.12.0.0 through 9.13.1.0 contain an Insecure Temporary File vulnerability. A low privileged remote attacker could potentially exploit this vulnerability, leading to denial of service and information tampering.
{
"affected": [],
"aliases": [
"CVE-2026-40635"
],
"database_specific": {
"cwe_ids": [
"CWE-377"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T17:17:21Z",
"severity": "MODERATE"
},
"details": "Dell PowerScale OneFS versions 9.12.0.0 through 9.13.1.0 contain an Insecure Temporary File vulnerability. A low privileged remote attacker could potentially exploit this vulnerability, leading to denial of service and information tampering.",
"id": "GHSA-mw53-2gx3-5w75",
"modified": "2026-09-09T18:32:03Z",
"published": "2026-09-09T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40635"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000505684/dsa-2026-360-security-update-for-dell-powerscale-onefs-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-149: Explore for Predictable Temporary File Names
An attacker explores a target to identify the names and locations of predictable temporary files for the purpose of launching further attacks against the target. This involves analyzing naming conventions and storage locations of the temporary files created by a target application. If an attacker can predict the names of temporary files they can use this information to mount other attacks, such as information gathering and symlink attacks.
CAPEC-155: Screen Temporary Files for Sensitive Information
An adversary exploits the temporary, insecure storage of information by monitoring the content of files used to store temp data during an application's routine execution flow. Many applications use temporary files to accelerate processing or to provide records of state across multiple executions of the application. Sometimes, however, these temporary files may end up storing sensitive information. By screening an application's temporary files, an adversary might be able to discover such sensitive information. For example, web browsers often cache content to accelerate subsequent lookups. If the content contains sensitive information then the adversary could recover this from the web cache.