Please report security vulnerabilities via GitHub Security Advisory. Do not open a public issue.

uContract.NET is a Design by Contract utility library with a deliberately narrow attack surface. The following list distinguishes what the maintainer will treat as a security issue from what is out of scope. Edge cases not listed here are welcome as a question on the advisory channel.

• Deserialization behavior in Contract.Old<T>(), which uses System.Text.Json to produce deep copies. Crafted input types or JSON payloads that cause the library's own serialize / deserialize code path to behave unsafely (e.g., unexpected exception leakage, resource exhaustion amplified by library-internal choices) are in scope.
• Reflection-based member enumeration in Contract.EnsureAssignable<T>(). If crafted types could cause the library to read members in a way that violates reasonable expectations (e.g., accessing members the caller could not themselves access), that is in scope.
• Environment variable parsing in ContractConfiguration. Parsing bugs that could be triggered by crafted environment values and affect library behavior beyond the documented on/off toggles are in scope.
• Exception message content generated by the library, if that content unexpectedly discloses information beyond what the caller explicitly passed as the description.

• User-supplied lambdas. Contract.Require(() => SomeDangerousCall()) evaluates whatever lambda the caller wrote; the lambda body is the caller's code, not the library's. Side effects, slow conditions, or resource usage inside a user-supplied lambda are out of scope.
• Intentional contract bypass via documented environment variables. Setting DBC=off or the per-category toggles disables contract enforcement by design (see ADR-0004). Contracts are a correctness aid, not a security control; relying on them to enforce a security boundary is a design error in the calling code.
• Bugs in the caller's own types passed to Old<T>() (e.g., a caller type whose serialization path throws or behaves unexpectedly) — that is a caller bug, not a library issue.
• Expected *ViolationException types thrown on contract violations. These are the library's correctness signal and not a fault.
• Denial of service via expensive user conditions. A slow lambda is the caller's concern; the library's evaluation harness is a thin wrapper.