Crafted Web Addresses Evade Browser Warnings Through Character-Matching Weaknesses

Security researchers have identified two weaknesses in Chromium's handling of internationalized domain names (IDNs), demonstrating how deceptive web addresses can appear legitimate without triggering certain browser safeguards.


The findings, published October 3, 2026, by Ian Muscat and Leanne Briffa of Have I Been Squatted, involve Unicode character substitutions that evade hostname display restrictions and lookalike detection.


The researchers registered 20 proof-of-concept domains, including?????.com, which resembles Apple's website, ando?ta.com, which resembles Okta's identity platform.


Unicode Character Substitutions Defeat Display Checks

Chromium normally converts suspicious internationalized hostnames into Punycode, an ASCII representation beginning withxn--, to help users recognize potentially deceptive addresses.


Unlisted Cyrillic Characters Create a Detection Gap

The browser'sSafeToDisplayAsUnicode()function examines character combinations and checks whether an entire domain label resembles a Latin-script name.


However, researchers found that certain Cyrillic characters, including?, can interrupt this detection.


For example, replacing a character in a Cyrillic imitation ofapple.comwith?allows the hostname to pass a check that would otherwise flag a fully confusable spelling.


The researchers call these substitutions breaker characters because they interrupt the matching logic without making the address obviously suspicious.


Normalization Errors Undermine Brand Impersonation Checks

Chromium also compares normalized hostname representations, known as skeletons, against a bundled list of 8,462 popular domains.


Transformation Order Prevents Exact Matches

The second weakness involves how the browser processes diacritics and visually similar characters.


Chromium removes diacritics before applying certain Unicode confusable mappings. Some mappings subsequently introduce combining marks that remain in the final skeleton.


Consequently,o?ta.comdoes not normalize to an exact match forokta.com, while the Apple imitation also avoids the expected comparison.


Additional near-match restrictions compound the problem. The Apple example falls outside the one-edit threshold, while the Okta example benefits from a rule that excludes shorter target names from certain comparisons.


Browser and Email Tests Reveal Different Behaviors

In tests involving Chrome 154 on macOS, the Apple lookalike appeared in Unicode with a valid HTTPS certificate and without the expected lookalike warning.


Email Clients Handle Suspicious Addresses Differently

The researchers also tested 20 internationalized sender domains.
Gmail displayed all tested addresses in Unicode, while Outlook Web presented their Punycode representations.


These observations concern address rendering, not whether the messages would bypass spam filters, reputation checks, or malicious-link scanning.


Importantly, the browser experiments did not establish that the domains could evade every phishing protection or security service.