CVE-2026-62847: 
C# vulnerability analysis and mitigation

CVE-2026-62847 is a local privilege escalation vulnerability in the Metalama .NET framework that allows an unprivileged local user to plant a malicious DLL in a predictable world-writable temporary directory, which is then loaded and executed by a higher-privileged build process. It affects Metalama.Framework and Metalama.Tool NuGet packages on Linux and macOS in versions >= 2026.1.0-preview, < 2026.1.19, < 2025.1.18, and >= 2026.0.0-preview, < 2026.0.25. Windows is not affected due to per-user ACL-protected temp directories. The vulnerability was originally published on June 27, 2026, and added to the GitHub Advisory Database on October 14, 2026. It carries a CVSS v3.1 score of 8.2 (High) and a CVSS v4.0 score of 6.0 (Medium) (GitHub Advisory).

The root cause is classified under CWE-377 (Insecure Temporary File) and CWE-427 (Uncontrolled Search Path Element). On Linux and macOS, Metalama used Path.GetTempPath() (resolving to /tmp) as the base for its cache directory, which is world-writable. Artifacts stored there — including compile-time assemblies, auxiliary executable tools, and embedded .NET helper assemblies — were trusted solely based on the presence of a sentinel .completed marker file, with no cryptographic integrity verification. An attacker with local unprivileged access can pre-create the deterministic cache directory structure (whose path is predictable based on assembly version and module ID) and plant a malicious DLL alongside a forged sentinel file; when a higher-privileged user or CI service account subsequently triggers a build, Metalama skips regeneration and loads the attacker-controlled assembly into the compiler, IDE, or MSBuild process (GitHub Advisory, Fix Commit).

Successful exploitation results in arbitrary code execution in the security context of the victim (building) user, constituting local privilege escalation across user accounts on shared POSIX systems such as multi-user developer machines and CI/build agents. The attacker can read source code and secrets accessible to the victim account, tamper with build output to inject malicious code into the software supply chain, or disrupt builds entirely. The scope is changed (CVSS S:C) because the attacker's low-privileged code executes in the context of a different, higher-privileged user account (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The vulnerability requires local access and low privileges, and exploitation is contingent on a higher-privileged user running a build after the attacker has pre-staged the malicious artifacts — a passive user interaction requirement. The CVE status is listed as "Reserved" and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog. No EPSS score or threat actor attribution is available.

1. Reconnaissance: Identify a shared Linux or macOS machine (e.g., a multi-user CI/build agent) where Metalama is used and where a higher-privileged user or service account periodically runs builds.
2. Determine cache path: Calculate the deterministic Metalama cache directory path under /tmp/Metalama/ using the target Metalama assembly version and module ID (a 4-byte hex string derived from the assembly's module GUID), e.g., /tmp/Metalama/Extract/<version>-<moduleid>/core/.
3. Pre-create directory structure: As the unprivileged attacker, create the full deterministic cache directory path under /tmp/Metalama/ before the legitimate build runs.
4. Plant malicious DLL: Copy a crafted malicious .NET assembly (DLL) into the pre-created directory, designed to execute attacker-controlled code when loaded by the .NET runtime.
5. Create sentinel file: Place a .completed marker file in the directory to signal to Metalama that the cache is valid and regeneration should be skipped.
6. Wait for victim build: Wait for the higher-privileged user or build service account to trigger a Metalama-enabled build. Metalama finds the sentinel, skips regeneration, and loads and executes the attacker-supplied DLL inside the compiler/MSBuild/IDE process with the victim's privileges.
7. Achieve objective: The malicious assembly executes arbitrary code as the victim — enabling credential theft, source code exfiltration, build artifact tampering (supply-chain injection), or persistence (GitHub Advisory, Fix Commit).

• File System: Unexpected directories or DLL files under /tmp/Metalama/ owned by a user other than the building user; presence of .completed sentinel files in Metalama cache directories not created by the legitimate build process; unexpected DLLs in /tmp/Metalama/Extract/ or /tmp/Metalama/ subdirectories.
• Process: Unusual child processes spawned by dotnet, msbuild, or IDE processes (e.g., bash, curl, wget, python, nc) during or after a build; unexpected network connections originating from build processes.
• Logs: Build logs showing Metalama loading assemblies from /tmp/Metalama/ rather than the expected per-user application-data path (e.g., ~/.local/share/Metalama/Temp/ or ~/.cache/Metalama/); MSBuild or compiler error/warning messages referencing unexpected assembly paths.
• File System (post-patch): Presence of the legacy /tmp/Metalama/ directory on systems that have been upgraded to patched versions — this directory should be cleaned up by the patched version's cache maintenance routine and its continued existence may indicate tampering or a failed upgrade.

Update Metalama.Framework and Metalama.Tool NuGet packages to the patched versions: 2026.1.19, 2025.1.18, or 2026.0.25 depending on the release branch in use. The fix relocates the Metalama temp directory from the world-writable /tmp to a per-user application-data location ($XDG_CACHE_HOME/Metalama or ~/.local/share/Metalama/Temp on POSIX systems), relying on OS-enforced per-user ownership as the trust boundary. As a short-term workaround prior to patching, set the METALAMA_TEMP environment variable to a directory writable only by the building user. Additionally, consider using isolated build environments (e.g., containers or dedicated unprivileged build accounts) and implementing file integrity monitoring on /tmp/Metalama/ to detect suspicious DLL placement (GitHub Advisory, Fix Commit).

The vulnerability was reported and fixed by the Metalama maintainer Gaël Fraiteur (gfraiteur) of SharpCrafters s.r.o., who authored the fix commits and the security advisory. The fix was backported across all supported release branches (2025.1, 2026.0, and 2026.1) and merged via a dedicated security backport pull request. No significant external researcher commentary, media coverage, or notable community discussion beyond the GitHub advisory and associated pull request has been identified (GitHub PR #1719, GitHub Advisory).