Executive Summary:

CVE-2025-64095 is a critical vulnerability in DNN (formerly DotNetNuke), an open-source web content management system (CMS) built on the Microsoft .NET ecosystem. This flaw resides in the default HTML editor provider, specifically the CKEditor integration, allowing unauthenticated attackers to upload arbitrary files and overwrite existing ones in the server's default directory. Successful exploitation can lead to severe consequences, including website defacement, injection of malicious cross-site scripting (XSS) payloads, and potential remote code execution (RCE) when combined with other misconfigurations.

Key Findings:

Unauthenticated Access: The CKEditor file upload handler (FileUploader.ashx) processes requests without verifying user authentication or session state, allowing anonymous file uploads and overwrites.

Arbitrary File Manipulation: Attackers can target the Portals/_default/ directory, replacing critical assets like images, scripts, or HTML files.

High Impact Potential: Enables defacement and XSS; combinable with other flaws (e.g., CVE-2025-62368) for RCE.

Affected Scope: All unpatched DNN installations using the default DNNConnect.CKE provider, potentially thousands of public-facing sites.

Patch Availability: DNN 10.1.1 introduces authentication checks and disables guest uploads.

Exploitability: Proof-of-concept exists; no known in-the-wild exploitation, but recent disclosure heightens urgency.

Vulnerability Overview:

DNN Platform is a widely adopted .NET-based CMS supporting multi-tenant websites, intranets, and e-commerce portals. Its HTML Editor module integrates CKEditor for rich text editing, including file uploads for images and media. The vulnerability resides in the Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx endpoint, a custom ASP.NET handler for CKEditor uploads.

This flaw allows remote, unauthenticated users to:

• Upload arbitrary files (e.g., images, scripts) to portal directories.
• Overwrite existing files if the OverrideFile parameter is set to true.

Exploitation requires only HTTP access to the endpoint, making it trivial for attackers scanning public DNN instances. The National Vulnerability Database (NVD) classifies it as critical due to its network accessibility, low attack complexity, and high integrity impact.

Attribute	Details
CVE ID	CVE-2025-64095
Title	Unauthenticated Arbitrary File Upload in DNN HTML Editor Provider (Image Upload Allows Site Content Overwrite)
Severity	Critical (CVSS 3.1: 10.0) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected Products	DNN Platform (DotNetNuke), an open-source .NET-based web content management system (CMS) using the default HTML editor provider with CKEditor integration
Affected Versions	DNN Platform — affected versions include: • DNN 10.0: >= 10.0.0 and <= 10.0.0 • DNN 9.x: All versions >= 9.0.0 and < 10.1.1
Vendor	DNN Software
CWE	CWE-434: Unrestricted Upload of File with Dangerous Type
Disclosure Date	October 28, 2025
Privilege Required	None (PR:N) - Unauthenticated remote attacker can exploit
Scope Change	No (S:U) - Attack is confined to the affected component's security scope

 

Vulnerability Details:

The vulnerable component is part of the DNNConnect.CKE provider, a community extension for CKEditor 4.x integration in DNN. Key technical elements include:

• Endpoint: /Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx
• Request Type: POST with multipart/form-data payload.
• Processed Parameters:
• file: The uploaded binary (no MIME type enforcement beyond basic checks).
• storageFolderId: Target folder ID (defaults to 0 for root).
• PortalId: Multi-tenant portal identifier (defaults to 0).
• OverrideFile: Boolean flag for overwriting existing files.
• Affected Versions: DNN 9.x and 10.0.x (pre-10.1.1).
• Dependencies: Relies on ASP.NET's HttpPostedFile for handling; no input sanitization for file paths or contents.

Code inspection (via decompilation tools like ILSpy) reveals superficial validations (e.g., file size, emptiness) but no RBAC enforcement. Screenshots from analysis (as provided in the original POC document) illustrate:

• Lack of IsAuthenticated checks in ProcessRequest.
• Unverified user ID retrieval in UploadFile.
• Direct file system writes via SaveAs without permission guards.

Root Cause:

The root cause is a failure to implement proper authorization in the upload handler. Specifically:

• Missing Authentication Guard: The ProcessRequest method parses multipart data without invoking DNN's PortalSecurity or UserController to validate the requester's identity. In unauthenticated contexts, HttpContext.Current.User defaults to an anonymous user, granting unintended write access.
• Inadequate Overwrite Logic: The overrideFiles mechanism uses File.Delete and SaveAs directly on the file system path, bypassing DNN's file management APIs (e.g., IFileManager). This exposes the Portals/ directory to tampering.
• Design Flaw in Provider: The DNNConnect.CKE extension assumes uploads occur within authenticated editor sessions, a common oversight in legacy CMS plugins.

Exploitation Flow:

Figure: Attack flow showing how the CVE is exploited.

Exposure & Risk:

Impact Unauthenticated arbitrary file upload enabling website defacement, stored XSS injection, and file system tampering; potential escalation to remote code execution (RCE) when chained with misconfigurations or other DNN flaws (e.g., CVE-2025-62368).

Stealth Factor The exploit masquerades as legitimate CKEditor media uploads within standard multipart/form-data POST requests, evading basic WAF rules and logging filters focused on anomalous payloads rather than auth-bypassing patterns.

Attack Scenarios

• Defacement via overwrite of portal assets (e.g., replacing logo.png in Portals/_default/ with tampered content visible site-wide).
• XSS payload injection by embedding scripts in uploaded images, triggering on admin/editor interactions for session hijacking or phishing.
• Multi-tenant pollution: Targeting PortalId manipulation to upload malware across isolated portals, compromising shared hosting environments.
• Escalation to RCE: Uploading disguised server-side scripts (e.g., .aspx as .png) to exploitable endpoints, enabling persistent backdoors in CI/CD-integrated DNN deployments

POC & Active Exploitation: CVE-2025-64095

Vulnerability Mechanism

This POC allows an unauthenticated user to upload or overwrite existing files in the web server's default directory. DNN (DotNetNuke) is an open-source web content management system within the Microsoft ecosystem that is affected by this vulnerability. Exploiting this flaw can lead to website defacement or other severe impacts, such as injecting malicious XSS payloads.

The vulnerability originates from a specific file located at: Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx

This file is part of the CKEditor functionality, which is integrated through the HTML Editor management module. CKEditor is a popular rich text editor that provides multiple features, such as image uploads and text formatting. It is widely used by development teams across various content management systems (CMS) like Drupal and WordPress.

Authentication Bypass in ProcessRequest

When we inspect the class that implements the file upload handler and open FileUploader.ashx to examine its ProcessRequest method, we find it accepts and processes uploads without enforcing authentication or checking session state. The method immediately begins parsing the multipart form data without invoking any of DNN's built-in security mechanisms such as PortalSecurity.IsInRole() or UserController.ValidateUser().

The ProcessRequest method operates under the assumption that requests arriving at this endpoint have already been validated by upstream authentication middleware. However, the ASP.NET handler is registered as a public endpoint with no declarative security attributes. When an unauthenticated request arrives, the HttpContext.Current.User property returns a generic principal with an anonymous identity, yet the code proceeds to process the upload request as if this were a valid, authenticated session.

File Upload Processing Without Authorization

This is the UploadFile main function, which is responsible for processing and validating the uploaded file. It correctly performs several logical checks, such as verifying whether the file is empty, validating the file size, and handling other core functionalities related to file upload. The function also includes a mechanism to fetch the user ID of the requesting user. However, it fails to verify whether that user ID is actually authorized to perform these actions.

The UploadFile method retrieves a user identifier from the request context but never validates whether this user has the necessary permissions to write files to the target portal directory. In unauthenticated contexts, the method either defaults to a guest user ID (typically -1 or 0) or accepts whatever value is provided in the request parameters without validation, allowing attackers to impersonate system accounts.

Furthermore, the function does not consult DNN's FileManager service or FolderPermissionController to verify write permissions for the target directory. The absence of this check means that the physical file system permissions become the only barrier, and since the IIS application pool identity typically has broad write access to the Portals directory tree, attackers can write to virtually any location within the portal structure.

Dangerous File Overwrite Implementation

This is the main method that implements the override functionality based on a boolean overwrite flag. When overrideFiles is true, the method replaces the contents of an existing file—a behavior that must be guarded by explicit authorization checks and safe overwrite semantics to avoid unauthorized tampering or accidental data loss.

The overwrite mechanism is particularly dangerous because it directly invokes File.Delete() followed by FileStream.SaveAs() without any intermediate safety checks. This means an attacker can target critical portal assets such as the default skin files, portal logos, or configuration files. The method does not maintain backup copies, does not log the overwrite operation, and does not verify that the requesting user owns the original file or has administrative privileges over it.

In multi-tenant DNN environments, this flaw becomes even more severe because an attacker could potentially overwrite files across different portal instances by manipulating the PortalId parameter.

To verify the presence of this vulnerability, we send a POST request to Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx using a multipart/form-data payload. This request structure mimics how the legitimate CKEditor file upload feature interacts with the backend.

The multipart/form-data encoding allows the attacker to embed binary file content alongside textual parameters in a single HTTP request. An attacker can construct this request using common tools such as curl, Python's requests library, or specialized HTTP clients like Burp Suite or Postman. The request does not require any authentication tokens, session cookies, or CSRF tokens because the vulnerable handler performs no validation whatsoever.

Parameter Manipulation and Payload Structure

In the proof-of-concept, we supply an arbitrary file (for example, poc.png) through the form field parameter file. Additional parameters such as storageFolderId, PortalId, and OverrideFile are also passed along. These parameters are crucial:

• storageFolderId specifies the target folder where the file will be stored within the portal's file management system. By default, a value of 0 points to the root Portals/_default/ directory, but attackers can enumerate folder IDs to target specific subdirectories containing sensitive assets.
• PortalId determines which portal instance the file upload applies to (in multi-tenant DNN environments). In shared hosting scenarios, an attacker could potentially upload malicious files to any portal by iterating through portal ID values.
• OverrideFile is a boolean flag that instructs the server to overwrite an existing file if one already exists with the same name. When set to "true", this parameter enables the replacement of legitimate portal assets with attacker-controlled content.

During exploitation, the vulnerable handler fails to verify the user's session or authentication state before accepting and processing these parameters. Any unauthenticated user can craft a malicious multipart POST request containing arbitrary file data. The server interprets it as a valid upload request and writes the file directly into the portal directory (commonly Portals/_default/).

Upon receiving the request, the server's response typically includes a JSON or XML-formatted message indicating upload success, including the file path, file ID, and the URL where the uploaded file can be accessed. This response provides immediate confirmation to the attacker that their payload has been successfully written to the server.

Mitigation:

• Patch Immediately: Upgrade to DNN 10.1.1 or later, which adds RequiresAuthentication attributes and guest upload blocks.
• Interim Workarounds: 
  • Disable CKEditor: Admin > Basic Settings > HTML Editor > Switch to TinyMCE.
  • Web.config Restriction:

<location path="Providers/HtmlEditorProviders">
  <system.web>
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</location>

• File ACLs: Revoke write access to Portals/ for IIS_IUSRS via NTFS permissions.
• WAF Rules: Block unauthenticated POSTs to *.ashx with file attachments.
• Detection: Log anomalous multipart/form-data requests; use SIEM queries for /FileUploader.ashx hits from unknown IPs.
• Best Practices: Regular CMS audits, least-privilege hosting, and input validation for all providers.

Timeline:

  

Conclusion:

CVE-2025-64095 underscores the perils of legacy authentication gaps in CMS platforms like DNN, where usability features like CKEditor uploads can become high-severity vectors. While patchable, the unauthenticated nature demands swift action to avert defacement campaigns. Organizations should prioritize upgrades, monitor for anomalies, and integrate this into broader .NET/CMS security hygiene. Future disclosures will likely highlight similar provider flaws, emphasizing the need for proactive code reviews in open-source ecosystems.