Skip to main content
Vulnerability Database/CVE-2026-95625

CVE-2026-95625: Tauri Updater Auth Bypass Vulnerability

CVE-2026-95625 is an authentication bypass flaw in Tauri updater plugin that allows attackers to force installation of older signed releases. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-95625 Overview

CVE-2026-95625 affects the Tauri updater plugin, which verifies update binaries using minisign signatures. The signature covers only the raw binary bytes, while the update manifest containing the version number, download URL, and signature is fetched over TLS without being cryptographically signed. An attacker able to serve a crafted manifest can force installation of any older, legitimately signed release. This constitutes an improper validation of integrity check value weakness [CWE-354]. The flaw does not require the developer's private key, since the attacker reuses valid signatures from prior releases paired with a manipulated version field.

Critical Impact

An attacker positioned to serve or tamper with update manifest responses can downgrade Tauri applications to older signed builds containing known vulnerabilities.

Affected Products

  • Tauri updater plugin (tauri-apps/plugins-workspace)
  • Versions prior to updater-v2.12.0
  • Applications built with the Tauri framework that consume the updater plugin

Discovery Timeline

  • 2026-09-23 - CVE CVE-2026-95625 published to NVD
  • 2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-95625

Vulnerability Analysis

The Tauri updater plugin follows a two-step update flow. First, the client fetches an update manifest from a configured endpoint over TLS. Second, the client downloads the binary referenced by the manifest and verifies it against a minisign signature. The signature is computed over the binary bytes only. The manifest itself, which advertises the version, download URL, and signature string, is never authenticated end-to-end.

The only anti-rollback control compares the manifest's declared version field against the currently installed version. Because that field is unsigned, an attacker can pair a valid signature from an older release with an inflated version number. The client accepts the manifest, downloads the older binary, verifies the genuine signature, and installs it. The result is a controlled downgrade to a build that carries known vulnerabilities the attacker intends to exploit.

Root Cause

The root cause is a missing cryptographic binding between the version claimed by the update endpoint and the artifact that the signature actually authenticates. The minisign signature covers the binary but does not cover the version metadata used for the rollback check.

Attack Vector

Exploitation requires an attacker who can serve or tamper with responses from the update endpoint. This includes a compromised update server, a malicious CDN edge, or a network attacker who can defeat TLS through certificate misissuance or a compromised trust store. No access to the developer's minisign private key is required.

rust
// Patch: plugins/updater/src/config.rs
     pub endpoints: Vec<Url>,
     /// Signature public key.
     pub pubkey: String,
+    /// Require the update signature to carry the version it was signed for, and reject the
+    /// update when that version differs from the one announced by the update endpoint.
+    ///
+    /// The endpoint response is fetched over TLS but is not itself signed, and the signature
+    /// only covers the downloaded artifact. Without this flag, anyone able to serve a crafted
+    /// response can pair an inflated `version` field with the `url` and `signature` of an
+    /// older release and force a downgrade to a genuine but outdated build, since that older
+    /// artifact carries a valid signature.
+    ///
+    /// The signed version is read from the signature's trusted comment, which is covered by
+    /// the signature. Releases signed before the Tauri CLI started recording it carry no
+    /// version, so enabling this rejects them. Re-sign and re-publish every release your users
+    /// can still update from before turning this on.
+    ///
+    /// This is checked independently of the version comparison: it constrains which artifact a
+    /// given version number may resolve to, not whether that version is newer.
+    ///
+    /// The default value of this flag is `false`.
+    pub require_signed_version: bool,
     /// The Windows configuration for the updater.
     pub windows: Option<WindowsConfig>,
 }

Source: GitHub commit 690dcfd694. The patch introduces a require_signed_version flag. When enabled, the client reads the version from the signature's trusted comment and rejects any update whose signed version does not match the announced version.

Detection Methods for CVE-2026-95625

Indicators of Compromise

  • Update manifests announcing a version number that does not match the version embedded in the downloaded artifact metadata.
  • Successful update transactions that result in a lower installed application version than was previously running.
  • Anomalous update endpoint responses served from unexpected origins, edge nodes, or CDN paths.

Detection Strategies

  • Compare the version advertised in fetched update manifests against the version reported by the installed binary after each update cycle.
  • Log update transactions server-side and alert on clients that transition from a higher semantic version to a lower one.
  • Monitor for repeated update manifest fetches from the same client that return divergent version and URL pairings.

Monitoring Recommendations

  • Enable verbose logging in the Tauri updater plugin during rollout to capture manifest URLs, announced versions, and downloaded artifact hashes.
  • Emit telemetry from applications on every update attempt, including the manifest source and the resulting installed version.
  • Instrument the update endpoint to record client IPs and requested manifests for correlation with unexpected downgrade events.

How to Mitigate CVE-2026-95625

Immediate Actions Required

  • Upgrade the Tauri updater plugin to updater-v2.12.0 or later across all applications.
  • Re-sign and re-publish releases with the current Tauri CLI so that signatures carry the version in the trusted comment.
  • Enable require_signed_version in the updater configuration once every release your users can still update from has been re-signed.

Patch Information

The fix is available in updater-v2.12.0 of the tauri-apps/plugins-workspace repository. Details are documented in GHSA-j38x-g3m3-95fr and the corresponding source commit. The patch also introduces SignedVersionMismatch and MissingSignedVersion error variants to surface configuration and tampering conditions.

Workarounds

  • Restrict update endpoints to infrastructure under direct organizational control and enforce certificate pinning where feasible.
  • Publish signed release manifests out-of-band and validate them at the application layer before consuming the updater plugin's manifest response.
  • Monitor deployed application versions centrally and alert on unexpected downgrades pending rollout of the patched plugin.
bash
# Configuration example: enable require_signed_version after re-signing all supported releases
# tauri.conf.json
{
  "plugins": {
    "updater": {
      "endpoints": ["https://updates.example.com/{{target}}/{{current_version}}"] ,
      "pubkey": "<minisign-public-key>",
      "requireSignedVersion": true
    }
  }
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.