Tauri Updater Plugin CVE-2026-95625

Requires an attacker able to serve a crafted update-manifest response to the victim app - i.e. a MITM position over the TLS-protected update channel or control/compromise of the update server or CDN. The target must be a Tauri application using tauri-plugin-updater with auto-update enabled. Exploitation is limited by the TLS transport (the attacker must defeat or terminate TLS, or already control the endpoint) and only permits downgrading to an authentically-signed OLDER release (no arbitrary code signing). The fix is opt-in: requireSignedVersion defaults to false, and releases signed before the Tauri CLI began recording the version carry no signed version, so an attacker can still serve one of those older signatures to bypass the check unless every reachable release is re-signed and re-published.

This is a genuine but conditional integrity flaw, not a high-severity emergency. The provided CVSS 3.1 vector (5.9, AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N) rates it Medium, and the AC:H component correctly reflects the core barrier: the update manifest is fetched over TLS, so an attacker must occupy a privileged network position (defeat/terminate the TLS connection via MITM) or compromise the update server/CDN before a crafted manifest can be served. I disagree with the vendor's PR:H - the attacker needs no privileges on the victim host; the in-path requirement is better modeled through AC/attack-requirement, and the primary impact is integrity (forced downgrade), not confidentiality, so I assess C:N/I:H and a slightly lower score (~5.1). No EPSS score, KEV listing, or public POC is present in the input, so exploitation signals are weak: no public exploit identified at time of analysis. The realistic risk is that of a stepping-stone - a successful downgrade reinstalls a genuine, validly-signed but OUTDATED build, re-introducing whatever vulnerabilities were fixed in later versions. Notably, even the patch does not fully close this by default: the new requireSignedVersion option defaults to false, and older releases signed before the Tauri CLI recorded the version carry no signed version and can still be served to bypass the check, so the effective risk depends heavily on the app's re-signing/opt-in posture.

An attacker who controls the update endpoint (malicious/compromised update server or CDN) or holds a MITM position over the app's TLS update channel serves a crafted manifest that pairs an inflated version number with the download URL and valid minisign signature of an older, genuinely-signed release. The Tauri app's updater validates the signature (which passes, since the old artifact is authentically signed) and installs the outdated build, reintroducing previously-patched vulnerabilities the attacker can then exploit. No developer private key is required; no public exploit code is identified at time of analysis, though the fixing commit publicly documents the mechanism.