CVE-2026-62848: Local Arbitrary Code Execution via Unsafe Deserialization in Metalama Named Pipe IPC

Metalama is an open-source, Roslyn-based meta-programming, aspect-oriented programming, and architecture validation framework for C#. To provide real-time design-time feedback, interactive code transformations, live diagnostic updates, and CodeLens summaries without blocking the primary user interface thread, Metalama utilizes a multi-process architecture inside Microsoft Visual Studio. This architecture coordinates state across the main Visual Studio process (devenv.exe), the out-of-process Roslyn code-analysis service (ServiceHub.RoslynCodeAnalysisService.exe), and dedicated CodeLens worker processes.

Inter-process communication (IPC) among these components is conducted over local Windows named pipes. The named pipe endpoints follow a deterministic naming convention: Metalama_{role}_{processId}_{hash(PackageVersion)}. Because process identifiers and installed package version hashes can be enumerated or computed by any process executing on the host, the IPC channel endpoints are predictable and discoverable to local processes.

CVE-2026-62848 (tracked as GHSA-h26j-4vp7-x9w2) stems from the deserialization of untrusted data (CWE-502) and improper control of dynamically-managed code resources (CWE-913) across these named pipe channels. Prior to the remediated versions, the RPC endpoints deserialized incoming polymorphic messages without restricting the instantiated Common Language Runtime (CLR) types against an explicit allow-list.

Any local process operating within the same logged-in Windows user session can open a client handle to the active named pipe and write arbitrary serialized objects to the wire. Because type resolution and object instantiation occur during deserialization—prior to application-level message validation—an attacker can trigger standard .NET deserialization gadget chains to execute arbitrary code inside the Visual Studio host process.

The underlying vulnerability manifests through two distinct serialization mechanisms depending on the Metalama release branch. Both mechanisms share the same architectural flaw: enabling dynamic polymorphic type resolution from wire metadata across an untrusted local IPC boundary without per-type validation.

In Metalama versions 2023.0 through 2026.0.x, the design-time RPC pipeline relied on Newtonsoft.Json configured with TypeNameHandling = TypeNameHandling.All. This setting instructs the JSON deserializer to read the $type metadata property from incoming JSON objects and resolve the specified CLR type dynamically. Although Metalama implemented a custom JsonSerializationBinder inheriting from DefaultSerializationBinder, the binder only performed coarse assembly-level mapping and validation rather than enforcing a per-type allow-list. Crucially, the binder permitted core runtime assemblies, including System.Private.CoreLib and mscorlib. In JsonSerializationBinder.BindToType(string? assemblyName, string typeName), the code called assembly.GetType(modifiedTypeName) and returned the resulting Type directly, allowing attackers to instantiate any type residing in preloaded system assemblies.

In the 2026.1.0 through 2026.1.18 release branch, Metalama migrated its IPC transport to StreamJsonRpc backed by MessagePack serialization to improve throughput. To handle polymorphic payloads within the RpcEventEnvelope.Data property (typed as the abstract base class RpcEventData), BaseEndpoint configured MessagePackSerializerOptions with TypelessObjectResolver.Instance:

internal static MessagePackSerializerOptions MessagePackOptions { get; } =
    MessagePackSerializerOptions.Standard.WithResolver(
        CompositeResolver.Create(
            TypelessObjectResolver.Instance,
            StandardResolver.Instance ) );

TypelessObjectResolver embeds the fully-qualified CLR type name directly into the binary MessagePack stream and invokes MessagePackSerializerOptions.LoadType(string typeName) during deserialization. Similar to .NET's deprecated BinaryFormatter and Newtonsoft's TypeNameHandling.All, TypelessObjectResolver without a custom LoadType filter permits the caller to specify and instantiate arbitrary CLR types from any loaded assembly.

> [!NOTE] > Standalone command-line builds (dotnet build or msbuild) and standalone PostSharp versions prior to Metalama unification do not initialize the design-time named-pipe server and are unaffected by this vulnerability.

The remediation was implemented in Pull Request #1651 across two primary commits: d97f52e1b53ffe4176b2b05c56ffdf1ccd2f53a9 for the 2026.1 MessagePack implementation, and 5b4ced29f2b25631cc2e44d05b0fd5fe838b6cbe as a backport for the 2025.1 and 2026.0 Newtonsoft.Json branches.

MessagePack Remediation (d97f52e1b53ffe4176b2b05c56ffdf1ccd2f53a9)

To secure the MessagePack pipeline in 2026.1, the patch wraps the standard serializer options in a custom RpcContractMessagePackOptions class within BaseEndpoint.cs:

internal static MessagePackSerializerOptions MessagePackOptions { get; } =
    new RpcContractMessagePackOptions(
        MessagePackSerializerOptions.Standard.WithResolver(
            CompositeResolver.Create(
                TypelessObjectResolver.Instance,
                StandardResolver.Instance ) ) );

RpcContractMessagePackOptions overrides the LoadType method and inspects the target Type for an explicit [RpcContract] attribute before allowing deserialization to proceed:

internal sealed class RpcContractMessagePackOptions : MessagePackSerializerOptions
{
    private readonly ConcurrentDictionary<Type, bool> _isAllowedCache = new();
 
    public RpcContractMessagePackOptions( MessagePackSerializerOptions copyFrom ) : base( copyFrom ) { }
 
    protected override MessagePackSerializerOptions Clone() => new RpcContractMessagePackOptions( this );
 
    public override Type LoadType( string typeName )
    {
        var type = base.LoadType( typeName );
 
        // Verify the resolved type is explicitly marked with [RpcContractAttribute]
        if ( type != null && !this.IsAllowed( type ) )
        {
            throw new MessagePackSerializationException(
                $"For security reasons, the type '{type.FullName}' cannot be deserialized over the design-time RPC channel "
                + $"because it is not marked with [{nameof(RpcContractAttribute)}]." );
        }
 
        return type;
    }
 
    private bool IsAllowed( Type type )
        => this._isAllowedCache.GetOrAdd( type, static t => t.GetCustomAttribute<RpcContractAttribute>( inherit: false ) != null );
}

Newtonsoft.Json Remediation (5b4ced29f2b25631cc2e44d05b0fd5fe838b6cbe)

For the branches using Newtonsoft.Json, the patch introduced JsonSerializationAllowList and modified JsonSerializationBinder.BindToType to enforce strict per-type validation at the deserialization boundary:

public override Type BindToType( string? assemblyName, string typeName )
{
    var type = assembly.GetType( modifiedTypeName );
 
    // SECURITY (#1651 / GHSA-h26j-4vp7-x9w2): Enforce per-type allow-list here at the untrusted boundary
    if ( type != null && !this._allowList.IsAllowed( type ) )
    {
        throw new InvalidOperationException(
            $"For security reasons, the type '{type.FullName}' from assembly '{assemblyName}' cannot be deserialized "
            + "over the design-time RPC channel because it is not on the RPC type allow-list. See issue #1651." );
    }
 
    return type;
}

The JsonSerializationAllowList restricts instantiation exclusively to primitive scalars (int, bool, long, double, string), enumerations, validated generic collections (ImmutableArray<>, ImmutableDictionary<,> with recursive checks on generic type arguments), and a static registry of known RPC data transfer objects (ProjectKey, RpcEventEnvelope, RpcEventData, CompilationResultChangedEventData, EndpointChangedEventData, AspectDatabaseAspectInstance, CodeLensSummary, DiagnosticData, and SerializableSyntaxTree).

Fix Completeness Assessment

Both patches intercept type resolution prior to object allocation and constructor invocation. By requiring inherit: false on RpcContractAttribute in the MessagePack implementation and enforcing recursive generic type argument validation in JsonSerializationAllowList, the fixes prevent attackers from leveraging derived classes or wrapping gadget types inside generic collection containers.

Exploiting CVE-2026-62848 requires local code execution within the same Windows user session as a running Visual Studio instance that has a vulnerable version of Metalama loaded. Default Windows named pipe Access Control Lists (ACLs) permit read/write operations from any process sharing the creator's security token. Consequently, a low-integrity or sandboxed background script, malicious npm/NuGet post-install hook, or compromised utility process can target devenv.exe.

To execute the attack, the local process enumerates active named pipes matching \\.\pipe\Metalama_* (or calculates the pipe name directly from the target PID and package version hash) and connects as a client.

In the Newtonsoft.Json attack path (2023.0 – 2026.0.x), the attacker sends a JSON-RPC message containing a $type directive pointing to a known .NET deserialization gadget, such as System.Configuration.Install.AssemblyInstaller or System.Windows.Data.ObjectDataProvider:

{
  "$type": "System.Configuration.Install.AssemblyInstaller, System.Configuration.Install",
  "Path": "C:\\Users\\Public\\payload.dll"
}

In the MessagePack attack path (2026.1.0 – 2026.1.18), the attacker constructs a StreamJsonRpc frame containing an RpcEventEnvelope whose polymorphic Data field uses the MessagePack ext type code reserved by TypelessObjectResolver to specify the assembly-qualified name of the gadget class. When the endpoint deserializes the frame, LoadType resolves the target class and populates its properties or invokes its deserialization constructors.

The patch commits include regression tests in RpcSerializationTests.cs and JsonRpcSerializationTests.cs that model this exact exploitation primitive by serializing an off-contract class (OffContractGadget) through an untyped object reference to force polymorphic type metadata emission:

[Fact]
public void OffContractType_RejectedOnDeserialize()
{
    // Models an attacker-chosen gadget: a type NOT on the allow-list,
    // serialized through the object path so its $type is written.
    var json = JsonConvert.SerializeObject( new OffContractGadget(), typeof(object), _settings );
 
    AssertRejectedByAllowList( () => JsonConvert.DeserializeObject<object>( json, _settings ) );
}

CVE-2026-62848 is assigned a CVSS v3.1 base score of 7.3 (High) with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H. The Attack Vector (AV:L) and Privileges Required (PR:L) reflect that the attacker must already possess local execution capabilities under the user's account. User Interaction (UI:R) is required because the victim user must actively run Visual Studio with a Metalama-enabled project or extension loaded for the named pipe listener to be instantiated.

Although the Scope is Unchanged (S:U) because Windows named pipe ACLs restrict access to the current user session, compromising the Visual Studio process (devenv.exe) or its Roslyn analysis worker carries significant operational impact:

1. Process Context Hijacking & Defense Evasion: devenv.exe and ServiceHub.RoslynCodeAnalysisService.exe are trusted developer binaries that routinely compile code, spawn child processes, read source repositories, and make outbound network requests. Executing arbitrary code inside devenv.exe allows an attacker to bypass application allow-listing rules or Endpoint Detection and Response (EDR) behavioral heuristics.
2. Credential and Token Theft: Visual Studio maintains in-memory authentication tokens for Azure DevOps, GitHub, NuGet feeds, and cloud deployment environments. Code executing within the devenv.exe memory space can extract these credentials directly.
3. Supply Chain Tampering: If the user runs Visual Studio elevated (as Administrator), an unprivileged process may be blocked by Windows Mandatory Integrity Control (MIC) depending on the pipe's integrity label, or if accessible, achieve silent elevation and inject malicious code directly into build outputs.

At the time of writing, the EPSS score for CVE-2026-62848 is 0.00186 (0.19%), placing it in the 8.31st percentile, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Addressing CVE-2026-62848 requires updating both project-level NuGet dependencies and installed Visual Studio IDE extensions to ensure all local IPC endpoints enforce strict type allow-listing.

Framework and Package Updates

Update all Metalama.* NuGet packages in affected repositories to the patched release corresponding to your active release branch:

• 2025.1 branch: Upgrade to 2025.1.18 or later.
• 2026.0 branch: Upgrade to 2026.0.25 or later.
• 2026.1 branch: Upgrade to 2026.1.19 or later.
• Preview and release candidate versions in the 2025.2.0-preview through 2025.2.5-rc range are unsupported and must be migrated to a patched 2026.0 or 2026.1 release.

Visual Studio Extension Updates

Because the Visual Studio extension hosts the design-time RPC endpoints inside devenv.exe, updating NuGet packages alone is insufficient if an outdated IDE extension remains installed:

• Update the Metalama + PostSharp Visual Studio extension to version 2026.1.5 or later via the Visual Studio Extension Manager or Marketplace.
• Immediately uninstall the deprecated standalone Metalama extension and the legacy Caravela Visual Studio extension, as neither receives security patches.

> [!WARNING] > Developer workstations that have opened legacy projects using vulnerable versions of Metalama may have cached design-time worker binaries. After updating packages and extensions, restart all devenv.exe and ServiceHub.RoslynCodeAnalysisService.exe processes to ensure unpatched named pipe listeners are terminated.