Metalama: Local code execution via DLL planting in world-writable temporary directories (Linux/macOS)
Affects Metalama.Framework before 2026.1.19 on Linux and macOS with the default cache, which uses the world-writable system temporary directory. Fixed in 2026.1.19.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 2025.1.18, 2026.0.25, 2026.1.19
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
Metalama.Framework and Metalama.Tool, the C# code-generation toolkit's compiler and build components, are affected on Linux and macOS. An unprivileged local user on a shared machine or build agent can plant a malicious library in a predictable temporary directory, which the build process then runs with the privileges of the developer or build account, potentially allowing privilege escalation, access to source code and secrets, or tampering with build output.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- metalama Metalama
fixed in 2025.1.18; From 2025.2.0-preview · through 2025.2.5-rc; From 2026.0.0-preview · fixed in 2026.0.25; From 2026.1.0-preview · fixed in 2026.1.19
References 7
Questions about CVE-2026-62847
What does this mean?
Metalama's default cache on Linux and macOS was the world-writable system temporary directory, so other local users could place files there that the build would load. This allows arbitrary code execution as the user running the build, which can enable privilege escalation across accounts, reading source and secrets, tampering with build output, or disrupting builds.Source: github.com
Am I affected, and how do I check?
Metalama.Framework versions before 2026.1.19, and before 2025.1.18 and 2026.0.25 on their branches, are affected, including the 2025.2 preview range up to 2025.2.5-rc. A reader can check the Metalama.Framework package version in the project's package references and whether the build runs on Linux or macOS with the default cache location.Source: github.com
What should I do about it?
Upgrade Metalama.Framework to 2026.1.19, or to 2025.1.18 or 2026.0.25 if staying on those branches.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data