Summary
CVE-2026-62848 is an unsafe deserialization vulnerability in Metalama's Windows Visual Studio integration, where local named-pipe messages can cause attacker-controlled CLR types to be instantiated. A same-user local process that can write to the predictable pipe may achieve arbitrary code execution within an affected Visual Studio process, although the issue does not normally cross the Windows user boundary.
CVE-2026-62848 is an unsafe deserialization vulnerability in Metalama's Windows Visual Studio integration, where local named-pipe messages can cause attacker-controlled CLR types to be instantiated. A same-user local process that can write to the predictable pipe may achieve arbitrary code execution within an affected Visual Studio process, although the issue does not normally cross the Windows user boundary.
Affected context
The vulnerability occurs in the Windows Visual Studio integration when communication between Visual Studio, out-of-process Roslyn analysis, and CodeLens processes uses local named pipes without sufficiently restricting deserialized types. Affected deployments include integrations that use unsafe Newtonsoft.Json or typeless MessagePack handling; command-line and MSBuild-only builds generally do not use this communication channel. Default Windows pipe permissions typically limit access to processes running as the same logged-in user.
The vulnerability occurs in the Windows Visual Studio integration when communication between Visual Studio, out-of-process Roslyn analysis, and CodeLens processes uses local named pipes without sufficiently restricting deserialized types. Affected deployments include integrations that use unsafe Newtonsoft.Json or typeless MessagePack handling; command-line and MSBuild-only builds generally do not use this communication channel. Default Windows pipe permissions typically limit access to processes running as the same logged-in user.
Exploit preconditions
- Attack surface: Local Windows named-pipe communication used by the Visual Studio integration
- Required access: Ability to run a same-user local process that can write to the affected pipe
- Trigger point: Processing a crafted message received by the Visual Studio integration
- Why exploitation is possible: Deserialization permits wire-supplied CLR types or typeless objects to be instantiated without an effective allow-list
- Boundary limitation: Default pipe ACLs generally prevent lower-privileged users from writing to another user's pipe
- Attack surface: Local Windows named-pipe communication used by the Visual Studio integration
- Required access: Ability to run a same-user local process that can write to the affected pipe
- Trigger point: Processing a crafted message received by the Visual Studio integration
- Why exploitation is possible: Deserialization permits wire-supplied CLR types or typeless objects to be instantiated without an effective allow-list
- Boundary limitation: Default pipe ACLs generally prevent lower-privileged users from writing to another user's pipe
Why this happens
The underlying flaw is unsafe deserialization of attacker-influenced interprocess messages. JSON configurations using broad type-name handling and MessagePack configurations using typeless object resolution can treat serialized type metadata as an instruction to construct arbitrary runtime types. A serialization binder that only remaps assembly names does not provide sufficient protection when it still resolves arbitrary wire-supplied types. This behavior maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-913: Improper Control of Dynamically-Managed Code Resources also describing the insufficient restriction of dynamically selected types.
The underlying flaw is unsafe deserialization of attacker-influenced interprocess messages. JSON configurations using broad type-name handling and MessagePack configurations using typeless object resolution can treat serialized type metadata as an instruction to construct arbitrary runtime types. A serialization binder that only remaps assembly names does not provide sufficient protection when it still resolves arbitrary wire-supplied types. This behavior maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-913: Improper Control of Dynamically-Managed Code Resources also describing the insufficient restriction of dynamically selected types.
Potential impact
- A same-user local process may execute arbitrary code inside the affected Visual Studio process
- Confidentiality of data accessible to Visual Studio may be compromised
- Project files, source code, credentials, or development artifacts could be modified
- Visual Studio availability may be disrupted
- Development workflows or build-related activities could be tampered with
- The vulnerability could support local persistence within the user's development environment
- A same-user local process may execute arbitrary code inside the affected Visual Studio process
- Confidentiality of data accessible to Visual Studio may be compromised
- Project files, source code, credentials, or development artifacts could be modified
- Visual Studio availability may be disrupted
- Development workflows or build-related activities could be tampered with
- The vulnerability could support local persistence within the user's development environment
General mitigation guidance
Mitigation generally focuses on eliminating polymorphic deserialization of untrusted pipe messages and enforcing strict type boundaries.
Common defensive patterns include:
- Use schema-bound serializers that do not honor arbitrary wire-supplied type metadata
- Configure explicit allow-lists for every deserializable message type
- Validate message structure, length, role, and protocol state before object construction
- Prefer narrowly defined data-transfer objects over general-purpose runtime object graphs
- Preserve restrictive named-pipe ACLs and avoid broadening same-user or cross-user access
- Remove or migrate retired integrations that remain exposed to unsafe communication paths
- Apply least privilege to Visual Studio extensions and related helper processes
- Monitor extension installation and interprocess communication policy in managed development environments
Mitigation generally focuses on eliminating polymorphic deserialization of untrusted pipe messages and enforcing strict type boundaries.
Common defensive patterns include:
- Use schema-bound serializers that do not honor arbitrary wire-supplied type metadata
- Configure explicit allow-lists for every deserializable message type
- Validate message structure, length, role, and protocol state before object construction
- Prefer narrowly defined data-transfer objects over general-purpose runtime object graphs
- Preserve restrictive named-pipe ACLs and avoid broadening same-user or cross-user access
- Remove or migrate retired integrations that remain exposed to unsafe communication paths
- Apply least privilege to Visual Studio extensions and related helper processes
- Monitor extension installation and interprocess communication policy in managed development environments
How teams detect issues like this
High-level detection can include:
- Static analysis for Newtonsoft.Json
TypeNameHandlingsettings that permit broad polymorphism - Searches for
TypeNameHandling.All, typeless MessagePack resolvers, and unrestrictedBindToTypeimplementations - Code review checks for deserialization of named-pipe or other IPC input before authentication, schema validation, or type allow-list enforcement
- Tests that submit unknown, unexpected, or disallowed type metadata and verify rejection
- Policy enforcement preventing extensions from creating overly permissive local IPC endpoints
- Inventory reviews identifying active, retired, or migrated Visual Studio integrations that use the affected channel
- Neutral automated code-review or software-composition tools may help identify unsafe serializer configurations
High-level detection can include:
- Static analysis for Newtonsoft.Json
TypeNameHandlingsettings that permit broad polymorphism - Searches for
TypeNameHandling.All, typeless MessagePack resolvers, and unrestrictedBindToTypeimplementations - Code review checks for deserialization of named-pipe or other IPC input before authentication, schema validation, or type allow-list enforcement
- Tests that submit unknown, unexpected, or disallowed type metadata and verify rejection
- Policy enforcement preventing extensions from creating overly permissive local IPC endpoints
- Inventory reviews identifying active, retired, or migrated Visual Studio integrations that use the affected channel
- Neutral automated code-review or software-composition tools may help identify unsafe serializer configurations
