From endpoint candidate to confirmed exploit path

DNN Defender uses progressively stronger evidence. The administrator should not have to guess whether a red label came from a name, a real route or a verified security boundary.

Evidence levels

1. Static candidate: metadata and IL prove that an endpoint declaration and a sensitive capability exist, but the exact portal route or runtime guard has not yet been confirmed.
2. Route confirmed: a bounded anonymous request reaches the mapped endpoint on the current portal. HTTP 401/403 confirms a runtime guard; HTTP 404 means the route was not confirmed on that portal; HTTP 5xx is inconclusive and must be matched to the DNN Event Log.
3. Anonymous operation confirmed: the live endpoint accepts the relevant safe request without a DNN credential. For upload validation, DNN Defender uses a uniquely named inert .txt canary, never an executable shell.
4. Exploitable upload/RCE path confirmed: an anonymous endpoint permits server-executable content to be placed in a web-executable location, or exposes a reachable process/command/ dynamic-code execution primitive. This is a Critical, exploitable condition—not merely a suspicious possibility. An attacker does not need a second vulnerability once that path is available.
5. Anonymous destructive access confirmed: an unauthenticated request can alter or delete legitimate application data. This is an exploitable authorization failure with direct integrity impact.

Safe production validation deliberately stops before creating an executable ASPX file, executing a command or deleting a real record. That safety boundary does not weaken the conclusion when the route, missing authorization and reachable dangerous capability are already proven. Security testing does not need to leave a live web shell behind to demonstrate that an anonymous executable upload path is exploitable.

Automatic validation after scanning

After a fresh scan, eligible Medium/High/Critical findings are automatically checked with bounded, credential-free requests. Destructive verbs, inferred routes and executable payloads are never auto-submitted. The finding records the probe ID, HTTP outcome and the exact reason for its status, so route not verified, guarded, anonymous reachable, input rejected and inconclusive are not mixed together.

The severity displayed to an administrator must follow the strongest evidence. A static candidate can require urgent review, but only confirmed reachability/capability evidence should be described as a confirmed exploitable endpoint.