CVE-2026-66005: Jan API Server Auth Bypass Vulnerability

CVE-2026-66005 Overview

CVE-2026-66005 is a Cross-Origin Resource Sharing (CORS) misconfiguration in the Jan local API server through version 0.8.4. The server replaces user-configured trusted hosts with a wildcard that reflects arbitrary origins with credentials when bound to 0.0.0.0. Network-adjacent attackers, or attackers using Domain Name System (DNS) rebinding, can reach the unauthenticated OpenAI-compatible API. This allows them to perform inference, enumerate models, invoke Model Context Protocol (MCP) tools, and read cross-origin responses. The issue is tracked under CWE-183 (Permissive List of Allowed Inputs) and fixed in commit 3e1c1e7.

Critical Impact
Attackers on the local network can bypass trusted host restrictions to invoke MCP tools and read cross-origin API responses containing user data and model outputs.

Affected Products

Jan through version 0.8.4
Jan local API server (src-tauri/src/core/server/proxy.rs)
Fixed in commit 3e1c1e724f696620d89bb4a9cc18a380e0753757

Discovery Timeline

2026-07-24 - CVE-2026-66005 published to the National Vulnerability Database (NVD)
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-66005

Vulnerability Analysis

The Jan local API server exposes an OpenAI-compatible endpoint used for inference, model enumeration, and MCP tool invocation. When a user binds the server to 0.0.0.0 to enable local area network (LAN) access, the server discards the configured trusted hosts allowlist. It substitutes a wildcard entry (*) that reflects any submitted Origin header back with credentials permitted.

This behavior collapses the same-origin policy for browser-based clients. Any malicious web page loaded by a user on the LAN, or any origin reached via DNS rebinding, can issue authenticated cross-origin requests to the API. The endpoint requires no authentication in the default local deployment. Attackers gain full API access, including inference calls, model enumeration, and tool execution through MCP.

Root Cause

The root cause is in the trusted hosts enforcement logic in src-tauri/src/core/server/proxy.rs. When host == "0.0.0.0", the code replaced trusted_hosts with vec![vec!["*".to_string()]]. This wildcard bypassed the is_valid_host check for every incoming Host header, including attacker-controlled hostnames used in DNS rebinding attacks.

Attack Vector

An attacker hosts a malicious page that resolves a hostname first to a public IP, then rebinds it to 127.0.0.1 or a LAN address after initial page load. The victim's browser sends requests to the rebinding hostname, which the wildcard trusted-host logic accepts. Credentials are reflected, allowing the attacker's JavaScript to read responses containing model output, enumerated models, and MCP tool results.

rust

         .parse()
         .map_err(|e| format!("Invalid address: {e}"))?;
 
-    // When binding to all interfaces (0.0.0.0), the user explicitly wants the server
-    // reachable from any network interface. Allow any host header so LAN clients
-    // (e.g. 192.168.x.x) are not rejected with "Invalid host header".
-    let effective_trusted_hosts = if host == "0.0.0.0" {
-        vec![vec!["*".to_string()]]
-    } else {
-        trusted_hosts
-    };
-
+    // Binding to 0.0.0.0 exposes the server on the LAN, but that must NOT discard
+    // the user's Trusted Hosts allowlist. LAN clients connect via http://192.168.x.x:port
+    // and send that literal IP as the Host header; is_valid_host now accepts loopback
+    // and private-range IP literals, which is safe against DNS rebinding (that sends an
+    // attacker *hostname*, not an IP). Hostnames still require an explicit allowlist entry.
     let config = ProxyConfig {
         prefix,
         proxy_api_key,
-        trusted_hosts: effective_trusted_hosts,
+        trusted_hosts,
         host: host.clone(),
         port,
         enable_server_tool_execution,

Source: GitHub Commit 3e1c1e7

The patch removes the wildcard substitution and enforces the user's allowlist regardless of bind address. A companion patch in src-tauri/utils/src/http.rs accepts literal loopback and private-range IP addresses in the Host header, preserving LAN client access without reopening the DNS rebinding vector.

Detection Methods for CVE-2026-66005

Indicators of Compromise

HTTP requests to the Jan API endpoint with unexpected Origin headers referencing external domains
Response headers containing Access-Control-Allow-Origin reflecting non-local origins alongside Access-Control-Allow-Credentials: true
Unusual Host header values on the Jan port that do not match the configured trusted hosts allowlist
Unexpected MCP tool invocations or model enumeration requests originating from browser user-agents

Detection Strategies

Inspect Jan server access logs for Origin headers not matching the deployed environment's expected client hostnames
Correlate outbound DNS resolutions on client endpoints to hostnames that resolve to both public and private IP ranges, a hallmark of DNS rebinding
Alert on POST requests to /v1/chat/completions or MCP tool endpoints where the Referer originates from an untrusted web origin

Monitoring Recommendations

Monitor endpoints running Jan version 0.8.4 or earlier for network exposure on 0.0.0.0
Capture and review web proxy logs for cross-origin requests targeting local ports commonly used by Jan
Track process telemetry for Jan spawning MCP tool subprocesses following inbound HTTP requests

How to Mitigate CVE-2026-66005

Immediate Actions Required

Upgrade Jan to a release containing commit 3e1c1e7 or later
Bind the Jan API server to 127.0.0.1 instead of 0.0.0.0 if LAN access is not required
Audit the trusted hosts allowlist configuration and remove wildcard entries
Restrict host firewall rules to block inbound access to the Jan API port from untrusted network segments

Patch Information

The vulnerability is fixed in commit 3e1c1e724f696620d89bb4a9cc18a380e0753757, which enforces the trusted hosts allowlist even when binding to 0.0.0.0. Additional context is available in the GitHub Pull Request #8506, the GitHub Issue #8453, and the VulnCheck Advisory.

Workarounds

Bind the API server to the loopback interface (127.0.0.1) until the patch can be applied
Configure a host-based firewall rule to drop inbound traffic to the Jan port from non-loopback sources
Disable MCP server tool execution in the Jan configuration to reduce blast radius if the API is reached
Use browser isolation or a dedicated profile for browsing untrusted content on machines running Jan

bash

# Configuration example: restrict Jan to loopback and block external access
# 1. Start Jan bound to loopback only
jan --host 127.0.0.1 --port 1337

# 2. Linux iptables rule to block external traffic to the Jan port
sudo iptables -A INPUT -p tcp --dport 1337 ! -i lo -j DROP

# 3. Verify the binding
ss -tlnp | grep 1337