Review every installed non-core, third-party, commercial, community, and custom DNN module for unauthenticated controllers, ASHX handlers, ASMX services, and dangerous capabilities that may never receive a public CVE or vendor advisory.
Not rated yet
A DNN site is not only the DNN core. Every installed extension can add controllers, Web API
routes, .ashx handlers, .asmx services, upload workflows and database operations. Every module
assembly outside the running DNN core therefore needs review—commercial, community, custom or
internal, inherited from an earlier team, recently upgraded, or no longer supported. Publisher
reputation and a current DNN core version do not validate an extension's authorization logic.
These endpoints may never appear in a public security advisory. A vendor may not know about the
defect, may fix it without assigning a CVE, or may no longer maintain the product. Attackers do not
need public disclosure before exploiting a reachable anonymous upload, command-execution, data-
deletion, or private-network access path. DNN Defender therefore inspects what is actually
installed on the site instead of waiting for a module name to appear in a vulnerability feed.
Actual module screen: the API Security Scanner inventories locally installed endpoints and separates route, authorization, capability, confidence, and severity. Counts in this screenshot are site-specific and do not represent current production findings.
DNN Defender applies the same analysis on supported DNN 9.x and DNN 10.x installations. DNN 9 is
not a special priority class: the scope is every installed non-core module on every supported DNN
generation. The scanner reads .NET metadata and reachable IL without loading or executing the
target DLL in the DNN worker process. It reconstructs the endpoint surface and evaluates:
- controller, action, ASHX and ASMX entry points;
- route prefixes, service folders and HTTP verbs;
AllowAnonymous, authorization filters, DNN role/permission checks and anti-forgery guards;- file upload/write/delete behavior;
- database read, mutation and deletion capability;
- process execution, dynamic assembly loading, reflection and command-launch primitives;
- outbound network and private-network access;
- whether a declared guard is actually reachable before the sensitive operation.
This is not filename matching and it is not a list of method names. Severity combines anonymous
reachability, the verb and route, reachable authorization evidence, and the capability reachable
from the endpoint. A method named Delete is not automatically a vulnerability; an anonymously
reachable DELETE endpoint with a reachable data-deletion path is.
The same evidence rule applies to upload and execution. A static upload candidate requires route
and guard validation. Once anonymous access and the ability to place server-executable content in
a web-executable location are confirmed, the condition is exploitable and Critical; it is no
longer a hypothetical warning. A confirmed unauthenticated command, process, or dynamic-code path
is likewise an RCE condition. DNN Defender never needs to leave a working shell on the production
site to establish that boundary.
Why hosting antivirus and firewalls do not provide this result
Hosting antivirus is valuable for known malware, suspicious binaries and filesystem behavior.
A network firewall is valuable for ports, addresses and network policy. A generic WAF is valuable
for common malicious request patterns. None of those controls normally disassembles every DNN
module DLL, reconstructs DNN/Web API/ASHX/ASMX routes, follows authorization guards and then maps
the endpoint to file, database, process or network capability.
That DNN-aware code-to-route authorization map is the difference. It finds application-layer
exposure created by third-party modules even when the request uses normal HTTPS, the DLL is
legitimately signed, the file has no malware signature and the vulnerable behavior is specific to
the module's own business logic.
Mandatory review of every non-core module
The review requirement comes from installed code, not from the DNN version number:
| Installed module source |
Why it must be reviewed |
| Commercial or marketplace module |
A valid license, signature, or reputation does not prove that every route enforces authorization before a sensitive operation |
| Community/open-source module |
Public source improves reviewability but does not guarantee that a deployment uses a fixed build or safe configuration |
| Custom or internal module |
Its endpoints are usually outside public CVE, hosting AV, and generic WAF knowledge |
| Legacy or discontinued module |
Security reporting, maintenance, and coordinated disclosure may no longer exist |
| Recently installed or upgraded module |
New routes and changed guards can alter the site's attack surface even when the DNN core is unchanged |
Do not wait for a CVE, a vendor bulletin, an antivirus signature, or evidence of compromise before
running this review. Run it after initial installation, after every module install or upgrade,
after route/permission changes, and as part of the regular security assessment. The result is an
inventory of the actual application attack surface installed on that site—not a generic checklist
copied from the DNN version number.
Static analysis can identify an urgent candidate without proving that the inferred route is live
on a particular portal. The follow-on bounded validation distinguishes route not verified,
guarded, anonymous reachable, input rejected, and inconclusive; the protection column then
states separately whether DNN Defender is blocking, monitoring only, or requires a module fix.
See From endpoint candidate to confirmed exploit path and Protecting vulnerable module endpoints.