CVE-2026-95623: Tauri HTTP Plugin SSRF Vulnerability

CVE-2026-95623 Overview

CVE-2026-95623 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the Tauri HTTP plugin. The plugin validates requested URLs against the application's configured scope allowlist only on the initial request. When the remote server responds with an HTTP 3xx redirect, the underlying reqwest client follows the redirect internally without re-checking the new target URL against the scope. An attacker who controls an allowed URL, or who finds an open redirect on an allowed host, can reach disallowed destinations. These destinations include cloud metadata endpoints, localhost services, and internal network hosts.

Critical Impact
The scope allowlist bypass allows attackers to pivot from an allowed origin to internal infrastructure, exposing cloud instance metadata and unauthenticated internal services to the webview.

Affected Products

Tauri Plugins Workspace — tauri-plugin-http
Tauri desktop applications using the HTTP plugin with a configured scope allowlist
Versions of tauri-plugin-http prior to http-v2.7.0

Discovery Timeline

2026-09-22 - CVE-2026-95623 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-95623

Vulnerability Analysis

The Tauri HTTP plugin exposes an allowlist-based scope mechanism to constrain which URLs the webview can reach. The scope check runs once, at the entry point of the request handler, against the URL supplied by the frontend. Control is then handed to reqwest, which follows HTTP 3xx redirects internally. Because the plugin never inspects intermediate hops, a redirect chain can terminate at any origin the underlying client is willing to connect to.

This pattern maps directly to Server-Side Request Forgery [CWE-918]. A webview constrained to https://api.example.com/* can be steered toward http://169.254.169.254/latest/meta-data/ on AWS, http://127.0.0.1:* for local services, or RFC1918 addresses reachable from the host. The response body is returned to the webview as if it originated from the allowed URL.

Root Cause

The root cause is a missing recursive scope enforcement over redirect hops. The plugin trusts reqwest's built-in redirect follower without registering a per-hop policy that re-validates each Location header against the configured scope. Intermediate URLs are neither logged nor authorized.

Attack Vector

Exploitation requires user interaction and an adjacent-network position, per the CVSS vector. A typical chain works as follows. The attacker hosts or compromises content on an allowed origin. That origin responds with HTTP 302 and a Location header pointing to a disallowed internal URL such as a cloud metadata service. The plugin follows the redirect and returns the metadata response to the webview, where the attacker can read it via the frontend JavaScript context.

typescript

   /**
    * Defines the maximum number of redirects the client should follow.
    * If set to 0, no redirects will be followed.
+   *
+   * When the `scopeRedirects` plugin configuration is enabled, every redirect must
+   * also be allowed by the configured scope, otherwise the request fails
+   * instead of being followed.
    */
   maxRedirections?: number
   /** Timeout in milliseconds */

Source: GitHub Commit 1198a524

The patch introduces a new scope_redirects option in plugins/http/src/config.rs that enforces the scope on every hop:

rust

+#[derive(Debug, Clone, Default, Deserialize)]
+#[serde(rename_all = "camelCase", deny_unknown_fields)]
+pub struct Config {
+    /// Whether the scope is checked on every hop of a redirect chain instead of only on the
+    /// URL requested by the frontend. Defaults to `false`.
+    ///
+    /// When enabled, a redirect to a URL that is not allowed by the scope fails with
+    /// [`Error::UrlNotAllowed`](crate::Error::UrlNotAllowed) instead of being followed, so every
+    /// redirect target must also be part of the scope.
+    #[serde(default)]
+    pub scope_redirects: bool,
+}

Source: GitHub Commit 1198a524

Detection Methods for CVE-2026-95623

Indicators of Compromise

Outbound HTTP requests from Tauri applications to cloud metadata endpoints such as 169.254.169.254, metadata.google.internal, or metadata.azure.com.
Connections from desktop clients to 127.0.0.1, localhost, or RFC1918 ranges that originate from HTTP flows to allowlisted external hosts.
HTTP responses containing Location headers redirecting allowed origins toward link-local, loopback, or private-range destinations.

Detection Strategies

Inspect proxy or endpoint telemetry for redirect chains where the initial request targets an allowed origin but the final host resolves to an internal or link-local address.
Enumerate Tauri applications in the environment and inventory their tauri.conf.json HTTP plugin scope configuration to identify permissive allowlists.
Correlate process-level HTTP activity from Tauri binaries with subsequent connections to metadata or loopback services within short time windows.

Monitoring Recommendations

Alert on any host process making requests to 169.254.169.254 unless explicitly expected for that workload.
Log full HTTP redirect chains at the egress proxy to preserve intermediate hops for forensic review.
Track deployed versions of tauri-plugin-http across managed endpoints and flag versions below http-v2.7.0.

How to Mitigate CVE-2026-95623

Immediate Actions Required

Upgrade tauri-plugin-http to http-v2.7.0 or later in all Tauri applications.
Enable the new scopeRedirects configuration flag so redirect targets are re-validated against the scope on every hop.
Audit the HTTP plugin scope allowlist and remove any origins that are not strictly required.

Patch Information

The fix is available in GitHub Release http-v2.7.0. The commit 1198a524 introduces the scope_redirects option, which causes redirects to disallowed URLs to fail with Error::UrlNotAllowed instead of being followed. See the GitHub Security Advisory GHSA-2rxp-f4w5-6hjr for the vendor advisory.

Workarounds

Set maxRedirections to 0 in the plugin configuration to disable redirect following entirely for requests that do not require it.
Restrict the HTTP plugin scope to specific paths on trusted origins rather than wildcard hosts.
Route Tauri HTTP traffic through an egress proxy that rejects responses containing Location headers pointing to loopback, link-local, or private IP ranges.

bash

# tauri.conf.json HTTP plugin configuration after upgrading to http-v2.7.0
# Enforce scope validation on every redirect hop
{
  "plugins": {
    "http": {
      "scopeRedirects": true
    }
  }
}