[Privacy] Exception-report scrubber is a weak denylist that leaks secrets/PII to the vendor #53

Disposition: Privacy / compliance — MSRC Moderate (no external attacker; CVSS does not apply) · Metalama analogue: metalama/Metalama#1679 / metalama/Metalama#1680

Affected code

• Core/PostSharp.Compiler.Settings/User/ExceptionSensitiveDataHelper.cs:13-29
• ExceptionXmlFormatter.WriteException:17-73 (serializes Message/Source/Data/StackTrace through it)
• default-on: Core/PostSharp.Compiler.Settings/User/UserSettings.cs:104 (ReportExceptions = true)

Description

The only scrubbing applied before exception reports are uploaded to PostSharp servers is two denylist regexes (dotted identifier → #user, backslash path → #path). Forward-slash Unix/macOS paths, connection strings, API tokens/JWTs, passwords-in-URIs, emails, IPs, and arbitrary Exception.Data/message content pass through unredacted. A SqlException carrying a connection string, or a custom exception with Data["Token"], ships verbatim to the vendor. This is the PostSharp analogue of Metalama metalama/Metalama#1679/metalama/Metalama#1680 (denylist vs allowlist).

Recommendation

Switch to an allowlist report: upload only known-safe fields (exception type, normalized/tokenized stack frames, the invariant hash); do not upload Exception.Message/Source/Data values by default; treat Exception.Data as opaque (allowlisted key names only). Honor the opt-out before assembling the report (see #56 → the opt-out child issue).

Backward compatibility

ExceptionSensitiveDataHelper and the report XML are internal (consumed only by PostSharp tooling) — the format can be tightened without a public-API break.

Part of #56.