Security and Privacy Hardening Across All PostSharp and Metalama Branches

Here is what shipped. Each links to its release notes, where you can see the full list of resolved tickets (about 60 in total):

• PostSharp 2024.0.24 (LTS branch)
• PostSharp 2026.0.13 (latest, also LTS)
• Metalama 2026.1.19 (latest and LTS)
• Metalama 2026.0.25 (Extended Support — advisory fixes only)
• Metalama 2025.1.18 (Extended Support — advisory fixes only)
• PostSharp and Metalama Visual Studio Tools 2026.1.5

All packages are on NuGet.org, and the extension is on the Visual Studio Marketplace.

Scope and attack vectors

We published GitHub Security Advisories for the main findings, and a few are rated High. PostSharp and Metalama do not expose a network interface, and nothing in this review was exploitable remotely.

Every issue required the attacker to be in one of two positions:

• They already have access to the same machine as a different local user, which mainly matters on shared or multi-user build agents.
• They sit between your device and our postsharp.net or metalama.net servers as a man-in-the-middle.

Neither is reachable by a remote attacker against a normal developer or CI setup. “High” reflects the impact if an attacker is already local, not how easy you are to reach.

The published advisories:

• PostSharp: Local code execution, information disclosure, and denial of service in the build toolchain on shared machines (GHSA-gpwg-4q4j-792q)
• Metalama: Unsafe deserialization over the Visual Studio named pipe enables local code execution (GHSA-h26j-4vp7-x9w2)
• Metalama: Local code execution via DLL planting in world-writable temp directories on Linux/macOS (GHSA-m6wq-39m7-9xpp)

One assumption is unchanged: like the .NET SDK itself, PostSharp and Metalama assume your source code and NuGet dependencies are trusted, and they run that code at build time. This review hardened everything around that boundary, but it does not sandbox hostile source or malicious packages. Vetting what enters your build remains your job.

This is preventive maintenance, not an emergency. There is no known exploitation, and no customer needs to do anything beyond upgrading when convenient.

Why now, and not sooner

No attacker or customer reported these issues. We found and disclosed them ourselves, and published the advisories with the fixes already shipped on every supported branch.

Why now? Because a review of this depth was not practical until recently. Auditing a 20-year-old living codebase, every parser, every local server, every place data is collected or sent, used to mean weeks of specialist time. Claude Opus 4.8 did the complete review and proposed the fixes. We then reviewed every finding, corrected the fixes, and tested them on real VMs before release. The whole pass still took weeks; without the model it would not have happened.

Run the analysis yourself

You don’t have to take our word for any of this. Metalama is open source: clone it from GitHub and point your own tools at it. PostSharp’s source is available to enterprise customers at no additional charge under a source-available license, going back to version 1.0; see PostSharp Is Now Source Available.

If you run your own analysis, report any defects privately through GitHub Security Advisories (Metalama, PostSharp) and we will handle them the way we handled this review. Our security policy describes how we receive, prioritize, and disclose vulnerabilities.

What changed

Across all these releases, the work falls into a few themes:

• Better behavior on shared machines. Caches, temp files, and local servers now stay scoped to the current user, so one user cannot interfere with or read another’s build.
• Telemetry hardened to minimize what leaves your machine. Crash reports now omit exception messages and Exception.Data and do a more thorough job scrubbing both secrets and confidential identifiers, such as a company name embedded in a namespace, so a stack trace can’t carry a token, a connection string, or your internal names off your machine. We rotate device IDs monthly and keep separate salts for our own diagnostics and our third-party analytics, so the two are much harder to correlate. For exactly what we collect and how to turn it off, see our privacy policy.
• Removed features that collected data. We took out the in-product extras that came with a data cost: the Learning Hub tool window in Visual Studio, the Areas of Interest selection, and newsletter and email registration. We also removed the telemetry code for the defunct per-usage licensing model, which used to upload reversibly-hashed type names.
• Defense in depth against our own servers. Some data comes from postsharp.net or metalama.net, such as the news feed and content feeds. We replaced or hardened the parsers and serializers that handle it, so a compromise of our servers could not turn that data into code execution on your machine.

The LTS and latest branches (PostSharp 2024.0.24 and 2026.0.13, Metalama 2026.1.19, and the Visual Studio Tools 2026.1.5) get the full set of changes. The two Metalama advisory fixes were also backported to the other supported versions, 2025.1.18 and 2026.0.25, without the broader privacy and telemetry rework. See the version status page for what is still serviced.

The per-release notes have the full technical detail; the GitHub links above point to each one.

Updated policies

As part of this review we updated our privacy policy to describe exactly what we collect, and our security policy to reflect the current threat model and how to report a vulnerability.

How to upgrade

For most users this is a drop-in upgrade: bump the NuGet versions and update the extension. No API changes, nothing to reconfigure. Open-source and free-edition users can upgrade freely; for commercial editions, upgrading requires an active maintenance subscription. If you build on shared or multi-user agents, prioritize it.

What’s next

The next Metalama and PostSharp feature releases will focus on .NET 11 support, with work starting in late August.

Found an issue or have a feature request? Let us know on GitHub.

Happy meta-programming!

-gael