Tauri Plugin Updater
Monthly
Tauri applications that use the tauri-plugin-updater crate with auto-update enabled can be forced to downgrade to an older, authentically signed release, because the update manifest is fetched over TLS but is never itself signed or authenticated. An attacker who can serve a crafted manifest response - through a man-in-the-middle position on the update channel or by controlling/compromising the update server or CDN - can pair an inflated version field with the URL and minisign signature of an older release, and the plugin's only anti-rollback check compares that unsigned version field against the currently installed version. The assessment scores this as an integrity flaw (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) that is genuinely exploitable but conditional on defeating or terminating TLS or already owning the update endpoint, and it is limited to downgrading to releases that carry a valid developer signature - it does not permit signing arbitrary code. No public exploit was identified at time of analysis and the flaw is not known to be actively exploited (no CISA KEV listing); a vendor patch (updater 2.12.0) is available but the hardening option it introduces defaults to off.
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.
Tauri applications that use the tauri-plugin-updater crate with auto-update enabled can be forced to downgrade to an older, authentically signed release, because the update manifest is fetched over TLS but is never itself signed or authenticated. An attacker who can serve a crafted manifest response - through a man-in-the-middle position on the update channel or by controlling/compromising the update server or CDN - can pair an inflated version field with the URL and minisign signature of an older release, and the plugin's only anti-rollback check compares that unsigned version field against the currently installed version. The assessment scores this as an integrity flaw (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) that is genuinely exploitable but conditional on defeating or terminating TLS or already owning the update endpoint, and it is limited to downgrading to releases that carry a valid developer signature - it does not permit signing arbitrary code. No public exploit was identified at time of analysis and the flaw is not known to be actively exploited (no CISA KEV listing); a vendor patch (updater 2.12.0) is available but the hardening option it introduces defaults to off.
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.