Context
Build/Tools/PostSharp.Distribution.Unzipper uses SharpCompress for extracting PostSharp-Tools.7z on customer machines at first PostSharp build. This assembly ships inside the PostSharp NuGet package under build/_common/unzipper/.
Problem
CVE-2026-44788 (path traversal in WriteToDirectory) affects all SharpCompress versions through 0.48.1. No patched version exists.
There is no actual exploit possible in PostSharp's usage:
- The CVE targets the
IArchive.WriteToDirectory() API. PostSharp's unzipper does not call that API.
- The unzipper manually iterates entries via
MoveToNextEntry() and writes to explicit file streams via WriteEntryTo(destStream).
- The archive (
PostSharp-Tools.7z) is created by PostSharp's own build, signed with Authenticode, and shipped inside a signed NuGet package.
However, customer security scanners might flag SharpCompress as a vulnerable transitive dependency regardless of actual exploitability.
Current mitigation
NU1902 is suppressed in the unzipper's csproj so the warning doesn't appear in our build output. The SharpCompress dependency still ships to customers and will be flagged by their scanners.
Proposed solution
Replace the 7z archive format with one that can be extracted using only built-in .NET APIs, eliminating the SharpCompress dependency entirely. Options evaluated:
| Approach |
Compression |
Dependencies |
Notes |
| tar.gz |
~30-40% worse than LZMA |
Zero (GZipStream built-in) |
Simplest. Tar reader is trivial for net472; System.Formats.Tar available for net6.0+. |
| tar + Brotli |
Close to LZMA on net6.0 |
Zero (BrotliStream built-in on .NET Core 2.1+) |
Better compression than gzip. Needs gzip fallback on net472. |
| Embed LZMA SDK |
Same as current 7z |
Zero NuGet deps (vendored code) |
Best compression. Use tar.lzma format. More code to maintain. |
Key constraint: the archive contains many near-identical assemblies, so solid-archive compression (tar-based) is important — zip's per-entry compression would be significantly worse.
Files involved
Build/Tools/PostSharp.Distribution.Unzipper/ — the unzipper tool (rewrite to use built-in APIs)
Build/Distribution/NuGet.proj — creates PostSharp-Tools.7z (change to new format)
Core/PostSharp.MSBuild/BuildToolsHelper.cs — invokes the unzipper (update archive filename)
Context
Build/Tools/PostSharp.Distribution.Unzipperuses SharpCompress for extractingPostSharp-Tools.7zon customer machines at first PostSharp build. This assembly ships inside the PostSharp NuGet package underbuild/_common/unzipper/.Problem
CVE-2026-44788 (path traversal in
WriteToDirectory) affects all SharpCompress versions through 0.48.1. No patched version exists.There is no actual exploit possible in PostSharp's usage:
IArchive.WriteToDirectory()API. PostSharp's unzipper does not call that API.MoveToNextEntry()and writes to explicit file streams viaWriteEntryTo(destStream).PostSharp-Tools.7z) is created by PostSharp's own build, signed with Authenticode, and shipped inside a signed NuGet package.However, customer security scanners might flag SharpCompress as a vulnerable transitive dependency regardless of actual exploitability.
Current mitigation
NU1902 is suppressed in the unzipper's csproj so the warning doesn't appear in our build output. The SharpCompress dependency still ships to customers and will be flagged by their scanners.
Proposed solution
Replace the 7z archive format with one that can be extracted using only built-in .NET APIs, eliminating the SharpCompress dependency entirely. Options evaluated:
System.Formats.Taravailable for net6.0+.Key constraint: the archive contains many near-identical assemblies, so solid-archive compression (tar-based) is important — zip's per-entry compression would be significantly worse.
Files involved
Build/Tools/PostSharp.Distribution.Unzipper/— the unzipper tool (rewrite to use built-in APIs)Build/Distribution/NuGet.proj— createsPostSharp-Tools.7z(change to new format)Core/PostSharp.MSBuild/BuildToolsHelper.cs— invokes the unzipper (update archive filename)