CVE-2026-30924: qui (qBittorrent Web Interface) CSRF Vulnerability

CVE-2026-30924 Overview

CVE-2026-30924 is a critical CORS (Cross-Origin Resource Sharing) misconfiguration vulnerability affecting qui, a web interface for managing qBittorrent instances. Versions 1.14.1 and below implement a permissive CORS policy that reflects arbitrary origins while returning Access-Control-Allow-Credentials: true, allowing any external webpage to make authenticated requests on behalf of logged-in users.

This vulnerability enables attackers to trick victims into loading malicious webpages that silently interact with the qui application using the victim's authenticated session. The potential impact includes exfiltration of sensitive data such as API keys and account credentials, and even full system compromise through the built-in External Programs manager.

Critical Impact

Attackers can achieve full system compromise by exploiting the External Programs manager feature, steal API keys and credentials, and execute arbitrary authenticated actions on behalf of logged-in users through a simple social engineering attack.

Affected Products

• qui (qBittorrent web interface) versions 1.14.1 and below
• autobrr/qui project installations accessible via non-localhost hostnames

Discovery Timeline

• 2026-03-19 - CVE-2026-30924 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-30924

Vulnerability Analysis

This vulnerability stems from an insecure CORS configuration in the qui web application (CWE-942: Permissive Cross-domain Policy with Untrusted Domains). The application's API server was configured to reflect any origin in CORS responses while simultaneously allowing credentials to be included in cross-origin requests.

When a web application sets Access-Control-Allow-Credentials: true alongside a permissive AllowOriginFunc that returns true for any origin, browsers permit cross-origin requests from attacker-controlled websites to include cookies and authentication headers. This effectively bypasses the same-origin policy, allowing malicious sites to perform authenticated actions on behalf of users.

The attack requires the victim to access the qui application via a non-localhost hostname and then visit an attacker-controlled webpage. This makes highly targeted social-engineering attacks the most likely real-world exploitation scenario.

Root Cause

The root cause lies in the CORS middleware configuration within internal/api/server.go. The original implementation used a permissive AllowOriginFunc that unconditionally returned true for all origins:

AllowOriginFunc: func(origin string) bool { return true },

Combined with AllowCredentials: true, this configuration allowed any website to make authenticated cross-origin requests to the qui API, completely undermining the browser's same-origin security model.

Attack Vector

The attack vector is network-based and requires user interaction. An attacker would:

1. Craft a malicious webpage containing JavaScript that makes authenticated requests to the victim's qui instance
2. Lure the victim (who is logged into qui via a non-localhost hostname) to visit the malicious page
3. The malicious JavaScript executes API calls using the victim's authenticated session
4. The attacker can exfiltrate API keys, credentials, or abuse the External Programs manager for remote code execution

The security patch restricts CORS to an explicit allowlist rather than accepting all origins:

// VULNERABLE CODE (removed):
// CORS - mirror autobrr's permissive credentials setup
corsMiddleware := cors.New(cors.Options{
    AllowCredentials: true,
    AllowedMethods:   []string{"HEAD", "OPTIONS", "GET", "POST", "PUT", "PATCH", "DELETE"},
    AllowedHeaders:   []string{"Accept", "Authorization", "Content-Type", "X-API-Key", "X-Requested-With"},
    AllowOriginFunc:  func(origin string) bool { return true },
    MaxAge:           300,
    Debug:            false,
})
r.Use(corsMiddleware.Handler)

// PATCHED CODE:
// CORS is disabled by default. Enable only for explicit trusted origins.
if len(s.config.Config.CORSAllowedOrigins) > 0 {
    corsMiddleware := cors.New(cors.Options{
        AllowCredentials: true,
        AllowedOrigins:   s.config.Config.CORSAllowedOrigins,
        AllowedMethods:   []string{"HEAD", "OPTIONS", "GET", "POST", "PUT", "PATCH", "DELETE"},
        AllowedHeaders:   []string{"Accept", "Authorization", "Content-Type", "X-API-Key", "X-Requested-With"},
        MaxAge:           300,
        Debug:            false,
    })
    r.Use(corsMiddleware.Handler)
}

Source: GitHub Commit 424f7a0

Detection Methods for CVE-2026-30924

Indicators of Compromise

• Unexpected cross-origin requests in web server access logs from unfamiliar referrer domains
• API calls to sensitive endpoints (External Programs manager, credential retrieval) from external origins
• Session activity from IP addresses or user agents inconsistent with legitimate user patterns
• Unauthorized modifications to External Programs configurations

Detection Strategies

• Monitor HTTP request logs for Origin headers that don't match expected legitimate origins
• Implement alerting on API calls to sensitive endpoints that include cross-origin request indicators
• Review server configuration for permissive CORS settings that allow credential-based cross-origin requests
• Audit access logs for patterns indicating automated or scripted API abuse

Monitoring Recommendations

• Enable detailed access logging on qui instances and monitor for anomalous cross-origin requests
• Implement network monitoring to detect potential data exfiltration to external domains
• Set up alerts for any modifications to the External Programs manager configuration
• Regularly audit session activity for signs of unauthorized access or account takeover

How to Mitigate CVE-2026-30924

Immediate Actions Required

• Update qui to a version containing the security fix (commit 424f7a0de089dce881e8bbecd220163a78e0295f or later)
• Restrict qui access to localhost or trusted network segments only
• Review and rotate any API keys or credentials that may have been exposed
• Audit External Programs manager configurations for unauthorized changes
• Implement network-level access controls to limit exposure

Patch Information

The vulnerability has been addressed in commit 424f7a0de089dce881e8bbecd220163a78e0295f. The fix disables CORS by default and requires explicit configuration of trusted origins via the CORSAllowedOrigins setting. Users should upgrade to a version containing this commit and configure only necessary trusted origins.

For detailed patch information, see the GitHub Security Advisory.

Workarounds

• Access qui exclusively via localhost or 127.0.0.1 to prevent cross-origin exploitation
• Place qui behind a reverse proxy that strips or validates CORS headers
• Implement network segmentation to prevent external access to qui instances
• Use a web application firewall (WAF) to block suspicious cross-origin requests

# Configuration example - restrict qui access to localhost only
# In your reverse proxy (nginx example):
server {
    listen 127.0.0.1:8080;
    server_name localhost;
    
    location / {
        proxy_pass http://localhost:qui_port;
        # Remove permissive CORS headers if present
        proxy_hide_header Access-Control-Allow-Origin;
        proxy_hide_header Access-Control-Allow-Credentials;
    }
}