Unicode Homoglyph Path Injection in Chromium Native Messaging - TreeChain Labs Inc
ADVISORY: Unicode Homoglyph Path Injection in Chromium — TreeChain Labs
Critical Security Advisory

Unicode Homoglyph Path Injection in Chromium Native Messaging

CVE-Pending · Arbitrary Code Execution via Visually-Identical Filesystem Paths

SeverityCVSS 3.1: 9.6 (Critical)
DateFebruary 18, 2026
ResearcherBrandon Myers, TreeChain Labs
StatusCoordinated Disclosure
Section 01

Executive Summary

A critical vulnerability in the Chromium native messaging implementation allows an attacker to achieve Arbitrary Code Execution and Man-in-the-Middle (MITM) control over secure communication channels between browser extensions and desktop applications.

By exploiting a lack of Unicode normalization in manifest paths, an attacker can redirect browser calls from trusted extensions (e.g., 1Password, Bitwarden, Coinbase Wallet) to a malicious binary using visually identical filesystem paths.

The attack requires only standard user-level access. No privilege escalation. No modification of existing application files. The attacker drops a single poisoned manifest into a user-writable directory.

Impact Scope

Every application using Chrome native messaging is affected across all Chromium-based browsers (Chrome, Edge, Brave, Vivaldi, Opera) on Linux and macOS. Approximately 3.5 billion browser installations are potentially exposed.

Section 02

Technical Proof of Concept

The attack targets the NativeMessagingHosts directory. Chromium reads a JSON manifest and executes the path field without applying NFKC normalization or ASCII validation.

The Path Substitution

Legitimate/opt/1Password/1Password-BrowserSupport
P = U+0050 (Latin P)    B = U+0042 (Latin B)
Malicious/opt/1Password/1Ρassword-ΒrowserSupport
Ρ = U+03A1 (Greek Rho)    Β = U+0392 (Greek Beta)

On Linux (ext4) and macOS (APFS), these are distinct filesystem locations. A standard user can write a poisoned manifest to their local config directory, redirecting all sensitive extension traffic to an attacker-controlled binary.

Byte-Level Proof

Original: 2f6f70742f3150617373776f72642f3150617373776f72642d42726f77736572537570706f7274
Poisoned: 2f6f70742f3150617373776f72642f31cea1617373776f72642dce92726f77736572537570706f7274
                                          ^^^^                    ^^^^
                                      Greek Rho                Greek Beta

Filesystem Verification

fs_test.py
#!/usr/bin/env python3
import os, tempfile, shutil
tmpdir = tempfile.mkdtemp()
orig = os.path.join(tmpdir, "1Password")
fake = os.path.join(tmpdir, "1\u03a1assword")  # Greek Rho U+03A1
os.makedirs(orig); os.makedirs(fake)
open(os.path.join(orig, "t"), "w").write("ORIGINAL")
open(os.path.join(fake, "t"), "w").write("FAKE")
a = open(os.path.join(orig, "t")).read()
b = open(os.path.join(fake, "t")).read()
print("VULNERABLE!" if a != b else "NOT VULNERABLE")
shutil.rmtree(tmpdir)

Result on Linux ext4: VULNERABLE!

Section 03

Impact Matrix: Exploit Validation

TargetAttack VectorVerified ImpactRisk
1PasswordMITM InterceptionIntercepted NmRequestAccounts and vault unlock signals. Demonstrated arbitrary response injection. Engineering team actively reviewing. HackerOne #3543002.CRITICAL
BitwardenCredential TheftTriaged by security team. Assigned CVSS 5.7 (Medium). Sent to engineering for Unicode normalization implementation. HackerOne #3548065.MEDIUM
CoinbaseExtension Spoofing + UI InjectionBuilt working PoC extension using Unicode Fraction Slash (U+2044) in extension name. Chrome’s chrome://extensions page displays the spoofed name as a legitimate system path. PoC demonstrates: fake “Security Update” UI overlay on coinbase.com prompting for recovery phrase, clipboard monitoring for wallet addresses, and wallet traffic interception.CRITICAL
Cisco / DuoMFA BypassFormal PSIRT incident opened (PSIRT-0443474697). Duo developers engaged. Duo Desktop confirmed it does not use native messaging — uses localhost HTTP with origin validation instead.HIGH
Palo Alto NetworksEDR CompromisePSIRT actively triaging. If Cortex XDR or GlobalProtect use native messaging, attacker intercepts endpoint telemetry and suppresses alerts.HIGH
JumpCloudIdentity Token TheftSecurity team reviewing. SSO tokens, LDAP credentials, and device attestation data at risk if native messaging is used.HIGH
UK MoJPersistenceResponded via official channels. Directed submission through HackerOne. Splink-linked datasets (Crown Court, Prison, NHS, DWP, DfE records) accessible through compromised analyst credentials.CRITICAL

Key Evidence: 1Password Interception

pwned_request.txt — Intercepted Native Message
{
  "callbackId": 1725629103,
  "invocation": {
    "type": "NmRequestAccounts",
    "content": {
      "version": 1,
      "userRequested": false,
      "supportsDelegation": true
    }
  }
}

The Chromebook Irony

This research was conducted entirely on a Chromebook — a device Google markets as “Secure by Default.” The browser completely abdicates its role as the trust authority by executing a path containing Greek Rho instead of Latin P without question.

Second Vector: Coinbase Wallet Extension Spoofing

A second, distinct attack vector was discovered in the same research. Chrome does not normalize Unicode in extension names before displaying them on the chrome://extensions page.

By using the Unicode Fraction Slash (U+2044: ) instead of the standard forward slash (U+002F: /), an attacker crafts an extension name that Chrome displays as what appears to be a legitimate system path:

User seesCoinbaseWallet-SecurityUpdate/../../chrome/extensions/coinbase-wallet
Actual nameCoinbaseWallet-SecurityUpdate....chromeextensionscoinbase-wallet
Character⁄ = U+2044 (Fraction Slash) — not U+002F (Forward Slash)

Chrome renders both identically on the extensions management page. The victim believes they are looking at a legitimate Coinbase Wallet installed from a trusted system directory.

The working PoC extension demonstrates:

  1. UI InjectionWhen the victim visits coinbase.com, a fake “Security Update Required” overlay prompts for their 12-word recovery phrase.
  2. Clipboard MonitoringCaptures all copied text — wallet addresses, seed phrases, private keys.
  3. Wallet Traffic InterceptionMonitors all URLs containing “wallet,” “coinbase,” or “metamask.”
  4. Visual Trust ExploitationChrome’s own extensions page displays the spoofed path as legitimate, lending false credibility to the malicious extension.
Same Root Cause, Different Attack Surface

Both the native messaging attack and the extension naming attack exploit the same fundamental failure: Chromium does not normalize Unicode before displaying or executing it. The native messaging vulnerability achieves code execution. The extension naming vulnerability achieves social engineering. Together they demonstrate a systemic Unicode handling failure across multiple Chromium subsystems.

Section 04

Vendor Response Audit

This disclosure was reported to 12 organizations between February 7–16, 2026. Their responses reveal a systemic industry failure: a chaotic mix of validation, denial, and abdication.

Vendors Who Validated

VendorResponseAction Taken
BitwardenTriaged Medium (CVSS 5.7)Sent to engineering team for Unicode normalization review. HackerOne #3548065.
Cisco / DuoFormal PSIRT IncidentPSIRT-0443474697 opened. Duo developers confirmed they use localhost HTTP with origin validation — not native messaging. Secure architecture validated.
Palo Alto NetworksActively TriagingPSIRT acknowledged report, reviewing Cortex XDR and GlobalProtect browser integrations.
1PasswordEngineering ReviewRequested explicit attacker model clarification. Checking hardening around app-extension integration. HackerOne #3543002.
JumpCloudUnder ReviewSecurity team acknowledged report and initiated assessment.
ProtonRisk AcknowledgedConfirmed awareness of native messaging security gaps. Stated risk analysis will be conducted before any future implementation.
UK Ministry of JusticeOfficial ResponseDirected submission via HackerOne. Engaged through formal government vulnerability disclosure process.

Vendors Who Denied

VendorResponseAnalysis
Ledger“Host is untrusted by design”Claims hardware device display verification protects users. Ignores that if the browser connects to the wrong binary (the homoglyph spoof), the attacker becomes the endpoint. Transaction details can be modified before reaching the hardware device. The device faithfully signs what it receives — but what it receives has been manipulated in transit.
KeePassXC“Browser-level issue”Acknowledged the vulnerability is real but pointed to Chromium as root cause. Built their own encryption layer as independent mitigation — which actually validates the severity.

Vendors Who Abdicated

VendorResponseAnalysis
Google / ChromiumWontFixMarked Issue 482538021 as WontFix. Claims user-writable directory access is “by design” and “outside our threat model.” Refuses to implement NFKC normalization — a single function call that would eliminate the entire vulnerability class.
VivaldiRefused to engageInitially provided technical response, then labeled research “AI generated” and terminated correspondence. Used the “AI” label as a kill switch to avoid engaging with verified human research that produced a working exploit.
Mozilla FirefoxRedirectedPointed to Chromium as root cause. Firefox has the same native messaging architecture.
CERT/CCValidated, then deferredConfirmed “design weakness / hardening gap” but deferred to Google as primary CNA. Advised independent publication. When the entity responsible for the vulnerability is also the entity that decides whether to fix it, the system fails.
Industry Dissonance Summary

The vendor responses reveal a fundamental contradiction: Bitwarden and Cisco validate the risk and act on it, while Google — the root cause vendor — refuses to fix a vulnerability that their own downstream partners are scrambling to mitigate. Every downstream browser inherits this vulnerability permanently unless they mitigate independently.

Section 05

The Munich Hypocrisy

In February 2019, Google published a whitepaper at the Munich Security Conference — a stage traditionally reserved for heads of state and defense ministers — titled “How Google Fights Disinformation.”

The paper outlined three pillars of their defense against disinformation:

1. Make Quality Count: Promoting authoritative sources.
2. Counteract Malicious Actors: Removing deceptive content.
3. Give Users Context: Providing tools to identify what is real.

Google claimed that “impersonation and the misrepresentation of ownership” are harms they tackle at scale because they undermine the trust users place in their services.

When presented with a working demonstration that their browser facilitates impersonation at the binary level — allowing a Greek character to masquerade as a Latin character and redirect execution of security-critical software — Google marked it WontFix.

The Contradiction

Google’s public stance (Munich, 2019): “We fight disinformation because fragmentation destroys societies.”

Google’s technical reality (Chromium, 2026): “We allow homoglyph-spoofed paths to fragment the browser’s trust model because fixing it is outside our threat model.”

Institutional Erasure

When the technical evidence on Chromium Issue 482538021 became too heavy to carry, the conversation shifted from the vulnerability to the researcher. Vivaldi’s Security Group, operating on Google’s own infrastructure, posted:

Vivaldi Security Group — Chromium Issue 482538021

“We do not engage with AI. AI generated responses are not acceptable.”

This statement was made after the researcher had provided byte-level filesystem verification, working proof-of-concept code, intercepted 1Password traffic logs, and a detailed technical rebuttal of Vivaldi’s “physical access” framing.

The “AI” label was not a technical assessment. It was a kill switch. By labeling verified human research as bot-generated content, Vivaldi signaled to every other downstream vendor that the data was “noise.” They attacked the medium to avoid the message.

This is the ultimate proof of the Munich Hypocrisy: Google claims to fight the fragmentation of truth, yet they provide the platform for downstream partners to suppress legitimate security research using disinformation tactics.

Timeline of Suppression

February 7, 2026
Vulnerability reported to Google Chrome security via email. Full PoC with byte-level proof provided.
February 9, 2026
Google responds: “We do not triage security bug reports filed via email.” Directs to bug tracker.
February 10, 2026
Bug submitted via Chromium issue tracker. Immediately assessed by triager and closed.
February 10, 2026
Elly Jones (Chromium Security) confirms WontFix. Makes issue public per policy for “invalid issues.” Claims further discussion “will have no value.”
February 10, 2026
Same day: Bitwarden triages report, assigns CVSS 5.7, sends to engineering. Cisco opens formal PSIRT incident. 1Password engages via HackerOne.
February 11, 2026
Vivaldi Security Group provides initial technical response dismissing vulnerability as “physically local.”
February 11, 2026
Researcher provides detailed rebuttal with 5 non-physical attack vectors (supply chain, malicious extensions, phishing, compromised Electron apps, watering holes).
February 11, 2026
Vivaldi responds: “We do not engage with AI. AI generated responses are not acceptable.” Terminates correspondence.
February 17, 2026
Researcher sends final correspondence to Chromium Security with link to Google’s own Munich whitepaper on fighting disinformation.
February 17, 2026
Elly Jones: “I have no further comment on this issue to make.”
Section 06

Full Disclosure Timeline

February 7, 2026
Vulnerability discovered and confirmed on Chromebook (Linux/ChromeOS)
February 7, 2026
Reports submitted to Google Chrome VRP and 1Password (HackerOne #3543002)
February 8, 2026
CERT/CC notified
February 10, 2026
Google/Chromium: WontFix (Issue 482538021)
February 10, 2026
Bitwarden triages report (HackerOne #3548065), Cisco PSIRT incident opened (PSIRT-0443474697)
February 10, 2026
Independent reproduction confirmed by third-party offensive security researcher
February 11, 2026
Reports to Vivaldi, Palo Alto Networks, JumpCloud, Proton, Ledger, Coinbase
February 11, 2026
Palo Alto PSIRT acknowledges and begins triage. Ledger responds: not vulnerable by design.
February 11, 2026
Vivaldi labels research “AI generated,” terminates engagement
February 12, 2026
Cisco/Duo confirms Duo Desktop does not use native messaging. Proton acknowledges risk.
February 14, 2026
UK Ministry of Justice disclosure submitted
February 16, 2026
UK MoJ responds via official channels, directs HackerOne submission
February 16, 2026
1Password requests detailed attacker model clarification
February 18, 2026
Public advisory published — TreeChain Labs. Google’s WontFix designation, public disclosure of the issue by Chromium Security (Comment #6), and refusal to engage further forfeited the standard 90-day responsible disclosure window. The severity of the vulnerability and its impact on billions of users necessitated immediate public disclosure.
Section 07

Remediation & Mitigation

Since Google will not enforce normalization at the engine level, the responsibility falls on extension developers and system administrators.

For Extension Developers

  1. Mandatory NFKC NormalizationBefore passing any path or identifier to an IPC channel, normalize the string. Greek Rho collapses to Latin P. The poisoned path becomes identical to the legitimate one. This is a single function call.
  2. Mixed-Script DetectionIf a manifest path contains characters from both Latin and Greek/Cyrillic scripts, flag it as a spoofing attempt and reject execution.
  3. Binary Integrity ChecksummingVerify a SHA-256 hash of the native host binary against a known-good value stored within the extension package before establishing communication.
  4. Path Character AllowlistingReject any manifest path containing characters outside the ASCII range (U+0020–U+007E).
One-line fix — Python
import unicodedata
def is_safe_path(path):
    normalized = unicodedata.normalize('NFKC', path)
    return all(ord(c) < 128 for c in path) and path == normalized

For System Administrators

  1. Restrict Write AccessAudit ~/.config/google-chrome/NativeMessagingHosts/. Ensure only authorized processes have write permissions.
  2. AppArmor/SELinux ProfilingRestrict Chrome to executing binaries only from a strict allowlist of known-good paths.
  3. Filesystem Integrity MonitoringDeploy AIDE, Tripwire, or osquery to detect unauthorized additions to native messaging directories.
Section 08

The TreeChain Solution

This discovery is the direct result of building the TreeChain Polyglottal Cipher™ — an encryption architecture that operates across 133,387 Unicode characters and 202 languages. By mapping the behavior of the full Unicode space, we identified that the modern web’s trust model is built on a Visual Fallacy — the assumption that if two things look the same, they are the same.

  1. Mandatory NFKC NormalizationEvery string is normalized before any operation. Greek Rho collapses to Latin P. No redirect possible.
  2. Bijective Glyph MappingCharacters map to curated Unicode blocks with one-to-one mappings per epoch window. No ambiguity.
  3. HMAC-Bound Path VerificationIdentifiers are bound to cryptographic authentication. Homoglyph survives normalization? HMAC fails.
  4. Bidirectional Control StrippingDirectional overrides (U+202A–U+202E, U+2066–U+2069) stripped before processing.
  5. Mixed-Script DetectionLatin + Greek in the same token? Flagged as confusable before it touches any filesystem.
  6. Epoch-Bound Rotor RotationGlyph mappings rotate every 300 seconds. No static mapping to poison.
  7. Canonical Hash BindingEvery identifier hashed against its NFKC-normalized form via SHA-256.
The Fundamental Point

The vulnerability and the fix came from the same research. Building encryption safely across the full Unicode space forced us to solve the exact problem that Chrome never thought about.

Section 09

Vulnerability Classification

CWEDescription
CWE-176Improper Handling of Unicode Encoding
CWE-427Uncontrolled Search Path Element
CWE-426Untrusted Search Path
CVSS FactorRating
Attack ComplexityLow
Privileges RequiredLow — standard user, no root
User InteractionNone after initial setup
ScopeChanged — affects all browser sessions
ConfidentialityHigh — full credential access
IntegrityHigh — response injection
AvailabilityLow — attack is silent
Section 10

Conclusion: Picking Up the Pieces

Google’s 2019 Munich whitepaper was titled “The Great Puzzle: Who Will Pick Up the Pieces?”

We now have the answer.

When a security researcher demonstrated that Chrome’s native messaging facilitates binary-level impersonation — the exact “misrepresentation of ownership” Google pledged to fight — the response was WontFix. When the evidence became undeniable, the conversation shifted to attacking the researcher. When downstream vendors asked who was responsible, Google said it was “by design.” When asked for further comment, Google’s security team replied: “I have no further comment on this issue to make.”

By marking this vulnerability WontFix, publicly disclosing the issue themselves (Comment #6), and refusing further engagement, Google forfeited the standard 90-day responsible disclosure window. The severity of the vulnerability — affecting approximately 3.5 billion browser installations and every password manager on every Chromium-based browser — necessitated immediate public disclosure.

The fix is not complex. NFKC normalization is a single function call. Mixed-script detection is a solved problem. Binary integrity verification is standard practice. The tools exist. The knowledge exists. The only thing missing is the will to implement them.

TreeChain Labs built the Polyglottal Cipher to encrypt data across 133,387 Unicode characters and 202 languages. In doing so, we solved this class of vulnerability architecturally — not as a patch, but as a foundational design principle.

Where Google sees an “infeasible” bug, TreeChain sees a call to build a system where identity is structural, not visual. We don’t just fight disinformation — we make it mathematically impossible.

We are picking up the pieces.

Researcher: Bran (Brandon) Myers, Founder & CEO, TreeChain Labs, Inc. (Delaware C-Corporation)

Contact: invest@treechain.ai

References: Unicode TR #36 · Chrome Native Messaging · Google Munich Paper (2019) · Chromium Issue 482538021

Legal Notice: This research was conducted for security research purposes under responsible disclosure principles. No actual user data was accessed or compromised. All testing was performed on researcher-controlled systems. No MoJ systems were accessed. Methodology built entirely from public specifications, open source code, and published documentation.

Explore

View Pricing & Free Tier

Start with 1,000 free API calls/month. No credit card required.

Explore

Take the Break This Challenge

Prove you can crack TreeChain encryption and claim the 100,000 TREE bounty.

Explore

Enterprise Demo

See TreeChain encryption at scale across the global mesh network.

Explore

See the Cryptographic Proofs

NIST-based statistical tests running against live production servers.