Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Metalama uses a local named-pipe channel to communicate between its Visual Studio processes — the Visual Studio UI process (`devenv`), the out-of-process Roslyn code-analysis process, and the CodeLens process. This channel deserialized messages from the pipe without restricting which CLR types could be instantiated. A local process able to write to the pipe can send a crafted message that instantiates arbitrary .NET types — a deserialization primitive in the same class as `BinaryFormatter` (CWE-502), and a well-known gadget-chain code-execution vector. The flaw is present, via two successive serializers, in every Metalama release from the first public version (2023.0) up to and including 2026.1.18, and is fixed in 2026.1.19. The pipe name is predictable: `Metalama_{role}_{processId}_{hash(PackageVersion)}`, derived from the public package version and a locally-enumerable process id. This channel is used by the Visual Studio integration only (Windows named…
Recommended action: Upgrade to 2026.1.19, 2026.0.25 or 2025.1.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Metalama loaded and executed compile-time assemblies, auxiliary executable tools, and embedded helper assemblies from predictable temporary directories. On Linux and macOS the default cache location was the world-writable system temporary directory (Path.GetTempPath(), i.e. /tmp), and previously-generated artifacts were trusted based on the presence of a sentinel/.completed marker file rather than on any integrity verification. A local, unprivileged user on a shared machine or CI/build agent can pre-create the deterministic cache directory structure and plant a malicious DLL together with the matching sentinel file. When a higher-privileged user (or build/service account) subsequently runs a build, Metalama finds the sentinel, skips regeneration, and loads and executes the attacker-supplied assembly inside the compiler / IDE / MSBuild process. Affected load-and-execute paths: - the cache of compile-time assemblies that Metalama generates from your aspects; - auxiliary…
Recommended action: Upgrade to 2026.1.19, 2026.0.25 or 2025.1.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.