CVE-2024-35222 is a medium-severity (CVSS 5.9) CWE-284 vulnerability in tauri. A fix is available for tauri — see the affected versions and patch details below.
iFrames Bypass Origin Checks for Tauri API Access Control
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-35222.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2024-35222 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
tauri🦀tauriReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
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 [email protected]
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 settinginvokeand 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | tauri | all versions | 1.6.7cargo update -p tauri --precise 1.6.7 |
| 🦀crates.io | tauri | ≥ 2.0.0-beta.0&&< 2.0.0-beta.20 | 2.0.0-beta.20cargo update -p tauri --precise 2.0.0-beta.20 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tauri, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update tauri to 1.6.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-35222 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2024-35222 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2024-35222. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2024-35222 in your dependencies?
O3 Security finds CVE-2024-35222 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.