DNN Vulnerability: Attackers Can Steal NTLM Credentials Through Unicode Normalization Bypass

A critical vulnerability in DNN (formerly DotNetNuke), one of the oldest open-source content management systems established in 2003.

The vulnerability, designated CVE-2025-52488, allows attackers to steal NTLM credentials through a sophisticated Unicode normalization bypass that exploits file system operations.

This authentication vulnerability affects the widely-used enterprise CMS platform, demonstrating how defensive coding measures can be circumvented through creative attack vectors.

The vulnerability was discovered in April 2025 by security researchers who found that DNN’s file upload functionality contained a flaw that could be exploited to make arbitrary SMB calls to attacker-controlled servers.

The issue stems from DNN’s attempt to sanitize user input through multiple security boundaries, including filename validation, illegal character replacement, and Unicode normalization. However, the sequence of these security measures created an exploitable gap.

The vulnerability exists in the FileUploader.ashx.cs component, specifically in the UploadWholeFile method that processes file uploads.

Despite implementing several defensive measures including Path.GetFileName calls, regex replacements, and filename validation functions, the code performs Unicode normalization after these security checks.

This post-validation normalization creates a window for attackers to bypass the earlier security boundaries using specially crafted Unicode characters.

DNN Vulnerability

The attack leverages the quirks of .NET’s Path.Combine function and Windows file system operations.

When an attacker provides a UNC path to file system operations, it can trigger out-of-band calls to attacker-controlled SMB servers, potentially leaking NTLM credentials.

The researchers discovered that specific Unicode characters could be normalized back to ASCII equivalents that bypass security controls.

The key to the exploit lies in the ConvertUnicodeChars function, which uses Encoding.ASCII.GetString(Encoding.GetEncoding(1251).GetBytes(input)) to normalize Unicode characters.

Through fuzzing, researchers identified that characters like U+FF0E (FULLWIDTH FULL STOP) and U+FF3C (FULLWIDTH REVERSE SOLIDUS) normalize to periods and backslashes respectively.

These characters, when URL-encoded as %EF%BC%8E and %EF%BC%BC, allow attackers to construct paths that appear safe to initial validation but become malicious after normalization.

While exploiting this issue, we had a debugger attached to DNN, where you can see this transformation taking place:

The exploit chain works by crafting a filename containing these Unicode characters that, after normalization, results in a UNC path pointing to an attacker-controlled SMB share.

When the File.Exists function processes this normalized path through Path.Combine, it ignores the intended storage folder and attempts to access the attacker’s server instead.

Mitigations

The researchers noted that DNN developers had implemented multiple layers of security to prevent exactly this type of vulnerability, making the discovery particularly significant.

The vulnerability affects the pre-authentication file upload endpoint, making it accessible without user credentials. However, a similar vulnerability in another component requires authentication, limiting its impact.

This discovery highlights the ongoing relevance of NTLM credential theft techniques, particularly on older Windows systems that commonly host legacy applications like DNN.

The vulnerability demonstrates how Unicode normalization, while necessary for supporting diverse user bases, can create unexpected security gaps when implemented after security boundary checks.

The research underscores the importance of conducting security validations after all input transformations are complete, rather than before normalization processes that might alter the input’s security characteristics.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.