tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.

View on Cargo

View on Github

Activity

Latest release: 3h ago
Total releases: 222
Cadence: ~7 days
Last 12 months: 18

Reach

Downloads: 30.7M
Stars: 111.1k

Details

License: Apache-2.0 OR MIT
First release: Nov 27, 2019

Releases

Version	Released
`3.0.0-alpha.1` pre	Sep 15, 2026
`3.0.0-alpha.0` pre	Sep 13, 2026
`2.11.5` unknown	Jul 01, 2026
`2.11.4` unknown	Jun 30, 2026
`2.11.3` unknown	Jun 17, 2026
`2.11.2` unknown	May 16, 2026
`2.11.1` unknown	May 06, 2026
`2.11.0` unknown 1 CVE	Apr 30, 2026
`2.10.3` unknown 1 CVE	Mar 04, 2026
`2.10.2` unknown 1 CVE	Feb 04, 2026
`2.10.1` unknown 1 CVE	Feb 02, 2026
`2.10.0` unknown 1 CVE	Feb 02, 2026
`2.9.5` unknown 1 CVE	Dec 09, 2025
`2.9.4` unknown 1 CVE	Nov 30, 2025
`2.9.3` unknown 1 CVE	Nov 13, 2025
`2.9.2` unknown 1 CVE	Oct 29, 2025
`2.9.1` unknown 1 CVE	Oct 22, 2025
`2.9.0` unknown 1 CVE	Oct 20, 2025
`2.8.5` unknown 1 CVE	Sep 01, 2025
`2.8.4` unknown 1 CVE	Aug 25, 2025
`2.8.3` unknown 1 CVE	Aug 24, 2025
`2.8.2` unknown 1 CVE	Aug 19, 2025
`2.8.1` unknown 1 CVE	Aug 18, 2025
`2.8.0` unknown 1 CVE	Aug 18, 2025
`2.7.0` unknown 1 CVE	Jul 20, 2025
`2.6.2` unknown 1 CVE	Jun 27, 2025
`2.6.1` unknown 1 CVE	Jun 26, 2025
`2.6.0` unknown 1 CVE	Jun 24, 2025
`1.8.3` unknown	May 17, 2025
`2.5.1` unknown 1 CVE	Apr 21, 2025
`2.5.0` unknown 1 CVE	Apr 15, 2025
`2.4.1` unknown 1 CVE	Apr 01, 2025
`2.4.0` unknown 1 CVE	Mar 20, 2025
`2.3.1` unknown 1 CVE	Feb 28, 2025
`2.3.0` unknown 1 CVE	Feb 26, 2025
`2.2.5` unknown 1 CVE	Jan 25, 2025
`2.2.4` unknown 1 CVE	Jan 25, 2025
`2.2.3` unknown 1 CVE	Jan 18, 2025
`2.2.2` unknown 1 CVE	Jan 13, 2025
`1.8.2` unknown	Jan 10, 2025
`2.2.1` unknown 1 CVE	Jan 10, 2025
`2.2.0` unknown 1 CVE	Jan 02, 2025
`2.1.1` unknown 1 CVE	Nov 11, 2024
`2.1.0` unknown 1 CVE	Nov 09, 2024
`2.0.6` unknown 1 CVE	Oct 21, 2024
`2.0.5` unknown 1 CVE	Oct 20, 2024
`2.0.4` unknown 1 CVE	Oct 15, 2024
`1.8.1` unknown	Oct 14, 2024
`2.0.3` unknown 1 CVE	Oct 12, 2024
`2.0.2` unknown 1 CVE	Oct 07, 2024

1–50 of 222

Repository

tauri-apps/tauri

Forks: 4.0k
Open issues: 1.3k
Language: Rust
: 5.1/ 10

rust
webview
high-performance
desktop-app
mobile-app
native-app

Dependencies (59)

Depends on

3.0.0-alpha.1

Used by

662

Supply-chain exposure

662 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (7)

CVE-2026-42184 GHSA-7gmj-67g7-phm9 May 06, 2026

Tauri has an Origin Confusion Issue that Allows Remote Pages to Invoke Local-Only IPC Commands

Medium
Network High None

Summary

A flaw in Tauri's is_local_url() 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:

#[cfg(any(windows, target_os = "android"))] let local = { let protocol_url = self.manager().tauri_protocol_url(uses_https); let maybe_protocol = current_url .domain() .and_then(|d| d.split_once('.')) // BUG: only splits on first dot .unwrap_or_default() .0; protocols.contains_key(maybe_protocol) && scheme == protocol_url.scheme() };

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

split_once('.') 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.contains_key("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, is_local_url() classifies it as a local origin and the command succeeds.

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

{ "$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:

tauri::Builder::default() .register_uri_scheme_protocol("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.

Fixed in

2.11.1

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-7gmj-67g7-phm9
https://nvd.nist.gov/vuln/detail/CVE-2026-42184
https://github.com/tauri-apps/tauri

Updated Jun 08, 2026 · Source: OSV.dev
CVE-2024-35222 GHSA-57fm-592m-34r7 May 23, 2024

iFrames Bypass Origin Checks for Tauri API Access Control

5.9 / 10
Medium
Network High Low Required Unchanged High Low Low

Impact

Remote origin iFrames in Tauri applications can access the Tauri IPC endpoints without being explicitly allowed in the dangerousRemoteDomainIpcAccess in v1 and in the capabilities in v2. This bypasses the origin check and allows iFrames to access the IPC endpoints exposed to the parent window.

For this to be exploitable, an attacker must have script execution (e.g. XSS) in a script-enabled iFrame of a Tauri application.

Patches

The patches include changes to wry and the behaviour of Tauri applications using iFrames. Previously, we injected the Tauri IPC initialization script into iFrames on MacOS, which was unintended. This is now also disabled to be consistent with all other supported operating systems.

This means that the Tauri invoke functionality is no longer accessible from iFrames, except on Windows when the origin of the Tauri window and the origin of the iFrame are the same.

We have also added a new protection mechanism to the IPC layer to protect against iFrames directly using the WebView IPC functionality (e.g. via window.ipc.postMessage). This introduces an invoke key (__TAURI_INVOKE_KEY__) which is used to prevent frames that have not been initialized by the Tauri core from sending messages to the Tauri IPC. This key is not used to protect against compromised Tauri windows or WebViews and is only intended to block IPC access from sub-frames.

Unauthorized messages to the Tauri IPC from an iFrame or other non-initialized context will log a warning and the potentially malicious IPC call will be ignored.

Workarounds

These workarounds should only be considered if you are unable to upgrade to the patched Tauri version in time.

As a workaround for v1 Tauri applications, we recommend using a dedicated window for untrusted origins instead of iFrames, or disabling script execution within the iFrame.

For v2 Tauri applications targeting Linux, it is possible to use either a dedicated window or multiple WebViews in the main window to simulate iFrame behavior. On other platforms, it is only possible to use dedicated windows or disable script execution inside the iFrame, as described for v1.

References

If you have any questions or comments about this advisory:

Open an issue in tauri or Email us at security@tauri.app

The original submissions from the reporter:

Context

This is following up on the comments here: https://github.com/tauri-apps/tauri/issues/8316, and here: https://discord.com/channels/616186924390023171/1227969106091966475. I was asked to submit my findings as a vulnerability report.

Firstly, thank you to all of you from the core team that helped out and guided me through understanding this issue! Huge fan of Tauri, and I'm excited to see it succeed!

Summary

In short, any iframe you add in your Tauri frontend will get access to Tauri APIs, even in isolation mode.

Any embedded iframe that you don't own will be able to invoke the same APIs your app does. While isolation mode allows for finer grained control of what Tauri APIs can be called, it is not possible to determine if a request is coming your own app, or from a potentially malicious iframe.

This means your app could be open to malicious iframe being able to execute any command your app can, and there doesn't seem to be a mechanism to filter these out.

Details

I'm not an expert in Tauri source code, so I can't be sure I'm on the right track here, but I assume this has to do with how the webview is bootstrapped with the Tauri APIs.

I know there's various handlers that get set, such as opening target="_blank" links via a shell command, and of course setting invoke and other such APIs. Sounds like the issue is somewhere there and the APIs are being injected where they shouldn't.

Technically it seems that an attacker couldn't actually receive a response from the command it executes. Tauri IPC can't route the response back to the invoking iframe, but the action is still executed, with the response just being dropped. You see these messages in the logs:

[Warning] [TAURI] Couldn't find callback id 3399436348 in window. This happens when the app is reloaded while Rust is running an asynchronous operation.

PoC

Repository with reproduction steps: https://github.com/begleynk/tauri-sandbox-iframe-escape-poc

Building on that POC, here is a video of a Codepen iframe running inside an isolation mode Tauri app, invoking the same "Greet" command the frontend is invoking.

https://github.com/tauri-apps/tauri/assets/1065208/8efd5f9d-3116-4068-b98b-6ace7de9261c

This is done with the following code running inside Codepen:

window.__TAURI_INVOKE__("greet", { name: "From CodePen" })

Impact

Valid commands with potentially unwanted consequences ("delete project", "transfer credits", etc.) could be invoked by an attacker that controls the content of an iframe running inside a Tauri app.

Fixed in

1.6.72.0.0-beta.20

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-57fm-592m-34r7
https://nvd.nist.gov/vuln/detail/CVE-2024-35222
https://github.com/tauri-apps/tauri/issues/8316
https://github.com/tauri-apps/tauri/commit/d950ac1239817d17324c035e5c4769ee71fc197d
https://github.com/tauri-apps/tauri/commit/f6d81dfe0871e0ccd012e5190d41e3767e733608
https://github.com/tauri-apps/tauri

Updated May 23, 2024 · Source: OSV.dev
CVE-2023-34460 GHSA-wmff-grcw-jcfm Jun 21, 2023

Tauri vulnerable to Regression on Filesystem Scope Checks for Dotfiles

4.8 / 10
Medium
Adjacent Low High None Changed Low Low None

Impact

The 1.4.0 release includes a regression on the filesystem scope check for dotfiles on Linux and macOS.

Previously dotfiles (eg. $HOME/.ssh/) 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 and dotfiles were implicitly allowed.

Only Tauri applications using wildcard scopes in the fs endpoint are affected. Only macOS and Linux systems are affected.

Patches

The regression has been patched on v1.4.1.

Workarounds

There are no known workarounds at this time, users should update to v1.4.1 immediately.

References

See the original advisory for more information.

For more Information

If you have any questions or comments about this advisory:

Open an issue in tauri Email us at security@tauri.app

Affected versions

1.4.0

Fixed in

1.4.1

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5
https://github.com/tauri-apps/tauri/security/advisories/GHSA-wmff-grcw-jcfm
https://nvd.nist.gov/vuln/detail/CVE-2023-34460
https://github.com/tauri-apps/tauri/pull/6969#discussion_r1232018347
https://github.com/tauri-apps/tauri/pull/7227
https://github.com/tauri-apps/tauri/commit/066c09a6ea06f42f550d090715e06beb65cd5564

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-31134 GHSA-4wm2-cwcf-wwvp May 03, 2023

Tauri Open Redirect Vulnerability Possibly Exposes IPC to External Sites

4.8 / 10
Medium
Adjacent Low Low Required Changed Low Low None

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.

Fixed in

1.0.91.1.41.2.5

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-4wm2-cwcf-wwvp
https://nvd.nist.gov/vuln/detail/CVE-2023-31134
https://github.com/tauri-apps/tauri/commit/9c0593c33af52cd9e00ec784d15f63efebdf039c
https://en.wikipedia.org/wiki/Open_redirect
https://github.com/tauri-apps/tauri
https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0.9

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2022-46171 GHSA-6mv3-wm7j-h4w5 Dec 22, 2022

Tauri Filesystem Scope Glob Pattern is too Permissive

6.8 / 10
Medium
Adjacent Low Low None Changed High None None

Impact

The filesystem glob pattern wildcards *, ?, and [...] match file path literals and leading dots by default, which unintentionally exposes sub folder content of allowed paths.

Example: The fs scope $HOME/*.key would also allow $HOME/.ssh/secret.key to be read even though it is in a sub directory of $HOME and is inside a hidden folder.

Scopes without the wildcards are not affected. As ** allows for sub directories the behavior there is also as expected.

Patches

The issue has been patched in the latest release and was backported into the currently supported 1.x branches.

Workarounds

No workaround is known at the time of publication.

References

The original report contained information that the dialog.open component automatically allows one sub directory to be read, regardless of the recursive option.

Imagine a file system looking like

o ../ o documents/ - file.txt - deeper/ o deep_file.txt

Reproduction steps:

Trying to load “file.txt” or “deep_file.txt” doesn’t work. Expected

Select “documents” as folder to open(ie. with window.TAURI.dialog.open)

Trying to load “file.txt” works. Expected

Trying to load “deep_file.txt” also works, which isn’t expected

The recursive flag is used in https://github.com/tauri-apps/tauri/blob/cd8c074ae6592303d3f6844a4fb6d262eae913b2/core/tauri/src/scope/fs.rs#L154 to scope the filesystem access to either files in the folder or to also include sub directories.

The original issue was replicated and further investigated.

The root cause was triaged to the glob crate facilitating defaults, which allow the * and [...] to also match path literals.

MatchOptions { case_sensitive: true, require_literal_separator: false, require_literal_leading_dot: false }

This implicated that not only the dialog.open component was affected but rather all fs scopes containing the * or [...] glob. During this investigation it became obvious that the current glob matches would also match hidden folder (e.g: .ssh) content by default, without explicitly allowing hidden folders to be matched. This is not commonly expected behavior in comparison to for example bash.

The new default Match options are:

MatchOptions { case_sensitive: true, require_literal_separator: true, require_literal_leading_dot: true }

Another note security relevant for developers building applications interacting with case sensitive filesystems is, that the case_sensitive option only affects ASCII file paths and is not valid in Unicode based paths. This is considered a known risk until the glob crate supports non-ASCII file paths for this type of case sensitive matching.

For more Information

If you have any questions or comments about this advisory:

Open an issue in tauri Email us at security@tauri.app

Fixed in

1.0.81.1.31.2.32.0.0-alpha.2

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5
https://nvd.nist.gov/vuln/detail/CVE-2022-46171
https://github.com/tauri-apps/tauri/commit/14d567f7ecb25a6d1024cf3d796f86aee89d0dd4
https://github.com/tauri-apps/tauri/commit/72389b00d7b495ffd7750eb1e75a3b8537d07cf3
https://github.com/tauri-apps/tauri/commit/f0602e7c294245ab6ef6fbf2a976ef398340ef58
https://github.com/tauri-apps/tauri

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2022-41874 GHSA-q9wv-22m9-vhqh RUSTSEC-2022-0091 Nov 08, 2022

Tauri Filesystem Scope can be Partially Bypassed

2.3 / 10
Low
Local High High Required Changed Low None None

Impact

Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it was possible to partially bypass the fs scope definition. It was not possible to traverse into arbitrary paths, as the issue was 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.

On Linux or MacOS based systems it was possible to use the *, ** and [a-Z] patterns inside a path, which allowed to read the content of sub directories and single character files in a folder, where only specific files or the directory itself were allowed.

On Windows [a-Z] was the possible bypass pattern, as * is not treated as a valid path component. This implies that only single character files inside an already allowed directory were unintentionally accessible.

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. This means the issue by itself can not be abused and requires further intentional or unintentional privileges.

Workaround

Disable the dialog and fileDropEnabled component inside the tauri.conf.json.

Patches

The issue has been resolved in #5237 and the implementation now properly escapes the special characters. The patch has been included in releases: 1.0.7, 1.1.2 and 1.2.0

For more information

This issue was initially reported by MessyComposer in #5234.

If you have any questions or comments about this advisory:

Open an issue in tauri Email us at security@tauri.app

Fixed in

1.0.71.1.2

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-q9wv-22m9-vhqh
https://nvd.nist.gov/vuln/detail/CVE-2022-41874
https://github.com/tauri-apps/tauri/issues/5234
https://github.com/tauri-apps/tauri/pull/5237
https://github.com/tauri-apps/tauri
https://rustsec.org/advisories/RUSTSEC-2022-0091.html

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2022-39215 GHSA-28m8-9j7v-x499 RUSTSEC-2022-0088 Sep 16, 2022

Tauri's readDir Endpoint Scope can be Bypassed With Symbolic Links

5.8 / 10
Medium
Network Low None None Changed Low None None

Impact

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.

Patches

The issue has been resolved in https://github.com/tauri-apps/tauri/pull/5123 and the implementation now properly checks if the requested (sub) directory is a symbolic link outside of the defined scope.

Workarounds

Disable the readDir endpoint in the allowlist inside the tauri.conf.json.

For more information

This issue was initially reported by martin-ocasek in #4882.

If you have any questions or comments about this advisory:

Open an issue in tauri

Email us at security@tauri.app

Fixed in

1.0.6

References

https://github.com/tauri-apps/tauri/security/advisories/GHSA-28m8-9j7v-x499
https://nvd.nist.gov/vuln/detail/CVE-2022-39215
https://github.com/tauri-apps/tauri/issues/4882
https://github.com/tauri-apps/tauri/pull/5123
https://github.com/tauri-apps/tauri/pull/5123/commits/1f9b9e8d26a2c915390323e161020bcb36d44678
https://github.com/tauri-apps/tauri/commit/bb178829086e80916f9be190f02d83bc25802799

Updated Nov 08, 2023 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

pre 2
unknown 220

222 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More