Impact

The Tauri shell plugin exposes functionality to execute code and open programs on the system. The open endpoint of this plugin is designed to allow open functionality with the system opener (e.g. xdg-open on Linux). This was meant to be restricted to a reasonable number of protocols like https or mailto by default.

This default restriction was not functional due to improper validation of the allowed protocols, allowing for potentially dangerous protocols like file://, smb://, or nfs:// and others to be opened by the system registered protocol handler.

By passing untrusted user input to the open endpoint these potentially dangerous protocols can be abused to gain remote code execution on the system. This either requires direct exposure of the endpoint to application users or code execution in the frontend of a Tauri application.

You are not affected if you have explicitly configured a validation regex or manually set the open endpoint to true in the plugin configuration.

Technically the scope was never a limitation for the rust side as it is not seen as an enforceable security boundary but we decided to mark the rust crate as affected since the plugin does not need to be a frontend dependency to be exposed.

Patches

The issue has been patched in the 2.2.1 version of the plugin. The plugin now differentiates between an unset scope and an explicit validation disable for the open endpoint.

Workarounds

A way to prevent arbitrary protocols would be setting the shell plugin configuration value open to true.

tauri.conf.json json5 "plugins": { "shell": { "open": true }, }

The above will only allow mailto, http and https links to be opened.

If the open endpoint should not be allowed at all there are two possible workarounds. - Defining a non matching regex like tauri^ in the plugin configuration - Removing shell:default and all instances of shell:allow-open from the capabilities

Alternatively we recommend usage of the opener plugin, as the shell plugin deprecated the open endpoint previously. References

PoC

This is a windows specific proof of concept.

1. Use create-tauri-app to make a new Tauri app. 2. Run tauri add shell to add the shell plugin. 3. Execute await window.TAURIINTERNALS.invoke("plugin:shell|open", {path: "file:///c:/windows/system32/calc.exe"}); in the developer console. 4. Observe the calculator being executed

Tauri is a framework for building binaries for all major desktop platforms. The 1.4.0 release includes a regression on the Filesystem scope check for dotfiles on Unix. Previously dotfiles were not implicitly allowed by the glob wildcard scopes (eg. $HOME/), but a regression was introduced when a configuration option for this behavior was implemented. Only Tauri applications using wildcard scopes in the fs endpoint are affected. The regression has been patched on version 1.4.1.

Impact

This advisory is not describing a vulnerability in the Tauri code base itself but a commonly used misconfiguration which could lead to leaking of the private key and updater key password into bundled Tauri applications using the Vite frontend in a specific configuration.

The Tauri documentation used an insecure example configuration in the Vite guide to showcase how to use Tauri together with Vite.

Copying the following snippet envPrefix: ['VITE', 'TAURI'], from this guide into the vite.config.ts of a Tauri project possibly leads to bundling the TAURIPRIVATEKEY and TAURIKEYPASSWORD into the Vite frontend code and therefore leaking this value to the debug built of a Tauri application.

The value is automatically bundled into debug builds but for production builds it is not embedded, as long as it is not directly referenced in the frontend code. Vite statically replaces these values in production builds. This reduces the amount of affected applications to a very small amount of affected applications.

To verify if you are affected you can search for the private key value or the TAURIPRIVATEKEY variable inside the release build frontend assets (dist/).

Example: grep -r "TAURIPRIVATEKEY" dist/

Using only the envPrefix: ['VITE'], or any other framework than Vite means you are not impacted by this advisory.

Patches

The documentation has been patched but as the root cause is not in Tauri itself the issue is not fixed by updating Tauri. The vite.config.ts configuration of the project needs to be adapted.

We recommend rotating your updater private key if you are affected by this (requires Tauri CLI >=1.5.5). After updating the envPrefix configuration, generate a new private key with tauri signer generate, saving the new private key and updating the updater's pubkey value on tauri.conf.json with the new public key. To update your existing application, the next application build must be signed with the older private key in order to be accepted by the existing application.

Workarounds

The envPrefix: ['VITE'],should be used and the desired TAURI variables manually added. Respective these variables could be added TAURIPLATFORM, TAURIARCH, TAURIFAMILY, TAURIPLATFORMVERSION, TAURIPLATFORMTYPE and TAURIDEBUG without leaking sensitive information.

We urge affected users to implement the workaround as the 1.x branch will not receive a general prevention fix as it would break systems.

References The issue was originally disclosed in our discord here. The affected guide is https://tauri.app/v1/guides/getting-started/setup/vite/.

Update: We lowered the severity from high to low, as the likelihood of impact was found to only affect a very limited amount of applications.

Update2: We changed the affected versions to make clear that after 2.0.0-alpha.16 or 1.5.6 the potentially vulnerable recommendation was no longer visible on our website and should not affect projects by default. A lot of users were confused and we believe this advisory reached the necessary user base.

Tauri's Content Security Policy hardening, which injects a random nonce to restrict script execution, provides zero protection when an application includes data: or blob: in its script-src directive. Per the CSP Level 3 specification, these scheme sources remain active even when a nonce is present, allowing arbitrary script execution without knowing the nonce.

Tauri is a framework for building binaries for all major desktop platforms. Due to missing canonicalization when readDir is called recursively, it was possible to display directory listings outside of the defined fs scope. This required a crafted symbolic link or junction folder inside an allowed path of the fs scope. No arbitrary file content could be leaked. The issue has been resolved in version 1.0.6 and the implementation now properly checks if the requested (sub) directory is a symbolic link outside of the defined scope. Users are advised to upgrade. Users unable to upgrade should disable the readDir endpoint in the allowlist inside the tauri.conf.json.

When a Tauri application uses the dialog plugin's file or folder picker, an attacker with JavaScript execution (XSS) can force the scope expansion to be recursive, granting read/write access to an entire directory tree after a single user click on a normal-looking OS file dialog. The user has no indication that recursive access was granted, and the expanded scope cannot be revoked for the lifetime of the application.

Tauri is a framework for building binaries for all major desktop platforms. The filesystem glob pattern wildcards , ?, and [...] match file path literals and leading dots by default, which unintentionally exposes sub folder content of allowed paths. Scopes without the wildcards are not affected. As allows for sub directories the behavior there is also as expected. The issue has been patched in the latest release and was backported into the currently supported 1.x branches. There are no known workarounds at the time of publication.

The Tauri updater plugin's 'check' IPC command accepts an allowDowngrades boolean parameter directly from frontend JavaScript code. When set to true, it replaces the version comparator from "update must be newer" to "update must be different." Because the default permission set grants allow-check to the webview, any XSS in the app frontend can invoke this command and bypass the only anti-rollback protection the updater offers. Combined with another bug, this enables downgrade attacks without even needing to fake a higher version number.

Summary A flaw in Tauri's islocalurl() function causes it to incorrectly classify remote URLs as trusted local origins on Windows and Android. On these systems, Tauri maps custom URI scheme protocols to http://<scheme>.localhost/ because those platforms' WebView implementations cannot serve custom URI schemes directly.

The issue is that Tauri's check to see if the origin is local, only checks the first subdomain of the URL. An attacker can abuse this by hosting a page on a domain whose subdomain matches the custom scheme of the application (e.g. http://app.attacker.com/)."

Example: - Local URL: app://localhost/ → on Android/Windows: http://app.localhost/ - The check passes for any URL starting with http://app., including http://app.evil.com/

As a result, the attacker page can invoke backend commands that the developer intended to be accessible only to the app's own frontend and that are explicitly restricted from being called by external or remote origins.

Details Vulnerable function:

rust #[cfg(any(windows, targetos = "android"))] let local = { let protocolurl = self.manager().tauriprotocolurl(useshttps); let maybeprotocol = currenturl .domain() .andthen(|d| d.splitonce('.')) // BUG: only splits on first dot .unwrapordefault() .0;

protocols.containskey(maybeprotocol) && scheme == protocolurl.scheme() };

Link: https://github.com/tauri-apps/tauri/blob/1ef6a119b1571d1da0acc08bdb7fd5521a4c6d52/crates/tauri/src/webview/mod.rs#L1680

splitonce('.') discards everything after the first .. For http://app.evil.com/, the extracted label is app. If the application has registered a protocol named app, protocols.containskey("app") returns true and the URL is classified as Origin::Local. The correct check must assert the full domain is exactly <protocol>.localhost.

PoC We created a proof of concept app that can be found here. The app registers a custom app:// protocol and exposes a ping command restricted to local origins only. It provides a button to open a URL in a WebView, pre-filled with https://app.robbe-bc9.workers.dev/, an attacker-controlled page that invokes ping on load. Because the domain's first label matches the registered app protocol, islocalurl() classifies it as a local origin and the command succeeds.

capabilities/main.json contains the following code, which only exposes ping locally:

json { "$schema": "../../../crates/tauri-schema-generator/schemas/capability.schema.json", "identifier": "main", "local": true, "windows": [""], "permissions": [ "sample:allow-ping" ] }

src/lib.rs contains the following code, to register a custom scheme:

rust tauri::Builder::default() .registerurischemeprotocol("app", |ctx, request| { ... })

Impact The attacker page can invoke backend commands that the developer intended to be accessible only to the app's own frontend and that are explicitly restricted from being called by external or remote origins.

The Tauri updater plugin verifies update binaries using minisign signatures, but the signature covers only the raw binary bytes. The update manifest -- which contains the version number, download URL, and signature -- is fetched over TLS but is never itself signed or authenticated. Because the only anti-rollback check compares the manifest's version field against the current version, and that field is unsigned, an attacker who can serve a crafted manifest can force installation of any older signed release without possessing the developer's private key.

The Tauri HTTP plugin validates requested URLs against the application's configured scope allowlist only once, on the initial request. When the remote server responds with an HTTP 3xx redirect, reqwest follows the redirect internally without re-checking the new target URL against the scope. This allows an attacker who controls an allowed URL (or finds an open redirect on an allowed host) to reach disallowed destinations such as cloud metadata endpoints, localhost services, or internal network hosts.

Impact The Tauri IPC is usually strictly isolated from external websites but the isolation can be bypassed by redirecting an existing Tauri window to an external website. This is either possible by an application implementing a feature for users to visit arbitrary websites or due to a bug allowing the open redirect[^open-redirect].

This allows the external website access to the IPC layer and therefore to all configured and exposed Tauri API endpoints and application specific implemented Tauri commands.

Patches This issue has been patched in the latest release and was backported to all previous 1.x releases.

Workarounds Prevent arbitrary input in redirect features. Only allow trusted websites access to the IPC.

References

The feature to enable this behavior in a more constrained way was introduced in the 1.3 release and documentation around this can be found in the documentation.

[^open-redirect]: https://en.wikipedia.org/wiki/Openredirect

Tauri is a framework for building binaries for all major desktop platforms. In versions prior to 1.0.7 and 1.1.2, Tauri is vulnerable to an Incorrectly-Resolved Name. Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it is possible to partially bypass the fs scope definition. It is not possible to traverse into arbitrary paths, as the issue is limited to neighboring files and sub folders of already allowed paths. The impact differs on Windows, MacOS and Linux due to different specifications of valid path characters. This bypass depends on the file picker dialog or dragged files, as user selected paths are automatically added to the allow list at runtime. A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. The issue has been patched in versions 1.0.7, 1.1.2 and 1.2.0. As a workaround, disable the dialog and fileDropEnabled component inside the tauri.conf.json.