Chromium IDN Spoofing Defenses Miss Convincing Lookalike Domains

Chromium IDN spoofing defenses missed 20 registered lookalike domains, despite years of safeguards designed to expose deceptive Unicode addresses. One proof-of-concept domain closely resembled apple.com while appearing as readable Unicode, not the conspicuous Punycode format beginning with xn--.

The finding does not mean attackers registered Apple’s domain or compromised its infrastructure. Researchers at Have I Been Squatted, or HIBS, registered a different domain whose Cyrillic characters resemble the Latin letters in “apple.” Their tests show how carefully selected characters can pass Chromium’s display rules and its separate navigation-time defenses.

That result revives a conflict browsers have managed since internationalized domain names entered widespread use. The web needs addresses written in the languages people actually use. However, the same character diversity gives attackers more ways to imitate trusted brands, identity providers, and payment services.

Chromium already applies one of the industry’s most detailed defense systems. It checks scripts, suspicious character combinations, known domains, and browsing history. The new examples do not erase those protections. They reveal how a few characters can fall between layers that each make slightly different decisions.

Researchers Found a New Chromium IDN Spoofing Edge Case

The important change is not the return of a forgotten attack, but evidence that current Chromium checks still permit convincing new variations.

HIBS researchers Ian Muscat and Leanne Briffa published their analysis on October 3, 2026. They examined whether an internationalized domain could resemble a famous Latin-script address while still appearing as Unicode in Chromium-based browsers.

An internationalized domain name, or IDN, contains characters beyond the basic English alphabet. Applications translate those characters into an ASCII-compatible representation called Punycode before making a DNS request. A domain beginning with xn-- is therefore not automatically dangerous. It is an encoded form needed by the existing Domain Name System.

Browsers often convert that encoded form back into readable Unicode for display. This supports legitimate addresses in Arabic, Cyrillic, Chinese, and many other writing systems. The security problem appears when different characters share nearly identical shapes.

The researchers focused on аррӏө.com, a domain that can resemble apple.com in common fonts. Its letters are Cyrillic, including characters shaped like a Latin “a,” two “p” characters, and an “l.” The final Cyrillic character, ө, resembles a rounded “e” when displayed at address-bar size.

The address is not apple.com. Its encoded form is xn--80a6aa68c8d.com, and DNS treats it as a separate name. Yet the readable version can create the visual impression that a visitor has reached Apple’s domain.

HIBS registered that domain and 19 additional lookalikes as a proof of concept. The list imitated names associated with OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike, and other recognizable organizations.

The original IDN research says Chrome 154 displayed the Apple lookalike in Unicode with a valid certificate. It also passed the navigation checks evaluated by the researchers without producing a lookalike warning.

A valid certificate does not prove that a domain belongs to the brand it resembles. It confirms that the browser established an encrypted connection to the domain named in that certificate. Attackers can obtain certificates for domains they legitimately control, including deceptive ones.

The examples were controlled registrations, not evidence of a campaign targeting customers of every named company. That distinction matters because a technically viable spoof is not automatically an active phishing operation.

Still, technical viability is the finding. A deceptive domain can support a real website, HTTPS, email, redirects, and other ordinary internet services. Attackers could then combine the visual resemblance with a search advertisement, fraudulent email, QR code, shortened link, or copied login page.

The research appeared in broader coverage on October 18, when a typosquatting investigation detailed how the Cyrillic substitutions survived Chromium’s rules. The timing puts renewed attention on defenses that many users never see unless the browser detects something suspicious.

This creates the article’s central tension. Chromium must distinguish deceptive visual substitutions from legitimate words used by millions of people. A rule broad enough to catch every resemblance would also make ordinary international addresses harder to read and trust.

How Chromium Unicode Lookalikes Pass Multiple Checks

The Apple lookalike survives because no single Chromium rule evaluates the complete visual impression that reaches the user.

Chromium does not simply ask whether a domain contains Unicode. It processes IDNs through several tests before deciding whether to show readable characters or the underlying Punycode label.

The first major layer uses the International Components for Unicode spoof checker. Chromium configures it at the “Highly Restrictive” level, which limits suspicious combinations of writing systems.

A mixed label containing one Cyrillic character among Latin letters will normally fail this test. Replacing only the first “a” in apple.com, for example, causes Chromium to display xn--pple-43d.com. The encoded address is much less likely to be mistaken for the original.

The new Apple lookalike avoids that result because every letter before .com is Cyrillic. It is a single-script label, not an obvious mixture of Latin and Cyrillic characters.

Chromium also maintains an allowed character set. It removes various Unicode blocks and individual code points associated with risky or confusing displays. The characters in аррӏө.com remain eligible, partly because they are legitimate letters used in real languages.

Several targeted checks follow. Chromium restricts Icelandic thorn and eth outside relevant country domains. It limits the Azerbaijani schwa and applies a specific rule to the Catalan middle dot. None of those restrictions addresses the Cyrillic sequence in the proof of concept.

The most relevant defense is Chromium’s whole-script confusable check. It looks for labels written entirely in Cyrillic characters that all resemble Latin letters.

Chromium introduced this protection after a widely discussed 2017 demonstration. Security researcher Xudong Zheng registered an all-Cyrillic version of apple.com that browsers displayed as a close visual copy of the real address.

Chromium responded in Chrome 58. Its whole-script check identifies a set of 29 Cyrillic characters that resemble Latin characters. When every letter in a single-script label belongs to that set, Chromium can display the domain as Punycode.

That defense catches the 2017 version. It does not catch the new variation because ө is not among the 29 listed characters. One character outside the set causes the whole-script condition to stand down, even though the complete label still resembles “apple.”

The browser must allow that character somewhere because it is not an invented symbol. Cyrillic ө is used in Kazakh, Mongolian, Tatar, and other languages. Blocking it everywhere would impose a usability cost on legitimate speakers.

Chromium then uses a skeleton comparison for protected domains. A skeleton reduces visually related characters into a normalized representation that software can compare against known names.

The process is useful but cannot perfectly reproduce human vision. In this case, the bar across ө survives normalization. The resulting skeleton ends with a form based on “o” plus a combining mark, rather than the expected Latin “e.”

That difference prevents an exact match with the skeleton for apple.com. One small mark is enough to change the computational result, even when that mark becomes difficult to see in a compact browser interface.

Latin-script examples expose a related weakness. The researchers used characters such as ƙ, a Latin letter with a hook, to imitate the “k” in names including Okta and Nike. Chromium cannot apply a broad whole-script warning to Latin characters because accented Latin domains are common and legitimate.

Chromium instead gives stronger skeleton protection to a bundled list of prominent domains. HIBS found 8,462 names in that list, including 836 in a higher-priority group. However, a character that preserves an extra mark can prevent an exact skeleton match.

The Chromium display guidance acknowledges the underlying balance. Chrome shows Punycode when its IDN display rules identify a homograph risk, but it avoids treating every non-ASCII address as hostile.

That balance makes Chromium IDN spoofing a classification problem rather than a simple blacklist problem. Every new rule must catch malicious resemblance without turning legitimate international names into unreadable encoded strings.

Browser Warnings Provide a Second Defense, With Limits

A domain that appears in Unicode still faces navigation checks, but those checks depend on exact comparisons, name length, and the visitor’s history.

Chromium separates address display from navigation-time protection. The first system determines how a hostname looks in the address bar. The second can interrupt or annotate a visit after the user navigates.

Chromium’s lookalike navigation component compares a visited address with popular domains and sites the user visits regularly. Depending on the match, Chrome can show a full-page interstitial or a less intrusive Safety Tip.

The lookalike warning design describes these checks as an additional layer beside Google Safe Browsing. Popularity and a user’s prior engagement give the browser reference points for identifying suspicious alternatives.

HIBS reports that an exact skeleton match against one of the 836 highest-priority domains produces an interstitial. An exact match against another bundled domain can produce a Safety Tip.

The browser also considers sites the user visits with sufficient frequency. If a new address exactly resembles one of those engaged sites, Chromium can block the navigation and ask whether the visitor intended to open the familiar domain.

Near matches receive narrower treatment. Chromium can detect a skeleton that differs by one inserted, removed, or replaced character. It can also recognize one swap between neighboring characters.

These comparisons do not apply uniformly. According to the research, the near-match test skips target labels shorter than five characters before the top-level domain. That matters for brands with compact names.

The Okta lookalike using ƙ is one edit away from the real name, but “okta” has four characters. The researchers say that makes it too short for the relevant near-match check.

The Apple example fails for a different reason. Its skeleton is two edits away from apple.com because ө normalizes to an “o” plus a retained bar. The near-match comparison allows only one edit.

As a result, the tested domain displayed as Unicode and loaded without a lookalike warning. HIBS says this remained true even for someone who regularly visited the authentic Apple website.

These findings should not be interpreted as a complete audit of every protection surrounding a visit. Safe Browsing, threat intelligence feeds, endpoint software, DNS filtering, email gateways, and reputation services can still flag a malicious domain.

HIBS also excluded some variables from its evaluation, including remote allowlists, reputation checks, and certain redirect behavior. A weaponized site could therefore encounter other defenses that the proof of concept did not test.

The reverse is also true. A newly created phishing domain might initially have little reputation data. Attackers often exploit that interval before automated systems classify the infrastructure or defenders complete a takedown.

This explains why the edge case matters even when multiple safeguards exist. Layered security works best when failures are independent. Here, several checks rely on closely related skeleton representations and domain lists, so a carefully chosen character can influence more than one decision.

History-based protection also means two users can receive different treatment. A regular visitor to a protected service gives the browser a known domain for comparison. A first-time visitor may have only the bundled popularity list.

That distinction is especially relevant for recruitment sites, regional banks, business software, and supplier portals. Employees may receive a link to a service they have never visited, leaving the browser with less personal history for comparison.

The safest conclusion is not that Chromium provides no protection. Its rules stop many common substitutions before they reach users. The lesson is that address-bar appearance and the absence of a warning cannot establish authenticity by themselves.

IDN Homograph Attacks Extend Beyond the Address Bar

The browser is only one display surface, while deceptive domains can reach users through email, messaging applications, documents, and search results.

An IDN homograph attack uses different characters that appear alike to impersonate another identifier. Typosquatting is the broader practice of registering confusing alternatives to a legitimate domain, including simple misspellings and visually deceptive characters.

The new research sits where those categories overlap. The domains are not conventional keyboard errors, but their visual similarity can exploit quick reading, small screens, and familiar brand shapes.

Email creates a particularly difficult handoff. Chromium’s address rules protect hostnames rendered by the browser interface. They do not automatically govern Unicode text that a webmail application places inside a message header.

HIBS tested 20 internationalized sender domains in Gmail and Outlook on the web. The researchers report that Gmail displayed all 20 in Unicode, including domains that Chromium’s address bar would have rendered as Punycode.

Gmail retained the encoded form in a separate mailed-by field, according to the test. Most recipients are more likely to inspect the prominent sender line than expand technical delivery information.

Outlook on the web took the opposite approach in the researchers’ test. It displayed all 20 sender domains as their ASCII-compatible labels, including ordinary international names such as café.com and zürich.com.

Neither approach fully resolves the underlying tradeoff. Decoding everything gives users readable international addresses but preserves visual ambiguity. Encoding everything exposes differences, while making legitimate multilingual addresses unfamiliar and difficult to interpret.

Messaging applications and documents can introduce the same gap. A platform can render a Unicode link as ordinary text before the browser receives the selected destination. The user evaluates one display, then navigates through another security system.

Search results and advertisements add another route. A deceptive domain can appear beside familiar branding and copied page titles. Even if the address differs slightly, the surrounding context can encourage a user to complete the visual pattern.

QR codes remove the visible destination almost entirely until scanning occurs. Mobile browsers also have less space for hostnames, and interfaces may emphasize a page title over the complete address.

The Unicode Consortium recommends several defenses for confusable IDNs. These include limiting allowed character repertoires, preventing risky script mixing, applying contextual language constraints, and blocking registrations that resemble existing labels.

Its IDN security guidance also emphasizes an important qualification. Unicode confusables represent only a small portion of phishing. Simple domains such as secure-brand-login.com remain more common and require no unusual characters.

That context prevents the new findings from becoming a claim that Unicode created most online fraud. Attackers usually choose the cheapest method that works. A familiar word, misleading subdomain, stolen account, or compromised legitimate site may be easier than constructing a sophisticated IDN.

However, lower prevalence does not remove the risk for high-value targets. Identity platforms, financial services, cloud consoles, and employee portals offer attackers valuable credentials. A visually strong impersonation can be worth the extra effort.

Internationalization itself is not the flaw. The internet must support names written outside the basic Latin alphabet. Treating every such address as hostile would shift the burden onto legitimate users and businesses.

The unresolved question is where each defense should operate. Browsers control display and navigation warnings. Registries control which labels can be registered. Email services control sender presentation. Brand owners monitor suspicious registrations, while security teams filter and investigate them.

No participant sees the complete attack path. That fragmentation allows a domain rejected by one interface to appear convincing in another.

Registries Cannot Leave Chromium IDN Spoofing to Browsers

The most durable defense begins before navigation, but registry policies remain fragmented across languages and top-level domains.

A domain cannot support an independent website or mailbox unless a registry permits its registration. Registry controls can therefore block deceptive names before browsers must decide how to display them.

Internationalized domain policies commonly use IDN tables. These tables define which Unicode characters a top-level domain accepts and which combinations or variants require special treatment.

The Unicode Consortium recommends bundling or blocking confusable labels. Bundling assigns related variants to the same registrant. Blocking allows one label to exist while preventing registration of confusing alternatives.

ICANN’s IDN implementation guidelines establish general expectations intended to reduce cybersquatting and consumer confusion. Actual policies still vary because different registries support different languages, scripts, and local requirements.

The .com registry permitted the HIBS proof-of-concept registrations. That does not mean .com accepts every Unicode sequence. It means the tested characters and combinations fit the applicable registration rules.

HIBS also analyzed the .com zone file obtained through ICANN’s Centralized Zone Data Service in October 2026. The researchers counted 167,226,216 delegated .com names, including 733,509 represented in IDN form.

Their methodology associated IDNs with delegated ASCII domains they visually resembled. It produced 161,894 lookalike pairs covering 133,953 distinct ASCII names.

Those numbers are not a count of malicious domains. The researchers explicitly caution that a visual pair can represent a defensive registration, a multilingual website, or an unrelated organization.

The distinction is essential. A domain containing an accented character may resemble an ASCII name by coincidence. Ownership, content, DNS behavior, certificates, email configuration, and redirects provide stronger evidence of malicious intent.

Even so, the scale shows why browser lists cannot enumerate every relevant target. Chromium’s bundled protections cover thousands of prominent names, while the .com zone contains millions of businesses and organizations that might face impersonation.

Small firms may be especially exposed. Their domains are less likely to appear on global popularity lists, yet their customers may trust invoices, supplier portals, and password-reset messages carrying the company name.

A registry could respond by banning a newly identified character from particular contexts. That approach can close one edge case but may also exclude valid words and communities that rely on the character.

A more precise policy can define variants based on language-specific relationships. However, visual resemblance depends on fonts, size, neighboring letters, and reader familiarity. A sequence obvious to an English speaker may be a legitimate word in another language.

Defensive registration offers another option. A brand can register likely variants and redirect them to the authentic domain. Chromium’s navigation code recognizes some safe redirects, which helps avoid warnings for variants controlled by the real organization.

That strategy does not scale perfectly. Unicode contains many potential substitutions, and registration policies change across top-level domains. Buying every conceivable lookalike would impose continuing cost and still leave gaps.

Monitoring offers broader coverage. Security teams can watch new registrations, certificate issuance, DNS changes, and hosting behavior for names resembling important domains. Early detection supports takedown requests and blocks before an attack reaches many users.

Organizations should also protect high-risk workflows outside the browser. Password managers match credentials to exact origins, making them less likely to autofill on a lookalike domain. Passkeys bind authentication to the legitimate site’s domain and resist conventional credential phishing.

Employees handling payments or account recovery need verification paths that do not rely on a link’s appearance. Known bookmarks, managed application portals, and independently confirmed contact channels reduce dependence on visual domain recognition.

These measures address more than Chromium Unicode lookalikes. They also help against ordinary misspellings, misleading subdomains, compromised mailboxes, and cloned login pages.

The pressure therefore falls on several parties at once. Chromium needs to refine its heuristics. Registries need stronger variant policies. Mail providers need clearer sender displays. Organizations need controls that assume users will sometimes misread an address.

What Happens Next Will Show Whether the Gap Really Closes

Three signals will determine whether this research produces a lasting defense or only another entry in the history of patched lookalikes.

The first signal is a Chromium rule change. The clearest response would address Cyrillic ө, Latin ƙ, or the branching logic that lets one unlisted character bypass a whole-script evaluation.

Simply adding two characters would stop the published examples. It would not necessarily solve the structural problem. Another character with a visible mark or unusual skeleton mapping might recreate the same result.

A broader fix could compare the rendered impression through additional skeleton transformations. Yet looser comparisons increase false positives, particularly for legitimate international names.

Chromium’s public code and tests make this process observable. Security researchers can examine whether a patch blocks the registered proofs while preserving ordinary domains in affected languages.

The second signal is action by registries. Updated IDN tables could classify these characters as variants in specific contexts or prevent registrations that imitate established ASCII labels.

Registry action would strengthen the article’s main judgment because it stops deceptive names before display differences arise. A browser-only patch would leave the domains available to email clients and other applications with different rendering rules.

The third signal is a change in mail presentation. HIBS found that Gmail decoded all tested sender domains, while Outlook displayed the encoded labels. Future interface changes might expose both forms, flag mixed visual identities, or warn when a sender resembles a known domain.

That signal matters because email remains a natural delivery mechanism for credential theft and payment fraud. A Chromium patch cannot protect a deceptive sender name rendered as text inside a web application.

Researchers will also need to retest the findings after updates. The original work examined specific browser behavior, registered names, and test mailboxes at a particular time. It did not establish that every Chromium build, operating system, font, or mail application will render the characters identically.

Font differences can weaken or strengthen the illusion. At larger sizes, the bar across ө is easier to notice. Inside a compact address bar or sender field, that distinction may become less apparent.

The reported registrations also prove possibility, not widespread exploitation. Public evidence of phishing campaigns using the precise characters would raise the urgency. An absence of such reports would not show the gap is harmless, but it would affect risk prioritization.

For users, the immediate lesson is narrower than “never trust Unicode.” Check unexpected requests through a known route, especially when they involve credentials, payments, or account recovery. A bookmark or password manager provides a better reference than visual inspection alone.

For administrators, inventory the domains that matter most and monitor registrations that resemble them. Require phishing-resistant authentication for sensitive systems. Treat new supplier or payment details as a verification event, not a routine email task.

For product teams, test how applications display internationalized sender addresses and links. Showing a friendly Unicode name without any access to the encoded form can conceal useful evidence. Showing only Punycode can make legitimate international identities unnecessarily hostile.

Chromium IDN spoofing defenses remain substantial, but this research demonstrates that substantial is not complete. The browser blocks obvious mixed-script substitutions and known whole-script tricks, then checks popular and familiar destinations during navigation.

A carefully selected character can still alter the machine comparison without changing the impression seen by a hurried person. That gap is small in code, yet meaningful wherever trust depends on recognizing a name.

The next few months should reveal whether Chromium, registries, and mail providers treat the examples as isolated additions to a list or as evidence that the layers need different assumptions. Until then, organizations should test their own domains, strengthen origin-bound authentication, and stop asking users to make security decisions from typography alone.