Skip to main content

Tauri Updater Plugin CVE-2026-95624

| EUVDEUVD-2026-84577 MEDIUM
Improper Access Control (CWE-284)
2026-09-22 JFROG GHSA-wqjv-7vqv-x3mj
6.8
CVSS 3.1 · Vendor: JFROG
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Achieve XSS in Tauri app webview
  2. Delivery
    Invoke plugin:updater|check with allowDowngrades:true
  3. Exploit
    Relax comparator to 'must be different'
  4. Execution
    Serve older validly-signed release from update feed
  5. Impact
    Downgrade app reintroducing patched vulnerabilities

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK

1 technique across 1 tactic: Defense Evasion

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires all of: (1) a pre-existing XSS vulnerability in the Tauri application's frontend to run attacker JavaScript in the webview; (2) the app using tauri-plugin-updater 2.8.0 through 2.11.x with the default permission set that grants allow-check to the webview; (3) the application NOT having set a custom Builder::default_version_comparator, which takes precedence and neutralizes the flag; and (4) an attacker-controlled or compromised update endpoint capable of serving an older, still-validly-signed release (the updater verifies artifact signature but not advertised version). The description further notes the strongest downgrade path is 'combined with another bug.' Limiting factors: the XSS foothold prerequisite, the need to influence the update feed, and UI:R interaction all constrain realistic exploitation despite the network vector and lack of authentication.

Impact

This is a genuine but conditional integrity/broken-access-control issue, not a drop-everything emergency. The vendor CVSS of 6.8 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) correctly reflects the tension: the attack surface is network-reachable and needs no authentication (PR:N), but AC:H captures that exploitation is not self-contained - it presupposes a pre-existing XSS in the app frontend AND, per the description, chaining with 'another bug' plus a malicious/compromised update endpoint. No EPSS score, KEV entry, POC, or SSVC data is provided, so exploitation status is: no public exploit identified at time of analysis. The C:H/I:H rating is arguably generous for the direct primary impact, which is really integrity - silently installing an older, validly-signed release (a downgrade), thereby reintroducing previously-patched vulnerabilities; confidentiality impact is indirect/downstream rather than immediate. Net: prioritize patching for apps that ship the updater plugin, but the XSS-prerequisite and update-feed-control requirements make mass, opportunistic exploitation unlikely. Missing signals (no EPSS/KEV/POC) mean risk is inferred from CVSS and the vendor advisory rather than observed exploitation.

Exploit ScenarioDerived

An attacker who has achieved XSS in a Tauri app's webview injects JavaScript that calls the default-permitted 'plugin:updater|check' IPC command with allowDowngrades:true, flipping the version comparator from 'must be newer' to 'must be different.' Combined with a compromised or attacker-influenced update endpoint serving an older but still validly-signed release, the app downgrades itself to a version containing known-exploitable flaws. No public exploit code is identified at time of analysis; the chain requires a pre-existing XSS foothold.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 22, 2026

Downgrade attacks against the Tauri updater plugin (tauri-plugin-updater) 2.8.0 through 2.11.x are possible because the plugin's check IPC command accepts an allowDowngrades boolean directly from frontend JavaScript, letting any code running in the app webview flip the version check from "update must be newer" to "update must be different." Where the default permission set grants allow-check to the webview, an attacker who already has an XSS foothold in the application frontend can invoke this command unauthenticated and, if they also control or compromise the update endpoint to serve an older but still validly signed release, force the app to roll back to a vulnerable version. Exploitation is conditional - it requires a pre-existing XSS, the default permission set, no custom Rust-side version comparator, and influence over the update feed - and carries a user-interaction requirement (UI:R); no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV. The practical impact is an integrity and access-control failure (our assessment scores it C:N/I:H/A:N) rather than a confidentiality compromise.

RemediationAI

Upgrade tauri-plugin-updater to the vendor-released fix version updater-v2.12.0 (commit 1308bfa399b962b3977c767100a6339d1cbfdd20), which removes allowDowngrades from the check command and makes downgrade tolerance an application-level config value defaulting to false - see https://github.com/tauri-apps/plugins-workspace/releases/tag/updater-v2.12.0 and the advisory at https://github.com/tauri-apps/tauri/security/advisories/GHSA-rjc6-5hfg-grp9. If upgrading immediately is not possible, apply these compensating controls, each with known trade-offs: (1) remove or narrow the allow-check permission from the default permission set so the webview can no longer call plugin:updater|check - this breaks any frontend-initiated update checks and forces checks to be driven from Rust; (2) set an explicit Builder::default_version_comparator in your Rust code, which takes precedence over the config flag and neutralizes the allowDowngrades parameter entirely - this requires code changes and a rebuild but has no runtime side effects; (3) treat the underlying XSS as the true entry point and remediate it, since the XSS prerequisite is what turns this into a live downgrade path; (4) where feasible, protect the update endpoint and manifest so an attacker cannot serve an older validly signed release, since the updater validates artifact signatures but not the advertised version number. Note this is a breaking API change: frontend code passing allowDowngrades to check must be updated, and any intentional downgrade capability must be re-expressed as the plugins.updater.allowDowngrades configuration value (or left to a custom comparator).

Affected VersionsENISA

tauri-plugin-updater 2.8.0 <2.12.0

Affected Packages

euvd tauri_plugin_updater fix: 2.12.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Tauri is a Rust framework for building desktop applications whose UI is rendered by a webview running HTML/JavaScript; the updater is distributed as the separate tauri-plugin-updater crate and communicates with frontend code over Tauri's IPC bridge. The plugin:updater|check command originally accepted an allowDowngrades: Option<bool> argument, and when true it replaced the builder's version comparator with a lambda that only required update.version != current instead of update.version > current, silently overriding the anti-rollback comparator the application had configured in Rust. This is CWE-284 (Improper Access Control): a security-critical policy decision (which versions may be installed) was exposed as a parameter to a lower-trust origin (the webview), and the default permission set granting allow-check made that parameter reachable from frontend JavaScript. The upstream fix in commit 1308bfa removes the parameter from the IPC command and from the JS CheckOptions interface, relocates the setting to the plugin's application-level configuration (plugins.updater.allowDowngrades, default false, with a allow-downgrades alias), and explicitly makes a custom Builder::default_version_comparator take precedence so the config flag is ignored when the app sets its own comparator. The commit message also highlights a key architectural wrinkle: the updater verifies the signature of the downloaded artifact but not the version advertised by the update endpoint, so a downgrade to a previously released, validly signed-and-vulnerable build passes signature validation - the version comparator was the only anti-rollback guard.

Know when Tauri Plugin Updater gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (JFROG) PRIMARY 6.8 MEDIUM
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
vuln.today AI 5.3 MEDIUM

AC:H because exploitation needs a pre-existing XSS plus a controllable update feed and a chained second bug; PR:N as the check command is default-granted; primary impact is integrity (forced downgrade), so I:H, C:N, A:N.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (JFROG).

CVSS VectorVendor: JFROG

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score
0.4%
Top 62% exploitable
Prevalence
Low
updater plugin is a subset of apps built on the niche Tauri desktop framework
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Total

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy