CVE-2026-62847 in Metalama
Summary
by MITRE • 10/30/2026
Metalama is a Roslyn-based open-source patterns and architecture toolkit for C#. Prior to 2025.1.18, 2026.0.25 and 2026.1.19, Metalama.Framework and Metalama.Tool load and execute compile-time assemblies, auxiliary executable tools and embedded helper assemblies from predictable temporary directories. On `Linux` and `macOS`, the default `Path.GetTempPath()` location is world-writable, and existing artifacts are trusted based on sentinel or `.completed` marker files rather than integrity verification. A local unprivileged user on a shared machine or CI/build agent can pre-create the deterministic directory structure and plant a malicious DLL with the matching sentinel. When a higher-privileged developer or build account subsequently builds, Metalama skips regeneration and executes the planted artifact in the compiler, IDE or MSBuild process as the building user. This permits cross-user privilege escalation, reading source and secrets, supply-chain tampering with build output, or disrupting builds. Default Windows per-user temporary directories are protected by ACLs and are not affected. Deployer-selected insecure cache locations are outside the vulnerability's scope. This issue is fixed in versions 2025.1.18, 2026.0.25 and 2026.1.19.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Metalama Framework prior to version 2025.1.18 represents a critical insecure temporary file handling flaw that facilitates local privilege escalation through the manipulation of compile-time execution artifacts. As an open-source toolkit for C# built on Roslyn, Metalama operates by loading and executing auxiliary assemblies during the build process to generate code or enforce architectural patterns. The core technical deficiency lies in the reliance on predictable temporary directories managed via standard system APIs such as Path.GetTempPath() on Linux and macOS environments. These operating systems typically configure their default temporary paths with world-writable permissions, allowing any local user account to read, write, and execute files within that directory structure without restriction. This architectural choice creates a shared resource space where unprivileged users can interact directly with the build infrastructure intended for higher-privileged developers or continuous integration agents.
The exploitation mechanism exploits Metalama's optimization strategy which utilizes sentinel markers like .completed files to determine whether auxiliary tools need regeneration. When an initial build occurs, Metalama generates necessary helper assemblies and places them in a deterministic temporary location alongside these marker files. Subsequent builds check for the existence of these markers rather than verifying the cryptographic integrity or hash of the existing artifacts. An attacker with local unprivileged access can monitor this directory structure and pre-create the expected subdirectories containing malicious DLLs that mimic the naming conventions of legitimate Metalama helpers. By planting a crafted assembly before a privileged user initiates a build, the attacker ensures that when Metalama checks for the sentinel file, it finds both the marker and its own planted executable. Consequently, the framework skips regeneration and proceeds to load and execute the malicious DLL within the context of the building process.
This execution occurs with the privileges of the user triggering the build, which is frequently a developer account or a service account running on a CI/CD server such as Jenkins or GitHub Actions. The operational impact is severe, enabling cross-user privilege escalation where an unprivileged attacker gains code execution rights equivalent to the target user. This access allows for the exfiltration of sensitive source code, API keys, and other secrets stored in environment variables or configuration files accessible to that user. Furthermore, it permits supply-chain tampering by allowing the injection of malicious logic into build outputs, potentially compromising downstream consumers who rely on these artifacts. The vulnerability also supports denial-of-service attacks against shared development environments by disrupting builds through corrupted or conflicting assemblies. It is important to note that this specific vector does not affect Windows systems due to their default per-user temporary directory ACLs which restrict access to the creating user only, nor does it apply if deployers have explicitly configured insecure cache locations outside of standard system temp paths.
From a classification perspective, this vulnerability aligns with CWE-377 Insecure Temporary File and CWE-250 Execution with Unnecessary Privileges, as the application performs actions in an elevated context without verifying the integrity of inputs derived from untrusted sources. The attack pattern corresponds to ATT&CK technique T1496 Resource Hijacking or potentially T1059 Command and Scripting Interpreter if used for further lateral movement, though primarily it serves as a local privilege escalation vector via TOCTOU race conditions inherent in trusting marker files over content verification. Mitigation strategies require immediate upgrade to patched versions 2025.1.18, 2026.0.25, or 2026.1.19 which address the underlying file handling logic. For environments where upgrading is not immediately feasible, administrators should enforce stricter permissions on temporary directories used by build agents, implement mandatory integrity verification such as cryptographic hashing for all auxiliary assemblies before execution, and consider using isolated containerized build environments to prevent cross-user contamination of shared resources.