CVE-2026-42184

What it actually does

Tauri 2.x incorrectly validates whether a URL is a trusted local origin on Windows and Android. Because those platforms map an application custom protocol to an internal origin such as http://<scheme>.localhost/, Tauri must distinguish that local origin from arbitrary internet origins. The vulnerable is_local_url() logic checks only the first subdomain/label, allowing a remote domain whose leftmost label matches the application scheme to be treated as local. If a vulnerable Tauri application navigates to or embeds attacker-controlled content at such a domain, the remote page may receive privileges intended only for bundled/local application content, potentially enabling unauthorized Tauri API or IPC access depending on the application’s permissions and exposed commands.

Why it matters to the business

A successful attack can turn a phishing link or attacker-controlled web page into a privileged context inside a desktop or Android application, potentially allowing data theft, unauthorized actions, or application compromise. The risk is highest for Tauri apps that open external links inside the app WebView, expose sensitive commands to the frontend, or rely on origin checks to protect privileged functionality. This issue is not currently in CISA KEV, is not reported as ransomware-used, has low EPSS and no public exploit maturity reported, but the CVSS severity is high because impact can be significant when application-specific preconditions are met.

How an attack unfolds

An attacker first identifies a vulnerable Tauri application on Windows or Android and determines the custom URI scheme it uses. They then register or control a domain where the leftmost DNS label/subdomain matches that scheme, for example https://<scheme>.attacker-controlled.example/. The attacker hosts malicious JavaScript at that URL and convinces a user to open it in a vulnerable application context, such as through a link, redirect, embedded page, OAuth flow, help page, or other external navigation path. Due to the flawed is_local_url() check, Tauri may classify the remote page as if it were the local mapped origin for the application. If the application grants local origins access to privileged Tauri APIs, IPC commands, file operations, system integrations, or sensitive application state, the attacker-controlled page can attempt to invoke those capabilities and perform actions normally reserved for trusted bundled code.

How to fix it

Upgrade Tauri to a fixed version. The advisory states the vulnerability is fixed in Tauri 2.10.3; use 2.10.3 or a later release that includes the fix, and verify the exact applicable version for the package branch in use. Rebuild and redistribute affected desktop and Android applications after upgrading the framework dependency. As defense in depth, restrict navigation to an explicit allowlist of trusted domains, open untrusted external links in the system browser rather than the app WebView, minimize exposed Tauri commands and plugin permissions, validate command callers server-side or in Rust rather than relying only on frontend origin assumptions, and add deny-by-default handling for unexpected remote origins.

How to confirm the fix worked

Confirm dependency manifests and lockfiles resolve Tauri to a fixed release, then rebuild the application and verify the runtime bundle includes the updated Tauri components. Test on Windows and Android specifically, because those platforms are affected by the custom protocol-to-localhost mapping behavior. Create a controlled test domain whose first label matches the application scheme and confirm it is not treated as a local/trusted origin and cannot access privileged APIs or IPC commands. Review application navigation behavior to ensure arbitrary remote pages cannot be loaded inside privileged WebViews. Static validation should include checking for unsafe external navigation handlers, broad protocol allowlists, permissive CSP, and exposed commands that lack independent authorization checks.

Typical attack path

1. Identify a Tauri 2.x application running on Windows or Android and determine its configured custom URI scheme.
2. Create or use an attacker-controlled domain whose first subdomain/leftmost label matches the application scheme.
3. Host malicious web content designed to call exposed Tauri APIs, IPC commands, or application-specific privileged functions.
4. Induce a user to navigate the vulnerable application WebView to the attacker-controlled URL through phishing, redirect, embedded content, login flow abuse, or unsafe external-link handling.
5. Rely on the vulnerable local-origin check to have the remote URL treated as trusted local content.
6. Use any exposed privileged functionality to read data, alter application state, execute sensitive commands, or pivot to further compromise within the application’s permission model.

How to detect it

There are no universal indicators because exploitation depends on each application’s custom URI scheme and attacker-chosen domain. To look for prior exploitation, review application telemetry, WebView/navigation logs, proxy logs, DNS logs, EDR network events, and crash/error logs for remote URLs loaded inside the Tauri app where the leftmost domain label matches the app’s configured custom scheme. Correlate such navigation with privileged IPC/API calls, unexpected file access, shell/process creation, credential access, settings changes, updater activity, account changes, or abnormal requests immediately afterward. On endpoints, inspect logs for the affected application process making network connections to unusual domains followed by sensitive local operations. If the application logs Tauri command invocations, look for commands invoked from non-bundled or unexpected origins. For Android, review app logs, WebView navigation telemetry, mobile EDR, and network telemetry for the same origin-pattern abuse. Threat actor-specific detection is not available from the provided intelligence; focus hunting on the scheme-matching remote-origin pattern and post-navigation privileged behavior.

What your security team should do

• Inventory Tauri-based applications and prioritize Windows and Android builds using Tauri versions from 2.0 through vulnerable 2.x releases.
• Upgrade to Tauri 2.10.3 or later fixed releases and rebuild/redeploy affected applications.
• Treat applications that expose filesystem, shell, credential, updater, deep-link, or account-management commands to the frontend as highest priority.
• Audit WebView navigation, redirect, OAuth, embedded browser, help/documentation, and external-link flows for cases where attacker-controlled URLs can load inside the app.
• Add explicit origin allowlists and deny unexpected remote origins even after applying the framework update.
• Hunt historical telemetry for app WebView navigation to domains whose leftmost label equals the application’s custom scheme.
• Review exposed Tauri commands and plugins for least privilege and require backend-side authorization checks independent of URL origin.
• Because the issue is not KEV-listed, has low EPSS, and has no known mature public exploit, prioritize based on application exposure and privilege level rather than internet-wide exploit likelihood alone.