DNN Vulnerability Let Attackers Steal NTLM Credentials via Unicode Normalization Bypass

A critical vulnerability in DNN (formerly DotNetNuke) that allows attackers to steal NTLM credentials through a sophisticated Unicode normalization bypass technique. 

The vulnerability, tracked as CVE-2025-52488, affects one of the oldest open-source content management systems and demonstrates how defensive coding measures can be circumvented through clever exploitation of Windows and .NET quirks.

Key Takeaways
1. CVE-2025-52488 in DNN allows attackers to steal NTLM credentials without requiring user authentication.
2. Specific Unicode characters (U+FF0E, U+FF3C) normalize into dots and backslashes after passing security validation, bypassing protection mechanisms.
3. Malicious filenames transform into UNC paths (\attacker.comshare) that trigger SMB connections to attacker-controlled servers via File.Exists.
4. Enables NTLM credential theft affecting enterprises and demonstrating how defensive coding can be circumvented through character encoding.

NTLM Credential Leak

Searchlight Cyber reports that the vulnerability exploits a fundamental weakness in how .NET applications handle file system operations on Windows machines. 

When attackers control file paths, they can provide UNC (Universal Naming Convention) paths that trigger out-of-band calls to attacker-controlled SMB servers. 

This mechanism becomes particularly dangerous when combined with functions like File.Exists, System.Net.HttpRequest, and System.Net.WebClient, which can inadvertently leak NTLM credentials to malicious servers.

The attack leverages the Path.Combine function’s behavior in C#, where if the second argument contains an absolute path, the first argument is completely ignored. 

According to Microsoft documentation, “if an argument other than the first contains a rooted path, any previous path components are ignored, and the returned string begins with that rooted path component.” 

This behavior, while documented, frequently leads to security vulnerabilities in C# codebases.

Technical analysis reveals that the core of this vulnerability lies in DNN’s Unicode handling process. 

The application implements multiple security boundaries to prevent malicious file uploads, including Path.GetFileName calls, regex replacements, and validation functions like Utility.ValidateFileName and Utility.CleanFileName. 

However, these security checks occur before the crucial Utility.ConvertUnicodeChars function. The vulnerable code section shows:

The ConvertUnicodeChars function contains the critical vulnerability in this line:

This normalization process converts Unicode characters to ASCII equivalents, effectively bypassing all previously implemented security measures.

Researchers discovered specific Unicode characters that normalize into dangerous path components:

• %EF%BC%8E (U+FF0E): “FULLWIDTH FULL STOP” normalizes to “.”
• %EF%BC%BC (U+FF3C): “FULLWIDTH REVERSE SOLIDUS” normalizes to “”

These characters allow attackers to construct malicious filenames that appear safe during initial validation but transform into UNC paths after normalization. The exploit payload demonstrates this:

When processed, this becomes: \attacker.comsharefile.jpg, triggering an SMB connection that leaks NTLM credentials to the attacker’s Responder server.

This vulnerability highlights the complexity of Unicode handling in web applications and demonstrates how defensive programming measures can be undermined by character encoding transformations. 

The pre-authentication nature of this vulnerability makes it particularly dangerous, as it requires no user credentials to exploit and can compromise domain credentials through NTLM relay attacks.

Investigate live malware behavior, trace every step of an attack, and make faster, smarter security decisions -> Try ANY.RUN now