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

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.

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. 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.

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.