DotNetNuke (DNN) Inadequate Encryption Strength Vulnerability (CVE-2018-15811)

What is affected, what to do

DNN (aka DotNetNuke) 9.2 through 9.2.1 uses a weak encryption algorithm to protect input parameters.

The vulnerability is being actively exploited; treat it as a priority. The available sources name no fixed version. Check the vendor guidance in the references below. Immediate actions, mitigation and detection rules are in the runbook below.

Affected

• Dnn.Platform lte 9.2..9.2.1

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Response and mitigation

1. 01

   Runbook step 1

   Immediate response (0-24 h)

   • Inventory: Find every DNN instance, including forgotten microsites and campaign pages. Check Settings > About or the file version of bin\DotNetNuke.dll. Affected versions are 9.2 through 9.2.1, including NuGet dotnetnuke.core 9.2.0, 9.2.0.366 and 9.2.1.533.
   • Upgrade: Move to the current vendor-supported DNN Platform release. A patch is available from the vendor — check the vendor advisory for the exact version. Do not settle for a release that only addresses CVE-2018-15811. This flaw is one link in the DNNPersonalization cookie deserialisation chain (CVE-2017-9822, CVE-2018-15812, CVE-2018-18325, CVE-2018-18326), and your target release must close all of them.
   • Isolate if delayed: If you cannot upgrade within 24 h, put the instance behind a WAF or reverse proxy, or restrict it to an IP allowlist. Prioritise sites with public user registration enabled.
   • Disable public registration: Set Settings > Security > User Registration = None. This removes an easy route for attackers to obtain encrypted material they can attack through the weak algorithm.
   • Rotate secrets after the upgrade: Regenerate the machineKey (validationKey/decryptionKey) in web.config. If the instance was exposed before patching, also rotate host/SuperUser passwords and database credentials.
   • Check for compromise: Sweep the webroot for new or modified .aspx, .ashx and .asmx files (webshells). Review the Users and UserPortals tables for unknown SuperUser accounts.
2. 02

   Runbook step 2

   Mitigation layers

   • Network segmentation: Host DNN in a DMZ zone with no direct path to internal networks. Apply default-deny egress on the IIS host so that post-deserialisation payload downloads and reverse shells fail.
   • WAF/IPS: Block requests where the Cookie header contains DNNPersonalization= with suspicious content. Patterns include ObjectDataProvider, ExpandedWrapper, System.Windows.Data, XamlReader, <profile> with type=, or unusually long Base64-like values. Alternatively, strip the cookie entirely at the reverse proxy for unauthenticated requests.
   • Configuration: Block the /Install/ wizard path via IIS Request Filtering. Review custom 404 handling, because the 404 path is a known entry point for the cookie chain.
   • Endpoint hardening: Run the IIS application pool under a dedicated low-privilege identity (ApplicationPoolIdentity, never LocalSystem). Use AppLocker/WDAC rules to stop w3wp.exe from launching cmd.exe, powershell.exe, certutil.exe or rundll32.exe.
   • IAM/least privilege: Limit the DNN database login to its own database (no sysadmin). Keep host accounts to a minimum and enforce MFA or SSO-fronted access for administrators.
3. 03

   Runbook step 3

   Detection rules

   • IIS logs: Enable logging of the cs(Cookie) field, which is off by default. Then hunt for cs(Cookie) containing DNNPersonalization AND (ObjectDataProvider OR ExpandedWrapper). Treat matches paired with 404 responses to random paths as especially suspicious.
   • Sysmon EID 1 / Security 4688 (process ancestry): Look for w3wp.exe spawning shells or LOLBins. KQL: DeviceProcessEvents | where InitiatingProcessFileName =~ "w3wp.exe" and FileName in~ ("cmd.exe","powershell.exe","certutil.exe","bitsadmin.exe")
   • Sysmon EID 11 (file creation): Look for new .aspx/.ashx files written by w3wp.exe under the DNN webroot or Portals\*. Sigma shape: Image|endswith: '\w3wp.exe' AND TargetFilename|endswith: ['.aspx','.ashx'].
   • Network telemetry (Zeek/Suricata): Watch for outbound connections from the web server to unfamiliar external hosts shortly after inbound requests carrying oversized cookies. Suricata idea: http.cookie; content:"DNNPersonalization"; content:"ObjectDataProvider"; nocase;
   • Application layer: Watch for bursts of new registrations followed by anomalous requests involving verification codes. Also flag new SuperUser rows in the DNN database and DNN EventLog entries outside maintenance windows.

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

Actively exploited: treat the vulnerability as a priority in vulnerability handling under Art. 21(2)(e) NIS2. If it is exploited in your environment, check the reporting obligation under Art. 23 (early warning within 24 hours).

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

Since 11.09.2026, manufacturers of affected products with digital elements must report actively exploited vulnerabilities under Art. 14 CRA, with an early warning within 24 hours via ENISA's single reporting platform.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

DNN (aka DotNetNuke) 9.2 through 9.2.1 uses a weak encryption algorithm to protect input parameters.

Source: NVD (NIST), OSV (Open Source Vulnerabilities), cvelistv5, CISA KEV Catalog

Vendors and products

• Dnnsoftware Dnn.Platform

Weakness classes (CWE)

• CWE-326Inadequate Encryption Strength

  Class

  The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.

  Entry at MITRE CWE-326

References & sources

• NVD (NIST)vuln/detail/CVE-2018-15811advisory
• github.comdnnsoftware/Dnn.Platform/releasesweb, x_refsource_MISC, Release notes
• cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2018-15811web, government-resource, US government resource
• dnnsoftware.comcommunity/security/security-centerweb, x_refsource_MISC, Vendor advisory
• packetstormsecurity.comfiles/157080/DotNetNuke-Cookie-Deserialization-Remote-Code-Exec…web, x_refsource_MISC, Exploit, Third-party advisory, Vulnerability database