Unicode Normalization Attacks: When “admin” ≠ “admin” 🔤

Understanding the Hidden Danger in Character Encoding

In the digital world, seeing truly isn’t always believing. While the username “admin” might look identical on your screen, it could actually be represented by entirely different Unicode characters—opening the door to sophisticated cyberattacks that bypass security filters, create deceptive lookalike domains, and enable account takeovers. Welcome to the world of Unicode normalization attacks, where visual similarity conceals malicious intent.

What Are Unicode Normalization Attacks?

Unicode normalization attacks exploit the fact that many characters can be represented in multiple ways within the Unicode standard. Unicode, the universal character encoding system that supports virtually all written languages, contains over 149,000 characters. Many of these characters look identical or nearly identical to one another but are assigned completely different code points—the numerical values that computers use to identify characters.

A recent Android security vulnerability, CVE-2024-43093, demonstrates the real-world impact of these attacks. This zero-day flaw, which was actively exploited in targeted attacks, involved incorrect Unicode normalization that allowed attackers to bypass file path filters designed to prevent access to sensitive directories, leading to local escalation of privilege.

The Core Problem: Multiple Representations

The fundamental issue lies in how Unicode handles character equivalence. The Unicode standard defines two types of equivalence:

Canonical Equivalence: Characters that have the same appearance and meaning when displayed are considered canonically equivalent, even if they’re encoded differently.

Compatibility Equivalence: A weaker form where characters represent the same abstract character but may be displayed differently depending on context.

To standardize these variations, Unicode defines four normalization forms:

• NFC (Normalization Form Canonical Composition): Composes characters using canonical equivalence
• NFD (Normalization Form Canonical Decomposition): Decomposes characters using canonical equivalence
• NFKC (Normalization Form Compatibility Composition): Composes using compatibility equivalence
• NFKD (Normalization Form Compatibility Decomposition): Decomposes using compatibility equivalence

The security vulnerability emerges when applications apply security checks before normalization, or when different parts of a system normalize text inconsistently.

Real-World Attack Vectors

1. SQL Injection Through Unicode Bypass

One of the most dangerous applications involves SQL injection attacks. The Unicode character ‘FULLWIDTH APOSTROPHE’ (U+FF07) normalizes to a standard apostrophe (U+0027) when using NFKD or NFKC normalization. If an application filters out standard apostrophes before normalization, attackers can inject the fullwidth version, which bypasses the filter but becomes a malicious apostrophe after normalization.

Consider this attack scenario:

Original query: SELECT name, bio from profiles where name like '%chloe%'
Attacker input: chloe%uff07 UNION SELECT username, password from users --
After normalization: SELECT name, bio from profiles where name like '%chloe' UNION SELECT username, password from users -- %'

The attack bypasses input filters designed to block SQL injection by using Unicode characters that aren’t caught by the filter but transform into dangerous SQL syntax after normalization.

2. Cross-Site Scripting (XSS) Exploits

Similar vulnerabilities affect XSS prevention. Characters like ‘SMALL LESS-THAN SIGN’ (U+FE64) and ‘FULLWIDTH GREATER-THAN SIGN’ (U+FF1E) can bypass filters that block standard HTML tag delimiters, but normalize into functional < and > characters that enable JavaScript injection.

An attacker might submit:

＜img src=x onerror=alert(123)＞

While the filter blocks standard <img> tags, the fullwidth Unicode equivalents slip through, only to transform into executable HTML after normalization.

3. Path Traversal and File System Attacks

In 2025, researchers discovered CVE-2025-52488 affecting DNN (formerly DotNetNuke), a widely-used content management system. The vulnerability exploited Unicode normalization to bypass file path security checks. Attackers crafted filenames using Unicode characters U+FF0E (fullwidth full stop) and U+FF3C (fullwidth reverse solidus), which bypassed initial validation but normalized to standard periods and backslashes.

This allowed the creation of UNC paths like \\example.com\share.jpg, which triggered Windows SMB connections to attacker-controlled servers, potentially leaking NTLM credentials. The attack was particularly insidious because DNN developers had implemented defensive coding specifically to prevent such vulnerabilities, but normalization occurring after security validation created a bypass opportunity.

4. Account Takeover Through Username Confusion

Unicode normalization can lead to username collision attacks. If a system allows registration with Unicode usernames but normalizes them inconsistently during different operations (registration versus login), attackers can create accounts that appear identical to legitimate users.

Security researchers have demonstrated IDN homograph attacks against SMTP servers where substituting ‘a’ with ‘á’ (a with an acute accent) allowed password reset links intended for one account to be intercepted by another. When chained with response manipulation techniques, this resulted in complete account takeover.

IDN Homograph Attacks: The Domain Name Deception

One of the most visible manifestations of Unicode attacks involves Internationalized Domain Names (IDN). IDN homograph attacks exploit the fact that many different characters from various scripts look identical. For example, the Cyrillic, Greek, and Latin alphabets each have a letter ‘o’ that appears the same but represents different sounds in their respective writing systems.

The Mechanics of Domain Spoofing

The potential for these attacks was first documented in December 2001 by researchers Evgeniy Gabrilovich and Alex Gontmakher from Technion, Israel, who successfully registered a variant of microsoft.com incorporating Cyrillic characters. The issue gained widespread attention in February 2005 when security researcher 3ric Johanson demonstrated the exploit at the Shmoocon conference.

Particularly dangerous character combinations exist in Cyrillic alphabets. If a target domain consists of letters “ј ѕ і а е о р с у х s” (with ’s’ from the Macedonian alphabet), attackers can register a domain completely unrecognizable from the Latin-based original. For instance, a domain like оорѕ.com appears identical to oops.com but uses entirely different Unicode characters.

Browser Defenses and Limitations

Modern browsers have implemented Punycode display—a method of representing Unicode characters as ASCII strings. When a potentially dangerous IDN is detected, browsers display the ASCII Punycode version (like xn--n1aag8f.com) instead of the Unicode representation. However, these protections are inconsistent.

As of 2017, several browsers including Chrome, Firefox, and Opera displayed IDNs consisting purely of Cyrillic characters normally without converting to Punycode, enabling spoofing attacks. Chrome addressed this in version 59 with tightened IDN restrictions.

Research from Bitdefender revealed that Microsoft Office applications—including Outlook, Word, Excel, OneNote, and PowerPoint—were particularly vulnerable to IDN homograph attacks, with all versions tested displaying international domain names instead of their real ASCII equivalents.

The Prevalence of IDN Attacks

Analysis of Akamai DNS traffic revealed the concerning scale of homograph attacks. Over a 32-day period, researchers identified 6,670 homograph IDNs that were actually accessed in DNS traffic, with an average of 67 newly-detected domains appearing daily. More alarming, 29,071 devices accessed at least one homograph IDN during the examination period, with over 850 devices daily accessing homograph IDNs for the first time.

Emerging Threats: AI and LLM Vulnerabilities

Recent research has identified Unicode-based attacks as a growing threat to artificial intelligence systems, particularly Large Language Models (LLMs). Attackers use emojis, zero-width characters, homoglyph substitutions, and combining marks to obfuscate malicious inputs, bypassing AI-powered content moderation and input validation systems.

The vulnerability extends to terminal emulators processing LLM outputs. When LLMs generate ANSI escape codes through Unicode manipulation, attackers can hijack terminals, manipulate visual displays, insert hidden text, and even access clipboards.

The Emoji Jailbreak

Google Cloud documented “Emoji Jailbreaks” where attackers exploited vulnerabilities in tokenization algorithms and variability in Unicode normalization to insert adversarial prompts into LLMs. These attacks evade traditional security controls by confusing tokenization processes.

Detection and Prevention Strategies

For Developers

1. Normalize Early, Validate Consistently

The most critical defense is normalizing all user input immediately upon receipt, before any security validation or filtering occurs. This prevents the “validate-then-normalize” vulnerability that enables most Unicode attacks.

# Correct approach
user_input = normalize_unicode(user_input)  # Normalize first
if is_valid(user_input):  # Then validate
process(user_input)

2. Use Strict Character Whitelisting

Instead of blacklisting dangerous characters, whitelist only expected characters for each input field. If an input field should only contain ASCII letters, reject any Unicode characters entirely.

3. Implement Multiple Validation Layers

Validate inputs at multiple stages of processing, especially after any transformation or normalization operations. The principle is that security boundaries should be checked after normalization, not before.

4. Be Aware of Framework-Specific Quirks

When working with .NET on Windows, file system operations pose inherent risks. Functions like File.Exists, System.Net.HttpRequest, and System.Net.WebClient can trigger SMB connections if attacker-controlled paths are provided, potentially leaking NTLM credentials. Developers should carefully audit code for these sinks.

5. Monitor for Suspicious Patterns

Implement logging to detect unusual Unicode characters in inputs, especially in fields that should contain only ASCII text. Flag and investigate submissions containing: - Fullwidth characters - Combining diacritical marks - Zero-width characters - Mixed-script content

For Organizations

1. Proactive Domain Registration

Organizations should proactively register potential homograph domains that could spoof their brand. Because IDNs are limited to single character sets, the combinations are finite and predictable. Few companies currently implement this defensive strategy.

2. Email and Web Filtering

Deploy email filtering solutions that detect and quarantine messages containing IDN homographs or suspicious Unicode patterns. Configure email clients to display Punycode representations of all IDNs.

3. User Education and Awareness

Train employees to verify URLs by checking the browser’s address bar before entering credentials. In 2025, with phishing costs averaging $4.88 million per incident and $10.22 million in the United States, and AI-driven phishing attacks increasing by 1,265% year-over-year, homograph spoofing represents a critical threat vector.

4. Multi-Factor Authentication

Implement strong multi-factor authentication across all systems. Even if attackers steal credentials through homograph phishing, MFA provides a crucial additional barrier.

5. Certificate Monitoring

Monitor certificate transparency logs for suspicious domain registrations. Attackers often obtain valid TLS certificates from services like Let’s Encrypt for their homograph domains, and nearly 10% of homograph domains use HTTPS, which increases user trust in malicious sites.

For End Users

1. Verify URLs Carefully

Always check the address bar before entering sensitive information. Look for: - Unusual characters or diacritical marks - Punycode representations (starting with xn--) - Slight variations in domain spelling

2. Type URLs Manually

When accessing sensitive sites like banking portals, type the URL manually rather than clicking links in emails or messages. While typosquatting relies on user errors, homograph attacks work even when users carefully click legitimate-looking links.

3. Use Browser Security Features

Enable and configure built-in phishing protection in modern browsers. Ensure your browser is updated to the latest version, which includes improved IDN homograph detection.

4. Bookmark Trusted Sites

Create bookmarks for frequently visited sensitive sites. This eliminates the risk of navigating to homograph spoofs.

Advanced Defense: Unicode Sanitization for AI Systems

The “Black Box Emoji Fix” represents an innovative defensive approach for LLM systems. This method integrates comprehensive Unicode normalization using NFKC (Normalization Form Compatibility Composition), grapheme cluster analysis, and multilayer filtering techniques to neutralize Unicode-based injection attacks.

The approach works through multiple stages: 1. Replace grapheme clusters containing dangerous Unicode characters with safe strings 2. Remove or replace emoji in configurations where they’re not permitted 3. Deploy customizable tokenizers to detect token explosion attacks 4. Apply strict mode settings for extended filtering based on Unicode category analysis

The Future of Unicode Security

As internationalization continues expanding across the internet, Unicode attacks will evolve in sophistication. The tension between supporting global languages and maintaining security will persist. Key challenges ahead include:

AI and Machine Learning Targets: As LLMs become more prevalent, Unicode-based prompt injection and jailbreak techniques will advance.

IoT Device Vulnerabilities: Internet-connected devices with limited processing power may perform inconsistent Unicode normalization, creating new attack surfaces.

Supply Chain Risks: Homograph attacks targeting supply chain communications—spoofing critical suppliers, customers, or partners—could enable sophisticated business email compromise schemes.

Zero-Width and Invisible Characters: Attackers increasingly leverage zero-width joiners, zero-width non-joiners, and other invisible Unicode characters to hide malicious payloads in plain sight.

Conclusion: Vigilance in the Visual Layer

Unicode normalization attacks represent a fundamental challenge at the intersection of internationalization and security. The visual similarity that makes Unicode characters useful for global communication simultaneously makes them dangerous for security systems that rely on character matching and filtering.

The key lessons for defending against these attacks are:

1. Never trust visual appearance—always normalize and validate programmatically
2. Normalize before validating—security checks on un-normalized input are ineffective
3. Assume multiple representations exist—for any given character, there may be dozens of Unicode equivalents
4. Layer your defenses—no single mitigation is sufficient
5. Stay informed—new attack techniques emerge regularly as Unicode evolves

Whether you’re a developer building secure applications, a security professional protecting infrastructure, or an end user navigating the web, understanding that “admin” doesn’t always equal “admin” is crucial. In the Unicode universe, what you see is not always what you get—and that invisible difference can be the gateway to serious security breaches.

The invisible war between identical-looking characters continues to rage, hidden in plain sight. The only defense is awareness, vigilance, and robust technical controls that look beyond the surface to the underlying code points that computers actually process. In cybersecurity, as in life, appearances can be dangerously deceiving.

---

Keywords: Unicode normalization attacks, homograph attacks, IDN spoofing, cybersecurity, SQL injection, XSS attacks, account takeover, phishing, domain spoofing, character encoding vulnerabilities, LLM security, Unicode security, internationalized domain names, Punycode, CVE-2025-52488, NTLM credential theft, path traversal attacks

Related Topics

#Unicode normalization attacks, Unicode security, Unicode encoding vulnerability, Unicode spoofing, Unicode bypass, Unicode normalization 2025, Unicode phishing, Unicode homoglyphs, Unicode normalization bug, Unicode normalization vulnerability, CVE-2024-43093, CVE-2025-52488, Unicode path traversal, homograph attacks, IDN homograph, domain spoofing, internationalized domain names, IDN spoofing, Punycode phishing, visual spoofing, mixed script domain attack, zero width character attack, invisible Unicode characters, fullwidth characters, combining marks attack, zero width joiner, zero width non joiner, Unicode SQL injection, Unicode XSS, fullwidth apostrophe, Unicode HTML bypass, Unicode account takeover, Unicode username confusion, Unicode login spoofing, AI Unicode jailbreak, LLM Unicode attack, emoji jailbreak, prompt injection Unicode, character encoding exploit, Unicode canonical equivalence, NFKC normalization, NFD normalization, normalization bug exploitation, cross-language spoofing, Unicode normalization bypass, Unicode validation best practices, Unicode sanitizer, Unicode security 2025, IDN phishing campaign, NTLM credential leak Unicode, Unicode normalization defense, Unicode vulnerability mitigation, homoglyph detection, Unicode normalization filter, Unicode confusion attack, Unicode threat AI, Unicode-based prompt injection, Unicode bypass filters, Unicode spoofing prevention