Is CVE-2017-9822 (DotNetNuke (DNN) Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2017-9822 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. DotNetNuke (DNN) contains a vulnerability that may allow for remote code execution via cookie deserialization. Any organisation running the affected product should treat remediation as urgent.

What active exploitation means for CVE-2017-9822

For a vulnerability like CVE-2017-9822, the key issue is not simply that a flaw exists, but that it has crossed from theoretical exposure into observed attacker use. Once a product weakness appears in CISA’s Known Exploited Vulnerabilities catalogue, the operational assumption changes: exposed systems should be treated as a live target, not a routine maintenance item.

That matters because active exploitation usually compresses the time available to respond. Even if an organisation has not seen alerts yet, the relevant question is whether the product is still present, reachable, and able to receive malicious input in the vulnerable path.

For background on how to triage these cases, the Zero-Day and Exploited Vulnerabilities Guide covers the practical difference between disclosure, exploitation, and emergency response.

The vulnerability type here is a remote code execution path through cookie deserialization. In practical terms, that means attacker-controlled data is being converted into application objects in a way that can trigger unintended behaviour, including code execution, if validation and trust boundaries are weak enough.

The important practitioner lesson is that deserialization bugs are rarely isolated coding mistakes. They often become full-system compromise paths because the application treats untrusted state as if it were internal state. When that happens, the attacker does not need a separate privilege escalation step if the flawed code path already runs in a powerful application context.

This failure pattern is discussed in the Insecure Deserialisation Guide, which is useful for understanding why object handling defects so often become execution issues.

What to check first before you assume you are safe

Start by confirming whether any internet-facing or internally reachable DNN instance still exists in your environment, including forgotten test systems, legacy portals, and outsourced hosting. Then verify whether the vulnerable feature path is actually enabled or reachable in the deployed configuration, because dormant software is lower risk than software that still processes external requests.

If the product is present, treat exposure assessment as a combination of inventory, patch state, and compromise checking. Active exploitation means you should not stop at version confirmation alone. You also need to review logs, web requests, unusual process creation, and any signs that the application began behaving differently around the period of exposure.

The Vulnerability Management Guide is a good reference for scoping, prioritisation, and post-remediation verification when exploitation is already known or suspected.

Risk and Threat Considerations

When a remotely exploitable flaw is already being used in the wild, the threat is no longer limited to opportunistic scanning. Attackers tend to target such weaknesses because they offer a direct path to application execution, and once initial code execution is obtained they can often pivot to credential theft, web shell deployment, or further internal access.

Failure mechanism: Untrusted cookie content is deserialized into application logic, allowing crafted input to trigger attacker-chosen behaviour and potentially run code in the application’s security context.

Impact: Successful exploitation can lead to full application compromise, data exposure, persistence, and follow-on abuse of the server or adjacent systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes continuous vulnerability tracking and remediation central.
Recommendation — Prioritise and remediate KEV-listed systems immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This is a live software flaw requiring urgent remediation and verification.
	AU-6 — Audit Record Review, Analysis, and Reporting	Compromise checks depend on reviewing logs for exploitation indicators.
Recommendation — Patch or mitigate the vulnerable DNN deployment without delay. Review audit and web logs for signs of post-exploitation activity.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Managed	The question is about a known exploited vulnerability and exposure confirmation.
	RS.MA-02 — Incidents Are Documented and Analyzed	Known exploitation requires analysis of possible compromise and incident evidence.
Recommendation — Inventory DNN assets and manage the exposed vulnerability as a current risk. Document exploitation indicators and analyze whether the host was compromised.

Practitioner Guidance

What to prioritise: Treat confirmed exploitation as a containment problem, not just a patching task. Remove or isolate exposed instances first if immediate remediation is not possible, then validate whether any credentials, session material, or hosted secrets could have been reachable from the application context.

What to verify: Check whether the vulnerable host showed signs of post-exploitation activity, including new files, unexpected child processes, suspicious outbound connections, and changes to application configuration or scheduled tasks. If you cannot prove the system stayed clean, assume possible compromise and investigate accordingly.

Practitioner takeaway: For a KEV-listed RCE, the safest operating assumption is that exposure may already equal compromise, so response should combine remediation, log review, and blast-radius assessment in one workflow.