What Is a Homoglyph Attack? Unicode Spoofing in 2026

A homoglyph attack (also called a homograph or IDN homograph attack) is visual spoofing: an attacker swaps one or more letters in a domain, email address, filename, or even source code for a near-identical character from another script, so the text looks legitimate but points somewhere else. To your eye, example.com with a Cyrillic "а" is indistinguishable from the real example.com with a Latin "a", yet they are entirely different strings that resolve to different places. This guide explains how homoglyph attacks work, where they now appear (including code and software packages), real 2026 examples, how to test for them, and how to defend, at a time when no major browser reliably stops them.

Updated: August 2026. Reflects the 2026 threat picture (no unified browser IDN defense, a resurgence of punycode phishing, and homoglyph/Unicode attacks spreading into source code and package registries).

The quick answer

The one line to remember: a homoglyph attack hides a malicious name in plain sight, so the string you read is not the string the computer resolves.

What is a homoglyph attack?

A homoglyph is a character that looks like another. Unicode contains tens of thousands of characters across dozens of scripts, and many are visually identical or nearly so, the Latin "o" (U+006F) and the Cyrillic "о" (U+043E) render the same on virtually every screen. A homoglyph attack weaponizes that overlap: the attacker composes a name that looks like a trusted one but contains one or more characters from a different script.

The enabling technology is the Internationalized Domain Name (IDN) system, which lets domains use non-ASCII characters (encoded behind the scenes as "punycode," an xn-- string). IDNs exist for a good reason, so the world can have domains in Arabic, Chinese, Cyrillic, and every other script, but they also mean a fully Cyrillic аррӏе.com can be registered and will resolve completely independently of the Latin apple.com. To a human, and to many filters, the two look the same.

This is why homoglyph attacks are a favorite of phishers and, increasingly, supply-chain attackers: the deception happens at the level of perception, before any security control gets a clean string to inspect.

How homoglyph attacks work

The mechanics are consistent whether the target is a domain, an email, or a line of code.

• Pick a target name. A trusted brand, login domain, sender address, package name, or function name.
• Substitute confusable characters. Swap one or more Latin letters for look-alikes from Cyrillic, Greek, or other scripts, or even use digits and symbols (0 for O, 1 for l, rn for m).
• Register or publish it. Register the IDN domain, spoof the email display name, or publish the malicious package or code.
• Deliver it. Put the look-alike in a phishing email, ad, message, dependency list, or pull request, where the victim (or an automated system) reads it as legitimate.

The classic proof of concept came from security researcher Xudong Zheng in 2017, who registered аррӏе.com using Cyrillic characters, which punycode-encodes to xn--80ak6aa92e.com, and demonstrated that Chrome and Firefox at the time displayed it as apple.com. The visual was perfect; the destination was not.

Homoglyph vs typosquatting vs slopsquatting

These lookalike techniques are often confused. The differences matter for defense.

The key distinction: typosquatting needs you to make a mistake; a homoglyph attack works even when you read carefully or copy and paste, because the string genuinely looks right. Slopsquatting is the newest twist, attackers register the fake package names that AI assistants confidently suggest but that never existed, catching developers who trust the AI's output.

Where homoglyph attacks appear now

Homoglyphs started as a domain trick. In 2026 they span four surfaces.

• Fake domains and websites. The original use: аррӏе.com, citibаnk.com, or a Cyrillic-laced login page that harvests credentials.
• Phishing emails and BEC. Attackers put homoglyphs in sender display names and addresses, a "Sρпtify Support Team" (Greek ρ and ο) or a spoofed DocuSign notice, that render normally and slip past naive filters. This feeds the business email compromise problem directly.
• Source code (Trojan Source). The 2021 "Trojan Source" research (CVE-2021-42574 and CVE-2021-42694) showed that Unicode can make source code look one way to a human reviewer while the compiler interprets it differently, for example defining a malicious function whose name is a homoglyph of a legitimate one. Follow-on attacks like the 2026 "Glassworm" invisible-Unicode campaigns keep this alive.
• Software packages (supply chain). Attackers publish malicious packages to npm and PyPI with homoglyph or typosquatted names of popular libraries. In August 2026, a self-propagating npm worm pushed malicious versions of packages like keyv and cacheable, part of a broader wave of AI-scaled, name-confusion supply-chain attacks that our attack surface management guidance treats as a first-class risk, and that our supply chain attack statistics track in detail.

Why homoglyph attacks matter in 2026

Three forces make this more dangerous, not less.

• Phishing is still the top vector, and the stakes are high. IBM's 2025 report put the global average breach at $4.44 million and the US average at $10.22 million, broken down further in our data breach cost analysis, and phishing remains a leading initial-access method. Homoglyphs are a reliable way to make a phishing lure pass a glance, as our phishing statistics roundup shows.
• AI scales the deception. Generative AI lets attackers spin up thousands of convincing lookalike domains, emails, and packages cheaply, and "slopsquatting" turns AI's own hallucinations into attack surface. Volume plus realism is the new normal.
• Browsers do not save you. There is no unified browser defense in 2026. Chrome, Firefox, and Safari each apply their own IDN-display heuristics, showing punycode for suspicious mixed-script domains, but each has known bypasses, and a well-constructed homoglyph domain can still render as its target. Researchers noted a fresh surge in punycode-based IDN phishing in early 2026.

Real-world homoglyph examples

The common thread: the top-level domain or the surrounding structure stays familiar, only the characters change, so the fake blends seamlessly into whatever interface displays it.

How to test for homoglyph attacks

Include homoglyph scenarios in phishing, red-team, and supply-chain assessments, alongside the core stages of what penetration testing covers. A practical sequence, which slots into a standard external penetration test:

1. Inventory the targets. List your critical domains, login URLs, sender addresses, brand names, and key software dependencies, the things worth spoofing.
2. Generate lookalikes. Use tools like dnstwist and the Unicode confusables data (UTS #39) to enumerate homoglyph and typosquatted variants of each target.
3. Simulate safely. Register test domains in a controlled environment or simulate them via lab DNS/hosts entries to see how browsers and mail clients render them (often as punycode, sometimes not).
4. Run controlled phishing and access tests. Send sanctioned phishing using the lookalikes and check whether filters catch them, whether users notice, and whether password managers correctly refuse to autofill on the wrong domain (a strong, underrated signal).
5. Analyze and report. Document which lookalikes were most convincing and which controls failed, then recommend blocks, filter updates, monitoring rules, and MFA on affected accounts.

Testing separately measures the control and the human, because a homoglyph attack can defeat either one alone.

How to defend against homoglyph attacks

Defense has to be layered, because no single control catches every case.

Two controls do the heaviest lifting. Phishing-resistant MFA neutralizes the payoff of a successful homoglyph phish, because a passkey simply won't work on the wrong domain. And automated confusable detection plus monitoring catches at machine speed what human eyes cannot, while the human side is quantified in our social engineering statistics. Pair those with a tested incident response plan so a reported lookalike triggers fast takedown and account protection.

Conclusion

Homoglyph attacks are a small trick with an outsized reach: by swapping a single character for a look-alike, an attacker can turn a trusted domain, email, code review, or dependency into a weapon, and in 2026 no browser reliably stops them. The defense is visibility and layering, force punycode, monitor for lookalikes, detect confusables automatically, lint your code and dependencies, and deploy phishing-resistant MFA so a convincing fake still fails. Above all, remember that the name you read is not always the name the machine resolves, and test for the difference before an attacker exploits it.

DeepStrike's penetration testing includes phishing and social-engineering assessments that use homoglyph and lookalike-domain scenarios to validate whether your filters, browsers, and people actually catch them. To scope an engagement, see our penetration testing services.

FAQ

What is a homoglyph (homograph) attack?

It is a spoofing attack that makes a domain, email, filename, or piece of code look identical to a legitimate one by replacing characters with visually similar glyphs, often from another alphabet. For example, using a Cyrillic "а" instead of a Latin "a" in a URL creates a lookalike that resolves to a different, attacker-controlled destination.

How is a homoglyph attack different from typosquatting?

Typosquatting relies on you making a typing mistake, like gooogle.com. A homoglyph attack uses characters that look identical to the real ones, so it fools you even when you read carefully or copy and paste, because the text genuinely appears correct. Homoglyphs deceive perception; typosquatting exploits error.

Can browsers block homoglyph attacks automatically?

Not reliably. As of 2026 there is no unified defense: Chrome, Firefox, and Safari each apply their own heuristics that show punycode (xn--...) for suspicious mixed-script domains, but each has known bypasses, and a carefully built homoglyph domain can still render as its target. Browser display helps but cannot be your only control.

Can homoglyphs appear in source code, not just domains?

Yes. The 2021 "Trojan Source" research (CVE-2021-42574 and CVE-2021-42694) showed that Unicode homoglyph and bidirectional-override characters can make source code look benign to a human reviewer while the compiler interprets it maliciously, for instance calling a homoglyph-named function. Anti-bidi linters and Unicode code scanning defend against it.

What are homoglyph attacks in software packages?

Attackers publish malicious packages to registries like npm and PyPI using homoglyph or typosquatted names of popular libraries, so developers install the fake by mistake. A related 2025-2026 twist is "slopsquatting," registering the plausible package names that AI coding assistants hallucinate. Dependency pinning, name verification, and scanning are the defenses.

Why are homoglyph attacks dangerous even with email security in place?

Because a homoglyph URL or sender looks legitimate, so simple filters that match on paypal.com miss pаypal.com with a Cyrillic character. The malicious string is a different string entirely. That is why defense must be layered, punycode display, confusable detection, DMARC, and phishing-resistant MFA, rather than any single filter.

How can penetration testing find homoglyph weaknesses?

Testers generate homoglyph and typosquatted variants of your domains with tools like dnstwist and the Unicode confusables data, then use them in sanctioned phishing and access tests to see whether email filters catch them, whether users notice, and whether controls like password-manager autofill correctly refuse the fake domain. The gaps found drive filter, monitoring, and training fixes.