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.

• Copy behavior in Contract.Old<T>(), which copies objects field by field with reflection. Crafted input types or object graphs that cause the library's own copy code path to behave unsafely (e.g., running user code during the copy, 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 that holds state that cannot be copied meaningfully) — 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.