CVE-2017-9822: DotNetNuke (DNN) Remote Code Execution Vulnerability

CVE-2017-9822 is a remote code execution vulnerability in DotNetNuke (DNN) that can be triggered through cookie deserialization. An attacker who can supply a crafted cookie may cause the application to execute code in the context of the web application, which can lead to full compromise of the site and the underlying host. CISA notes known ransomware use associated with this issue, so organizations still running DNN should treat it as a priority for inventory and remediation. Confirm all version and patch details against the vendor advisory.

How it works

The weakness is classified as CWE-20 (Improper Input Validation). In this case, DNN mishandles data supplied in cookies during deserialization. Deserialization turns a serialized object graph back into live objects; if the application does not adequately validate or restrict what can be deserialized, an attacker can embed unexpected object types or payloads that execute when the cookie is processed.

An unauthenticated or low-privilege attacker who can reach the vulnerable DNN instance sends a specially crafted cookie. The application deserializes it without sufficient checks, allowing the attacker’s payload to run with the privileges of the DNN process. Exact exploit mechanics and preconditions must be confirmed against the vendor advisory; defenders should assume remote code execution is possible once the cookie reaches the vulnerable code path.

Am I affected? How to find it in your systems

DotNetNuke (DNN) is a content-management and web-application platform commonly hosted on Windows/IIS environments, often used for public-facing sites, portals, and intranet applications. Inventory every web server and application pool that may host DNN:

• Search configuration management databases, software inventories, and IIS site bindings for DNN or DotNetNuke installations.
• Inspect web roots for DNN-specific folders, assemblies, and configuration files (for example, those referencing the DNN framework).
• Check installed product versions against the ranges listed in the vendor advisory for CVE-2017-9822; do not rely on informal version lists.
• Review whether the application accepts and deserializes cookies in the manner described by the advisory; any internet-facing or partner-facing DNN instance is higher risk.

For signs of exploitation, examine web-server and application logs for anomalous cookie values, unexpected deserialization errors, or sudden process creation and outbound connections originating from the DNN worker process. Correlate with endpoint detection alerts for unusual child processes of w3wp.exe or the DNN application pool identity. Absence of obvious log entries does not rule out compromise; treat any unpatched instance as potentially exposed.

How to remediate

Patch first. Apply the updates provided by the vendor exactly as described in the official advisory for CVE-2017-9822. CISA’s required action is to apply updates per vendor instructions. After patching, verify the installed version and restart application pools or services as directed.

Beyond the patch, harden the environment for this class of flaw:

• Ensure DNN and the underlying .NET runtime are kept current with vendor security releases.
• Restrict cookie handling and serialization settings where the product allows safer alternatives or type whitelisting.
• Run the application pool under a least-privilege identity and isolate it from other critical systems.
• Disable or remove unused DNN modules and features that expand the attack surface.

Re-scan or re-inventory after remediation to confirm no remaining vulnerable instances.

If you can't patch immediately

Implement compensating controls until the vendor update can be applied:

• Segment DNN hosts so they cannot reach sensitive internal networks or identity stores; limit outbound traffic to only what the application requires.
• Place a web application firewall or reverse-proxy rule set in front of the site to inspect and block suspicious cookie patterns associated with deserialization attacks; tune rules carefully to avoid breaking legitimate traffic and confirm coverage with the vendor or WAF provider.
• If the advisory or product documentation identifies a specific feature or cookie-handling path that can be disabled without breaking critical function, turn it off.
• Increase monitoring: alert on anomalous cookies, deserialization exceptions, new processes spawned by the DNN identity, and unexpected file-system or registry changes under the web root.
• Consider temporary removal from the internet or restriction to trusted networks if business impact allows.

These measures reduce risk but do not replace the patch. Schedule the official update as soon as possible.

If your data may have been exposed

Actively exploited vulnerabilities, including those with known ransomware use, frequently lead to web-shell deployment, data theft, or further lateral movement. If you discover an unpatched or compromised DNN instance, follow your incident-response process: isolate the host, preserve logs and memory, and assess whether credentials, customer data, or other sensitive information were accessible to the application. As a quick additional check, you can run a free exposure scan of your email addresses against known breach data sets to see whether associated accounts have appeared in prior breaches.