Metalama allows local code execution through DLL planting in shared temporary directories

Why it is Yellow

• CVSS 8.2 medium
• On your watchlist: NuGet

Affected packages

References

• https://github.com/advisories/GHSA-m6wq-39m7-9xpp
• https://github.com/metalama/Metalama/security/advisories/GHSA-m6wq-39m7-9xpp
• https://github.com/metalama/Metalama/pull/1719
• https://github.com/metalama/Metalama/commit/09911349a916e82194b1cfaa6d0a38acad928fc9
• https://github.com/metalama/Metalama/commit/92c4feecfce86d18fcb007ab6d3a1b4383326a2e
• https://github.com/metalama/Metalama/commit/ab9407263203c66d7c5680a34c28dba31f9951c9
• https://github.com/advisories/GHSA-m6wq-39m7-9xpp

Original description

## 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 `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. ## 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.