The Tauri HTTP plugin validates requested URLs against the application's configured scope allowlist only once, on the initial request. When the remote server responds with an HTTP 3xx redirect, reqwest follows the redirect internally without re-checking the new target URL against the scope. This allows an attacker who controls an allowed URL (or finds an open redirect on an allowed host) to reach disallowed destinations such as cloud metadata endpoints, localhost services, or internal network hosts.
Versions 2.0.0 through 2.6.1 are affected in every configuration and no fix is available for them. From 2.7.0 the plugin can check the scope on each redirect hop, but only when the application sets the scopeRedirects option in its http plugin configuration. A 2.7.0 or later application that does not set it behaves as before and is still affected.
Upgrade to tauri-plugin-http 2.7.0 or later and turn on the new scopeRedirects option. Both steps are needed. The fix is opt-in, so 2.7.0 on its own still follows a redirect out of scope; the option is what makes the plugin check every hop. Tauri made it opt-in because a redirect that leaves the scope now fails, which changes behaviour for apps that were relying on it.
<pre>
{"plugins": {"http": {"scopeRedirects": true}}}
</pre>
Nothing in the 2.0.0 to 2.6.1 range has a fix available.