CVE-2026-95623

Executive Summary

CVE-2026-95623 is a server-side request forgery (SSRF) vulnerability in the Tauri HTTP plugin. The plugin validates a request URL against the application's configured scope allowlist only on the initial request and fails to re-validate the target of any HTTP 3xx redirect that the underlying reqwest client follows internally. An attacker who controls a permitted URL, or who can leverage an open redirect on an allowed host, can redirect the Tauri application into reaching disallowed destinations such as cloud metadata endpoints, localhost services, or internal network hosts, resulting in unauthorized read access to otherwise restricted resources. The issue is currently unpatched with no public proof-of-concept, and exploitation requires an adjacent network position plus user interaction, with the scope change (S:C) indicating impact beyond the vulnerable component.

Technical Analysis

The vulnerability is a scoped allowlist bypass rooted in CWE-918 (Server-Side Request Forgery). Tauri applications commonly configure the HTTP plugin with a scope that restricts which URLs the frontend or application logic may request. According to the NVD description, this scope validation is performed only once — on the initial request — and is not re-applied when the remote server responds with an HTTP 3xx redirect.

The HTTP client used by the plugin (reqwest) follows redirects internally by default. When a request to an allowlisted URL receives a 301, 302, 303, 307, or 308 response, reqwest transparently issues a new request to the Location header value. Because the plugin's scope check already completed for the original request and is not repeated for the redirect target, the second (redirected) request reaches a URL that would never have passed the allowlist.

This is a classic "validate-once, follow-blindly" redirect SSRF. The trust boundary is drawn at the point of the initial user-supplied URL rather than at each network hop. The consequence is that the allowlist becomes ineffective whenever an allowed origin can be induced to redirect elsewhere. Two trigger conditions are described:

1. Attacker-controlled allowed URL — the attacker operates a host that legitimately appears on the application's scope allowlist and returns a redirect to an arbitrary disallowed destination.
2. Open redirect on an allowed host — the attacker identifies an open redirect endpoint on a host that is already allowlisted and uses it to pivot the redirect target.

The CVSS vector reflects this mechanism: attack vector is Adjacent (AV:A), attack complexity is High (AC:H) because a suitable allowed URL or open redirect must be identified and the redirect must land successfully, no privileges are required (PR:N), user interaction is required (UI:R) to initiate the request through the application, and scope is changed (S:C) because the vulnerable component's protected boundary is crossed when the request reaches a resource outside the intended allowlist. Confidentiality impact is High (C:H) due to potential retrieval of sensitive internal responses, while Integrity and Availability are None (I:N/A:N).

The impacts described in the source — cloud metadata endpoints, localhost services, and internal network hosts — are reachable precisely because the redirect target is not allowlist-constrained. Cloud instance metadata services commonly expose credential material and configuration data to any client that can reach the link-local address, making this a meaningful credential-exposure primitive. No source-level code, function names, or API parameters beyond those above are disclosed in the available data; the analysis is therefore bounded to the mechanism as described.

Exploitation Scenarios

No public proof-of-concept or exploit code is available; the attack chain below is inferred strictly from the vulnerability class (redirect-following SSRF) and the mechanism described in the NVD entry. No specific function names, endpoints, or parameters beyond "scope allowlist" and "reqwest" are available, and none are fabricated here.

1. Reconnaissance / target identification. The attacker determines whether the target Tauri application uses the HTTP plugin and which URLs are permitted by its scope allowlist. This can be inferred from application behavior or configuration exposed to the attacker. The attacker then either controls a host that matches the allowlist or searches for an open redirect on such a host — searching for any endpoint that accepts a destination parameter and issues a 3xx response to it.

2. Triggering the flaw class. The attacker induces the application to issue an HTTP request to the allowlisted URL. Because the plugin validates only this initial URL, the request passes the scope check. The allowlisted endpoint (attacker-controlled or an open redirect) responds with an HTTP 3xx status and a Location header pointing to a disallowed target.

3. Execution at the vulnerability-class level. The underlying HTTP client follows the redirect without consulting the scope allowlist again. The redirected request is dispatched to the disallowed destination, effectively traversing the allowlist boundary. The destination is chosen by the attacker via the Location header — for example, a cloud metadata endpoint, a localhost service, or an internal-only host. User interaction is required (UI:R) to cause the application to initiate the request.

4. Post-exploitation impact. Responses from the redirected destination are returned through the plugin to the requesting context. This can disclose sensitive data — internal service banners, configuration responses, or cloud metadata containing credentials — turning the SSRF into a credential-access or internal-reconnaissance primitive. The scope change (S:C) reflects that the impact extends beyond the vulnerable component to the internal resources reached. No public evidence indicates in-the-wild exploitation.

Impact Assessment

The primary impact is confidentiality loss (C:H): an attacker can reach and read responses from disallowed destinations including cloud metadata endpoints, localhost services, and internal network hosts. Integrity and availability impacts are rated None, consistent with the CVSS vector, though metadata credential exposure could enable downstream integrity-impacting actions outside the scope of this CVE itself.

Affected systems are Tauri desktop applications that rely on the HTTP plugin's scope allowlist as a security control and that permit any request path capable of following redirects. The blast radius depends on network reachability from the victim host: a client on a corporate network or cloud VM may have access to internal admin panels, service APIs, or instance metadata that should be isolated from the application. The CVSS base score is 5.6 (Medium), driven by the Adjacent attack vector, High complexity, and required user interaction, but offset by High confidentiality impact and a changed scope. Many SSRF-class vulnerabilities are under-scored relative to their real-world consequence when metadata services are reachable, because metadata frequently yields short-lived credentials with a broad permissions footprint. There is no CISA KEV listing, no EPSS score, no known exploit, and no patch, so exposure currently depends entirely on whether the vulnerable plugin configuration is in use and how the application's allowlist can be induced to redirect.

Detection Guidance

Sigma Rule

title: Tauri HTTP Plugin Redirect Scope Bypass (SSRF)
id: 3f9a1c7e-5b2d-4e8a-9c1f-7d6e2a4b8c30
status: experimental
description: Detects process/network behavior consistent with the Tauri HTTP plugin following a 3xx redirect to a disallowed internal or metadata destination, bypassing the configured URL scope allowlist.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-95623
author: valtersit.com
date: 2026/01/01
logsource:
  category: network_connection
  product: windows
detection:
  selection_proc:
    Image|endswith:
      - '\\app.exe'
  selection_dst:
    DestinationIp|cidr:
      - '127.0.0.0/8'
      - '169.254.0.0/16'
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection_proc and selection_dst
fields:
  - Image
  - DestinationIp
  - DestinationPort
falsepositives:
  - Legitimate application requests to internal services within the configured scope
level: medium

YARA Rule

rule Tauri_HTTP_Plugin_Scope_Bypass_Redirect_SSRF
{
    meta:
        description = "Detects indicators of Tauri HTTP plugin scope allowlist bypass via unvalidated redirects (CVE-2026-95623)"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-95623"
        severity = "medium"

    strings:
        $tauri_conf1 = "http" ascii nocase
        $tauri_conf2 = "scope" ascii nocase
        $tauri_conf3 = "allowlist" ascii nocase
        $meta1 = "169.254.169.254" ascii
        $req = "reqwest" ascii nocase
        $redirect = "redirect" ascii nocase

    condition:
        uint16(0) == 0x5A4D or uint32(0) == 0x464C457F
        and (
            (2 of ($tauri_conf*))
            or ($meta1 and 1 of ($req, $redirect))
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-95623 Tauri HTTP Plugin SSRF Redirect to Cloud Metadata"; flow:established,to_server; http.header; content:"Host|3a 20|169.254.169.254"; http.method; content:"GET"; classtype:attempted-recon; sid:202695623; rev:1; reference:cve,2026-95623; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

alert http any any -> any any (msg:"CVE-2026-95623 Redirect to Localhost via Tauri HTTP Plugin"; flow:established,to_server; http.header; content:"Host|3a 20|localhost"; http.referer; content:"tauri"; classtype:attempted-recon; sid:202695624; rev:1; reference:cve,2026-95623;)

Elastic Detection

network where network.transport == "tcp" and
  destination.ip in ("127.0.0.1", "169.254.169.254", "::1") and
  process.name : "*.exe" and
  process.parent.name : "*.exe" and
  event.category == "network"

Splunk SPL Query

index=network sourcetype=netflow OR sourcetype=zeek_conn
| where (dest_ip="169.254.169.254" OR dest_ip="127.0.0.1" OR cidrmatch("10.0.0.0/8", dest_ip) OR cidrmatch("192.168.0.0/16", dest_ip))
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip dest_ip dest_port
| where count > 3
| sort - count
| table first_seen last_seen src_ip dest_ip dest_port count

Wazuh OSSEC Rule

<group name="tauri,ssrf,cve-2026-95623,">
  <rule id="2026956" level="10">
    <decoded_as>json</decoded_as>
    <field name="destination.ip">^169\.254\.169\.254$</field>
    <description>CVE-2026-95623: Possible Tauri HTTP plugin SSRF redirect to cloud metadata endpoint</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,tauri,</group>
  </rule>

  <rule id="2026957" level="8">
    <decoded_as>json</decoded_as>
    <field name="destination.ip">^127\.0\.0\.1$</field>
    <field name="process.name">\.exe$</field>
    <description>CVE-2026-95623: Tauri HTTP plugin request to localhost following redirect</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,tauri,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected version range has been published in the available data.

1. Immediate mitigations.

   • Restrict the HTTP plugin's scope allowlist as tightly as possible; remove any allowlisted host that could act as an open redirect or that the attacker may control.
   • Disable automatic redirect following at the HTTP client layer where the application permits configuration, so each hop is re-evaluated against the scope rather than followed internally.
   • Apply outbound network egress controls that block the application from reaching link-local metadata addresses and other unintended internal destinations.
   • Enforce a metadata-service protection mechanism (e.g., require an authentication token / IMDSv2-style header) so that blindly followed requests cannot retrieve credentials.

2. Patch / upgrade steps.

   • No patch is currently available. Monitor the Tauri project's advisories and release channels for an update that re-validates redirect targets against the configured scope, and apply it as soon as it is published.
   • Until then, treat the plugin's scope allowlist as non-authoritative for redirect security and rely on compensating controls above.

3. Long-term hardening.

   • Validate every request hop (including redirects) against the scope allowlist, not just the initial URL.
   • Adopt an allowlist of outbound destinations at the network layer independent of application-level scope configuration.
   • Log and alert on requests originating from the application to internal, loopback, or metadata address ranges, and review application designs that rely on allowlists as a sole SSRF control.

References

• NVD — CVE-2026-95623: https://nvd.nist.gov/vuln/detail/CVE-2026-95623
• CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• Tauri project security advisories and HTTP plugin documentation: https://tauri.app/
• OWASP — Server-Side Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
• CISA KEV catalog (CVE-2026-95623 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaigns or exploit-in-the-wild evidence have been identified for CVE-2026-95623 in the available data.