Security and Privacy Update for PostSharp and Metalama
Today we are shipping a coordinated security and privacy update across every supported branch of PostSharp and Metalama. It covers the build toolchain, the design-time services, telemetry, and the Visual Studio Tools. It does not change the public API or how you write aspects.
This article was first published on the Metalama Blog.
In short: All fixes are already shipped on every supported branch. The most serious issues (three High-severity advisories) require an attacker to already have a local account on your machine, so they mainly affect shared or multi-user build agents. Upgrade when convenient; prioritize it if you build on shared agents. Nothing else to do.
Scope and attack vectors
We published GitHub Security Advisories for the most severe findings, all rated High. They require the attacker to already have local access to the same machine, under a different user account, which mainly matters on shared or multi-user build agents.
- 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)
- Local code execution via DLL planting in world-writable temp directories on Linux/macOS (GHSA-m6wq-39m7-9xpp)
We found and fixed other vulnerabilities that required the attacker to sit between your device and our postsharp.net or metalama.net servers as a man-in-the-middle. See the GitHub release notes in the What changed section below.
None of these vulnerabilities could be exploited by a remote attacker against a normal developer or CI setup.
One assumption is unchanged: like the .NET SDK itself, PostSharp and Metalama assume your source code and NuGet dependencies are trusted, and they execute 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.
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 the new generation of AI models makes it both possible and urgent. Auditing a 20-year-old living codebase used to mean weeks of work and skills we didn’t have in-house. It did not seem necessary for a niche tool that processes trusted local inputs without network access. However, with new AI tools, an in-depth security analysis takes a couple of hours – both for the publisher and the attacker. We used Claude Opus 4.8 for the review, reviewed every finding, supervised and refined 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
We believe that security stems from transparency. Ultimately, it does not matter who wrote the code you execute. What matters is the code itself.
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:
- Safer 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 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 long-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 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 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:
- PostSharp:
- Metalama:
- Visual Studio Tools for PostSharp and Metalama:
All packages are on NuGet.org, and the extension is on the Visual Studio Marketplace.
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