CVE-2017-9822

What Is DotNetNuke (DNN)?

DotNetNuke (DNN) is an open-source content management system built on ASP.NET that powers tens of thousands of websites across government, education, healthcare, and commercial sectors. DNN stores per-user personalization data (portal settings, module preferences) as a serialized binary object in the DNNPersonalization cookie. CVE-2017-9822 exploits this cookie: DNN uses .NET's BinaryFormatter to deserialize the cookie value without validation — an authenticated attacker with any account (even a basic registered user) can replace the cookie with a crafted .NET deserialization gadget chain and achieve remote code execution as the IIS application pool identity.

Overview

CVE-2017-9822 is a code injection vulnerability (CWE-94) via .NET cookie deserialization in DotNetNuke. When DNN processes the DNNPersonalization cookie, it deserializes the cookie value using .NET BinaryFormatter — a notoriously unsafe serialization format that can instantiate arbitrary .NET types and execute code via gadget chains. Any authenticated user (low-privilege — PR:L) can submit a crafted cookie to achieve server-side code execution. CVE-2017-9822 has been used in ransomware attacks. Fixed in DNN Platform 9.1.1 (July 2017). CISA added CVE-2017-9822 to the KEV catalog in November 2021.

Affected Versions

Technical Details

Root Cause: BinaryFormatter Deserialization of User-Controlled Cookie

CVE-2017-9822 is a .NET deserialization vulnerability (categorized as CWE-94) in DNN's personalization data handling. The DNNPersonalization cookie stores a base64-encoded, BinaryFormatter-serialized object graph representing a user's portal preferences. When a request arrives, DNN deserializes this cookie using BinaryFormatter.Deserialize() without validating the type or content of the deserialized object.

.NET BinaryFormatter gadget chains: The .NET BinaryFormatter allows specifying arbitrary types by assembly-qualified name in the serialized stream. Attackers use pre-constructed "gadget chains" — sequences of commonly available .NET framework classes whose constructors or methods execute code when instantiated during deserialization. Tools like ysoserial.net generate ready-to-use BinaryFormatter payloads targeting .NET gadget chains.

Low privilege requirement: Any account registered on the DNN portal — even a guest or community member with no administrative capabilities — can set the DNNPersonalization cookie and trigger deserialization.

Attack Characteristics

Discovery

Reported to DNN Software's security team; patched in DNN Platform 9.1.1 released July 7, 2017 and disclosed as a security advisory.

Exploitation Context

• Ransomware use confirmed: CVE-2017-9822 has been used in ransomware attacks against organizations running unpatched DNN installations — threat actors register a low-privilege account, exploit the deserialization, and deploy ransomware or cryptominers via the resulting code execution
• Wide government and education deployment: DNN is popular in government agencies, universities, and nonprofits — communities that may lag in patching CMS platforms; this deployment profile makes CVE-2017-9822 attractive for targeted campaigns
• .NET deserialization class: BinaryFormatter deserialization vulnerabilities were an active area of exploitation research in 2016–2018; DNN joined a long list of .NET applications affected by this class including SharePoint, Exchange, and various CMS platforms
• CISA KEV (2021): Added November 3, 2021 as part of the initial KEV catalog launch; the ransomware connection reflects continued exploitation well after the 2017 patch

Remediation

1. Upgrade to DNN Platform 9.1.1 or later — the patch replaces the insecure BinaryFormatter deserialization with a safe alternative; upgrade immediately for all internet-accessible DNN installations.

2. Review DNN instance for indicators of compromise — if running unpatched DNN, audit IIS logs for unusual POST requests with large DNNPersonalization cookie values; check for new files created in the web root (web shells) and unexpected scheduled tasks or user accounts.

3. Require authentication for sensitive DNN instances — if the DNN portal does not require public user registration, disable self-registration to eliminate the low-privilege attacker account vector.

4. Apply defense-in-depth on IIS — run the DNN application pool under a least-privilege identity; restrict the IIS account from writing to the filesystem or executing shell commands using AppLocker or Windows file ACLs.

5. Keep DNN updated — DNN has had multiple security vulnerabilities over the years; establish a regular patching cadence for CMS platforms and include them in vulnerability scanning programs.