CVE-2025-32012: Jellyfin Media Server DoS Vulnerability

CVE-2025-32012 Overview

Jellyfin is an open source self-hosted media server. Versions 10.9.0 through 10.10.6 expose the /System/Restart administrative endpoint to unauthenticated attackers through an IP spoofing flaw. The endpoint authorizes any request originating from a local area network (LAN) IP address, but Jellyfin determines the source IP using forwarded HTTP headers. An unauthenticated attacker can forge X-Forwarded-For headers to impersonate a LAN client and trigger server restarts. Repeated spoofed requests cause a sustained denial-of-service condition. The flaw is tracked under [CWE-290: Authentication Bypass by Spoofing] and patched in version 10.10.7.

Critical Impact

An unauthenticated remote attacker can spoof a LAN source IP to repeatedly invoke the admin-only restart endpoint, producing a denial-of-service condition on default-configured Jellyfin servers.

Affected Products

• Jellyfin 10.9.0 through 10.10.6
• Jellyfin default-configured deployments without trusted reverse proxy settings
• Jellyfin instances exposed to untrusted networks

Discovery Timeline

• 2025-04-15 - CVE-2025-32012 published to NVD
• 2025-10-06 - Last updated in NVD database

Technical Details for CVE-2025-32012

Vulnerability Analysis

The flaw resides in how Jellyfin resolves the source IP address of incoming HTTP requests. The application uses ASP.NET Core's ForwardedHeadersMiddleware with XForwardedFor, XForwardedProto, and XForwardedHost enabled by default, even when no trusted proxies are configured. This allows any client to inject an X-Forwarded-For header that the framework then treats as the authoritative remote address.

The /System/Restart endpoint enforces an authorization policy that admits requests either from authenticated administrators or from clients on the local network. Because the LAN check evaluates the spoofable forwarded address, an attacker on the public internet can present a private RFC 1918 IP and satisfy the LAN condition without credentials.

Root Cause

The root cause is misplaced trust in client-supplied HTTP headers combined with network-based authorization. When KnownProxies and KnownNetworks are empty, ASP.NET Core's middleware should not honor forwarded headers, yet Jellyfin enabled them unconditionally. The endpoint also conflates network locality with administrative identity, treating LAN membership as a sufficient authorization signal [CWE-290].

Attack Vector

An attacker sends an HTTP POST request to /System/Restart containing an X-Forwarded-For: 192.168.1.10 header. Jellyfin's middleware overwrites the connection's remote address with the spoofed value, the policy handler classifies the caller as a LAN client, and the server reboots. Repeating the request every few seconds keeps the server in a perpetual restart loop. The same primitive can bypass other LAN-gated controls and amplify the impact of any chained remote code execution flaw.

// Patch diff: Jellyfin.Server/Extensions/ApiServiceCollectionExtensions.cs
                     // https://github.com/dotnet/aspnetcore/blob/master/src/Middleware/HttpOverrides/src/ForwardedHeadersMiddleware.cs
                     // Enable debug logging on Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersMiddleware to help investigate issues.

-                    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost;
-
                     if (config.KnownProxies.Length == 0)
                     {
+                        options.ForwardedHeaders = ForwardedHeaders.None;
                         options.KnownNetworks.Clear();
                         options.KnownProxies.Clear();
                     }
                     else
                     {
+                        options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost;
                         AddProxyAddresses(config, config.KnownProxies, options);
                     }

Source: Jellyfin patch commit f625665. The fix disables forwarded header processing when no known proxies are configured, eliminating the spoofing primitive in default deployments.

Detection Methods for CVE-2025-32012

Indicators of Compromise

• Unexpected POST /System/Restart entries in Jellyfin access logs originating from external clients carrying private-range X-Forwarded-For values.
• Repeated Jellyfin process restarts recorded by the host service manager (systemd, Windows Service Control Manager) without administrator action.
• Service availability gaps and client reconnection storms occurring at regular short intervals.

Detection Strategies

• Inspect HTTP request logs for X-Forwarded-For headers containing RFC 1918 addresses arriving on a public network interface.
• Correlate Jellyfin application restart events with inbound requests to /System/Restart and flag any without a preceding authenticated admin session.
• Run authenticated version checks against managed Jellyfin instances to identify hosts still on 10.9.0 through 10.10.6.

Monitoring Recommendations

• Forward Jellyfin and reverse proxy access logs to a centralized SIEM and alert on bursts of /System/Restart requests.
• Monitor service uptime metrics; alert when the Jellyfin process restarts more than once within a short window.
• Track and alert on any HTTP request where the TCP source IP is public but the forwarded IP is private.

How to Mitigate CVE-2025-32012

Immediate Actions Required

• Upgrade Jellyfin to version 10.10.7 or later, which disables forwarded header trust by default when no proxies are configured.
• Audit KnownProxies and KnownNetworks settings to ensure only legitimate reverse proxies are listed.
• Restrict inbound access to the Jellyfin HTTP/HTTPS ports using firewall rules or VPN-only exposure until patching is complete.

Patch Information

The vulnerability is fixed in Jellyfin 10.10.7. Review the GitHub Security Advisory GHSA-qcmf-gmhm-rfv9 and the upstream patch commit for full remediation details. The patch sets ForwardedHeaders = ForwardedHeaders.None when KnownProxies is empty, preventing untrusted clients from rewriting the remote address.

Workarounds

• Place Jellyfin behind a reverse proxy that strips inbound X-Forwarded-For headers and configure KnownProxies to the proxy address only.
• Block external access to /System/Restart at the reverse proxy or web application firewall layer.
• Enforce network-layer access control so that only authenticated VPN clients can reach the Jellyfin web interface.

# Example NGINX reverse proxy hardening to strip client-supplied forwarded headers
location / {
    proxy_pass         http://127.0.0.1:8096;
    proxy_set_header   Host              $host;
    proxy_set_header   X-Real-IP         $remote_addr;
    proxy_set_header   X-Forwarded-For   $remote_addr;   # overwrite, do not append
    proxy_set_header   X-Forwarded-Proto $scheme;

    # Deny external access to the restart endpoint
    location = /System/Restart {
        allow 10.0.0.0/8;
        deny  all;
        proxy_pass http://127.0.0.1:8096;
    }
}