Homoglyphs use visually similar characters from different scripts to make a dangerous filename look like a harmless one. An attacker may disguise the real extension or confuse weak validation that compares strings visually instead of by normalised code points. Defenders should normalise input, enforce allowlists on server-side file types, and inspect actual content rather than appearance.
Why homoglyphs work against file extension checks
Homoglyph attacks exploit the gap between what a filename looks like to a human and what it actually is to the parser. If a filter compares raw text, or only strips a narrow set of characters, a disguised extension can survive long enough to reach storage, execution, or downstream processing. The core failure is treating visual similarity as if it were a trustworthy security signal.
That matters because extension filters are usually trying to answer a specific policy question: “Is this an allowed file type?” If the answer depends on visual inspection, the attacker only needs a character set that creates ambiguity across scripts, fonts, or rendering paths. A secure design must rely on normalized, machine-readable values and not on what the name appears to be.
File Upload Security Guide covers the broader controls that make this kind of bypass harder, including extension allowlists, content validation, and filename sanitisation.
Where the bypass happens in the upload pipeline
The weakness usually appears before the file reaches durable storage. An application may validate the extension on the client, accept the upload on the server, and only later rename, scan, or route the file. If those steps are not aligned, a filename that looks benign during one check can be interpreted differently by another component.
Homoglyphs are especially effective when the system validates by string comparison instead of by canonical form. A name can contain characters that resemble ASCII letters but belong to a different Unicode script, so the uploaded object passes a weak extension rule while still carrying a dangerous payload or a dangerous true extension. This is why visual inspection, copy-paste review, and ad hoc regexes are not reliable controls by themselves.
Persistence Techniques Guide is useful when an upload weakness could be chained into a web shell or other durable foothold after the file lands.
What defenders should validate before trusting the filename
The practical control objective is to validate the file as data, not as presentation. Normalise the filename before any decision, enforce a server-side allowlist of permitted types, and compare against the actual bytes or magic values where that is appropriate for the application. If the business accepts a small set of file types, reject everything else rather than trying to infer intent from naming conventions.
Security teams should also verify that every later step uses the same canonical representation. A file that is renamed, extracted, forwarded to antivirus, or handed to downstream processing must not be reinterpreted by a different normalization rule. When validation, storage, and preview code each “understand” the name differently, the upload path becomes inconsistent and bypasses become easier.
For high-risk upload points, confirm that file type decisions are enforced on the server after canonicalization, not merely in the browser or in a front-end SDK. The goal is to make the accepted type deterministic, reproducible, and independent of how the filename renders on a user’s screen.
Risk and Threat Considerations
Homoglyph bypasses can turn a routine upload feature into an execution or malware-delivery path when dangerous files are accepted as trusted content. The risk increases wherever uploads can be previewed, stored under web-accessible paths, or fed into automated processing that assumes the extension is honest.
Failure mechanism: A weak filter compares the filename as displayed, not as normalized code points or validated content, so a malicious extension survives the check and reaches a sensitive handler.
Impact: The result can be malicious code upload, unexpected file execution, stored web content exposure, or a later-stage compromise when another service trusts the mislabeled file.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | Homoglyph bypasses abuse unsafe upload and file-type handling decisions. |
| V1 — Encoding and Sanitization | Unicode homoglyphs require canonicalization and sanitization before security decisions. | |
| Recommendation — Validate uploaded files by content and permitted type before storage or processing. Normalize input before comparing filenames or extension values. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | File upload filters are input-validation controls that must reject malformed names and types. |
| Recommendation — Enforce server-side validation on uploaded filenames and file content. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Upload handling is an application-security control area where parsing and allowlisting matter. |
| Recommendation — Harden upload code paths and test them against bypass cases. | ||
Practitioner Guidance
What to verify: Test the upload path with Unicode lookalikes, mixed-script names, multiple dots, and alternate encodings, then confirm the server makes the same decision after normalization that the security team expects. If different components disagree, treat that as a control failure, not a cosmetic issue.
What good looks like: The application rejects ambiguous filenames early, stores files under server-generated names, and makes type decisions from validated content or approved metadata rather than from appearance. That should be true consistently across upload, preview, scanning, and downstream processing.
Practitioner takeaway: Homoglyphs matter because they exploit human perception, but the defense must be machine-enforced, canonical, and content-aware. If the filename can influence security decisions, it is part of the attack surface.