CVE-2026-95623 in Plugin Http
Summary
by MITRE • 09/22/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability described constitutes a critical security flaw within the Tauri HTTP plugin's request handling mechanism, specifically related to how it manages URL validation during redirection sequences. The core issue stems from an incomplete implementation of access control policies for outbound network requests. In secure application design, particularly in environments where applications interact with external services while potentially exposing sensitive internal resources or cloud metadata endpoints, strict enforcement of allowlists is paramount. This vulnerability arises because the plugin performs a single validation check against the configured scope allowlist only at the moment the initial request is initiated by the frontend code. It fails to re-evaluate the destination URL after any intermediate redirects occur during the HTTP transaction lifecycle.
From a technical perspective, this flaw allows for an open redirect-based bypass of security controls. When a client application sends an HTTP request to a server that responds with a 3xx status code indicating redirection, standard HTTP clients like reqwest automatically follow these redirects without exposing the new intermediate URLs to the calling application's logic or its associated security filters. In this specific scenario, because the Tauri plugin does not intercept and validate each subsequent URL in the redirect chain against the allowlist, an attacker can exploit this gap. By controlling a server that is already on the allowed list, or by finding an open redirect vulnerability within such a trusted host, the attacker can craft a request to the allowed domain that redirects to a disallowed destination. This effectively circumvents the intended security boundary established by the application's configuration.
The operational impact of this vulnerability is severe and multifaceted. It enables unauthorized access to sensitive internal resources that are typically isolated from external network traffic or web-based interactions. Attackers can leverage this flaw to reach cloud metadata endpoints, such as those found in AWS EC2 instances (e.g., 169.254.169.254), which often contain authentication credentials and configuration data for running services. Furthermore, the vulnerability facilitates access to localhost services or internal network hosts that are not intended to be reachable from external contexts. This can lead to significant information disclosure, unauthorized command execution on backend systems, or further lateral movement within a corporate network if the Tauri application is deployed in an enterprise environment with strict segmentation policies. The ability to pivot through trusted domains makes this vulnerability particularly dangerous as it blends malicious traffic with legitimate-looking requests originating from approved sources.
This issue aligns closely with CWE-601, URL Redirection to Untrusted Site (Open Redirect), and more critically, CWE-284, Improper Access Control, due to the failure to enforce security policies during state changes in the request lifecycle. In terms of the MITRE ATT&CK framework, this vulnerability supports techniques related to Discovery, specifically System Information Discovery via cloud metadata endpoints or Internal Network Service Scanning if internal hosts are targeted. It also relates to Defense Evasion by masking malicious traffic as legitimate requests from trusted domains. The lack of continuous validation represents a fundamental breakdown in the principle of least privilege and secure default configurations for network-bound applications.
To mitigate this vulnerability, developers must implement rigorous URL validation at every stage of an HTTP transaction that involves redirection. This requires modifying the underlying request handling logic to intercept redirect responses and validate each new target URL against the configured allowlist before proceeding with the next hop in the chain. If a redirected URL falls outside the permitted scope, the plugin should abort the request immediately rather than following it. Additionally, applications should consider disabling automatic redirects by default or providing an explicit configuration option that requires manual handling of redirect responses, thereby forcing the application logic to perform security checks explicitly. Regular audits of network access policies and penetration testing focused on redirection flows are also recommended to ensure that such bypasses do not exist in other parts of the system architecture.