Description

The Tauri updater plugin verifies update binaries using minisign signatures, but the signature covers only the raw binary bytes. The update manifest -- which contains the version number, download URL, and signature -- is fetched over TLS but is never itself signed or authenticated. Because the only anti-rollback check compares the manifest's version field against the current version, and that field is unsigned, an attacker who can serve a crafted manifest can force installation of any older signed release without possessing the developer's private key.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-23T09:17:09.393Z",
  "pubdate": "2026-09-23T09:17:09.393Z",
  "executiveSummary": "The Tauri updater plugin is susceptible to an authentication bypass vulnerability due to improper verification of the update manifest. While the update binary itself is verified via minisign, the metadata manifest—which dictates update parameters—remains unauthenticated and unsigned.\nThis design flaw permits an attacker to perform a downgrade attack by serving a crafted manifest containing a legitimate, previously signed binary. By manipulating the unsigned version field in the manifest, an attacker can bypass anti-rollback protections. The impact is significant, as it allows for the forced installation of older, potentially vulnerable versions of the application, even in the absence of the developer's private signing key.\nThe vulnerability resides in the trust model of the updater component, which relies solely on TLS for manifest delivery rather than cryptographically verifying the integrity of the manifest content itself. Consequently, any actor capable of intercepting or spoofing the update delivery process can compromise the versioning integrity of the application. The risk is critical for environments where software supply chain integrity and version consistency are essential for security posture.",
  "technicalDetails": "The root cause of this vulnerability lies in the decoupling of binary integrity verification from manifest authenticity. The Tauri updater plugin implements a two-stage verification process: first, the retrieval of an update manifest via TLS, and second, the cryptographic verification of the downloaded binary using minisign. However, the update manifest is not protected by an independent signature or a Message Authentication Code (MAC).\nThe attack flow begins with an adversary positioning themselves as a Man-in-the-Middle (MitM) or compromising the infrastructure serving the update manifest. Because the manifest is retrieved over TLS, it is susceptible to any scenario where the TLS connection can be intercepted, or where the update server itself is compromised. Once the attacker intercepts the request for the update manifest, they serve a malicious, crafted JSON or equivalent manifest structure.\nIn this crafted manifest, the attacker populates the download URL with a legitimate, older version of the software binary. Because the binary is a signed release from the developer, the minisign verification routine within the Tauri updater successfully validates the binary’s signature, confirming it is authentic and has not been tampered with. Crucially, the updater’s anti-rollback mechanism relies on a simple comparison between the version number provided in the manifest and the currently installed version.\nSince the attacker provides an unsigned manifest, they can manipulate the version field to circumvent these checks. The updater, finding the binary signature valid and the versioning logic satisfied by the attacker-controlled metadata, proceeds to execute the update process. This results in the silent downgrading of the user's application to an older, potentially insecure release. Because the downgrade is functionally treated as a legitimate update by the software, the attacker effectively exploits the lack of authenticity in the manifest to facilitate a version-rollback attack.\nThis vulnerability does not require possession of the developer's private key, as the attacker leverages existing, validly signed old binaries. The post-exploitation impact includes the restoration of historical vulnerabilities that were present in previous versions, enabling the attacker to chain the downgrade with known exploits for the older, re-installed version. This circumvents modern security patches and exposes the end-user to persistent threats."
}