CVE-2026-62847: High severity nuget/Metalama.Framework vulnerability
Summary
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 METALAMATEMP 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.
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 ($XDGCACHEHOME / ~/.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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nuget/Metalama.Frameworkto a version that resolves this vulnerability.Fixed in 2026.0.25 - Upgrade
Upgrade
nuget/Metalama.Toolto a version that resolves this vulnerability.Fixed in 2026.0.25 - Upgrade
Upgrade
nuget/Metalama.Toolto a version that resolves this vulnerability.Fixed in 2025.1.18 - Upgrade
Upgrade
nuget/Metalama.Frameworkto a version that resolves this vulnerability.Fixed in 2025.1.18 - Upgrade
Upgrade
nuget/Metalama.Toolto a version that resolves this vulnerability.Fixed in 2026.1.19 - Upgrade
Upgrade
nuget/Metalama.Frameworkto a version that resolves this vulnerability.Fixed in 2026.1.19 - Upgrade
Upgrade
Metalama.Frameworkto a version that resolves this vulnerability.Fixed in 2026.1.19 - Upgrade
Upgrade
Metalama.Toolto a version that resolves this vulnerability.Fixed in 2026.1.19
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
The primary exposure is on shared Linux or macOS machines and CI/build agents where an unprivileged local user can write to the system temporary directory and a higher-privileged user or build/service account later runs a Metalama build. The default cache location on those platforms was Path.GetTempPath(), typically /tmp, which is world-writable.
What does an attacker need to exploit it?
An attacker needs local unprivileged access to the same machine or build agent and the ability to predict and pre-create Metalama's cache directory structure. They must place a malicious DLL and the matching sentinel or .completed marker so Metalama skips regeneration and trusts the planted artifacts.
What execution context can the attacker gain?
The planted assembly is loaded and executed in the compiler, IDE, or MSBuild process that subsequently uses it. This can give the attacker the privileges of the user, build account, or service account running that process.
Which Metalama artifact paths are affected?
Affected paths include cached compile-time assemblies generated from aspects, auxiliary executable tools extracted locally and launched by Metalama, and embedded .NET helper assemblies extracted locally and loaded into the build or IDE process.