Summary

Multiple weaknesses in the PostSharp build toolchain allow an unprivileged local user on a shared or multi-user machine (including a shared CI/build agent) to compromise other users' builds. Depending on the weakness, an attacker can achieve arbitrary code execution in the context of a victim's build, disclose sensitive information handed to or produced by the build (including license keys and environment details), or render the build capability unavailable. This advisory bundles four related local-machine findings (A–D) that share the same root-cause class: build-time resources placed in shared, predictable, or weakly permissioned locations without adequate access control, authentication, or integrity verification.

All four findings require local access to the same machine as the victim. None is remotely exploitable on its own.

Severity

Overall: High — CVSS v3.1 8.2
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

The overall severity is governed by the most severe component (Finding A); the lower-severity components do not reduce the aggregate rating.

Affected product and versions

• Product: PostSharp build toolchain (distributed via the PostSharp NuGet package and its bundled build and compiler-host tools).
• Affected versions:
  • All PostSharp 2024.0 releases prior to 2024.0.24.
  • All PostSharp 2026.0 releases prior to 2026.0.13.
  • In effect, every PostSharp version is affected except the patched releases listed below.

Patched versions

The fix ships in two maintenance lines, released separately:

• 2024.0.24 (2024.0 line)
• 2026.0.13 (2026.0 line)

No other release line will receive this fix. Customers on any other line should upgrade to one of the patched versions above.

Description

PostSharp's build toolchain stages and exchanges several kinds of build-time resources — loadable compiler-host components, restored dependencies, precompiled native images, an inter-process build server, a machine-wide build throttle, and diagnostic output. In affected versions, these resources were placed in shared, predictable, or world-accessible locations and were trusted without sufficient access control, peer authentication, or integrity verification. On a single-user, properly isolated machine this is not exploitable by a remote party. On a machine shared by multiple users — or on a shared CI/build agent where untrusted jobs run under the same account or on the same host — another local user can interpose on these resources to attack a victim's build.

The four findings are:

• A — Arbitrary code execution via untrusted shared resource locations (DLL planting / missing integrity check). Loadable build components, restored dependency assemblies, and precompiled native images were consumed from shared, predictable locations using a freshness check based only on presence and timestamp, with no cryptographic or signature-based integrity verification. Where those locations were writable by other local users, an attacker could plant a malicious component that the victim's next build would load and execute.

• B — Arbitrary code execution and sensitive-data disclosure via the .NET Framework inter-process build server (Windows). The .NET Framework inter-process build server runs by default for attended (interactive) builds on Windows, and can also be enabled for unattended or CI builds via an opt-in setting. In affected versions, the inter-process build channel was created with overly broad access permissions and a predictable identity, and accepted build requests without authenticating the connecting peer. A local attacker could either drive the build host into loading and executing attacker-supplied code, or stand up a look-alike server under the predictable identity to capture data submitted by the victim's build (including license keys) and return forged results.

• C — Local denial of service via an unscoped build-throttle synchronization object. A machine-wide synchronization object used to limit CPU usage across PostSharp builds was created with a fixed, unscoped identity and permissions that let any local user manipulate it. An attacker could hold or exhaust it so that subsequent PostSharp builds on the machine block indefinitely.

• D — Local information disclosure via an unscrubbed exception report. On certain build-host errors, a full, unredacted exception report (including message text, nested exceptions, and a stack trace containing absolute paths) was written to a plaintext file in a temporary directory and left in place, without the redaction applied to other diagnostic output. A local user able to read that directory could recover usernames, source-tree layout, internal host names, and any sensitive data present in the exception text.

Attack vector and preconditions

All findings require local access to the victim's machine and are limited to shared or multi-user environments. They are not exploitable by a remote, unauthenticated attacker and do not apply to a properly isolated single-user workstation.

• A: A shared or insufficiently isolated build environment in which the default resource locations are writable by other local users, and a victim subsequently runs a PostSharp build. (User interaction required: the victim runs a build.)
• B: Windows; the .NET Framework inter-process build server, which runs by default for attended (interactive) builds and can also be enabled for unattended or CI builds via an opt-in setting; on a shared or multi-user host. Higher attack complexity (timing/positioning relative to the victim's build is required).
• C: Any shared host on which an arbitrary local user can execute code.
• D: A shared or world-readable temporary directory; a non-default or misconfigured environment increases the likelihood that the report is readable by another user.

Impact

• Confidentiality: Disclosure of license keys, environment and host details, source-tree structure, and other data present in build inputs, build outputs, or diagnostic reports (Findings A, B, D).
• Integrity: Execution of attacker-controlled code in the context of the user running the build, and forged build results returned to the victim (Findings A, B).
• Availability: Indefinite blocking of all PostSharp builds on the affected machine (Finding C); and, via code execution, arbitrary disruption of build availability (Finding A).

Remediation

Upgrade to PostSharp 2024.0.24 or 2026.0.13 (or a later release in those lines). The release hardens the build toolchain as follows:

• Shared build resources are confined to per-user, access-controlled locations and are verified for integrity before being loaded or executed, rather than being trusted on presence and timestamp alone.
• The .NET Framework inter-process build server now uses a non-predictable identity, restricts access to the owning user, and authenticates the connecting peer before honoring build requests.
• The machine-wide build-throttle synchronization object is scoped per user and restricted so that other local users cannot manipulate it.
• Diagnostic and exception output written to temporary locations is now redacted consistently and is not retained where it could be read by other users.

Until upgrade is possible, mitigate by running PostSharp builds only on properly isolated, single-user machines; ensuring temporary and cache directories are not shared or world-readable; and avoiding shared CI/build agents that run untrusted jobs under the same account or host as trusted builds.

Affected components