The Metalama Visual Studio integration deserializes messages received over a local named pipe without any type restrictions. The pipe, created with a predictable name, is shared between Visual Studio, the Roslyn code‑analysis process, and CodeLens. Because deserialization libraries such as Newtonsoft.Json and MessagePack are used with TypeNameHandling.All or a typeless resolver, any CLR type supplied by the attacker can be instantiated. This omission allows a local attacker who can write to that pipe to inject a payload that causes arbitrary code to execute inside the Visual Studio process. The vulnerability was present in Metalama releases 2023.0.101‑rc through 2025.1.18, 2026.0.25, and 2026.1.19, as well as the major release series 2026.1.0–2026.1.18 when typeless MessagePack was used. The problem exists in the Metalama + PostSharp extension from 2024.1 through 2026.1.4 and in the retired Metalama and Caravela extensions, which do not have a fix and need removal or migration.

Affected is Metalama, a Roslyn‑based patterns and architecture toolkit for C#, specifically its Visual Studio integration and associated extensions. The flaw requires the extension to be installed and running inside Visual Studio on Windows; default pipe ACLs allow only the same logged‑in user to write, so privilege escalation does not occur. Fixed releases are Metalama 2025.1.18, 2026.0.25, and 2026.1.19 for the core tool, and Metalama + PostSharp Visual Studio extension 2026.1.5 and later. Earlier Metalama‑free PostSharp versions are not affected.

The CVSS score is 7.3, indicating a high‑severity flaw. No EPSS score is published, so the exploitation likelihood cannot be quantified from public data, but the local nature of the attack and the absence of privilege escalation mean the threat is limited to the local user context. The vulnerability is not listed in the CISA KEV catalog. An attacker with access to a user account that has Visual Studio with the vulnerable Metalama extension installed can craft a malicious named‑pipe message, causing code execution inside the Visual Studio process, potentially allowing the attacker to influence projects, access source files, or gain persistence within the system. Because the flaw relies on the existence of the named pipe and the open deserialization setting, the attack is relatively straightforward for an attacker who can run a process as the same user.