CVE-2026-126499: 
Wolfi vulnerability analysis and mitigation

CVE-2026-126499 is a path traversal vulnerability in Jellyfin's virtual folder management API endpoints that allows attackers to delete or move arbitrary directories on the server. The flaw affects all Jellyfin versions before 12.0 and was disclosed on November 11, 2026. The vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and carries a CVSS v3.1 base score of 7.4 (High) and a CVSS v4.0 base score of 8.3 (High) (GitHub Advisory, Feedly).

The root cause is that the DELETE /Library/VirtualFolders and POST /Library/VirtualFolders/Name endpoints in LibraryStructureController.cs concatenate the caller-supplied library name directly onto the user-views root path using Path.Combine() without any validation, then pass the result to Directory.Delete(path, true) or Directory.Move(). Because Path.Combine() in .NET discards the base path when the second argument is an absolute path (e.g., /var/lib/jellyfin/data), and traversal sequences like .. resolve outside the intended directory, an attacker can target arbitrary filesystem locations. The vulnerable code in LibraryManager.cs used Path.Combine(rootFolderPath, name) without checking that the resolved path remained within the library root. The fix introduces a new FileSystemHelper.GetChildPath() method that validates the name is a single path segment and that the resolved full path's parent directory exactly matches the intended root (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated attacker to recursively delete or relocate any directory the Jellyfin server process has write access to, including the data directory and jellyfin.db database, resulting in permanent data loss and denial of service. The most severe scenario occurs before the startup wizard is completed: the FirstTimeSetupOrElevated policy grants anonymous access during this window, meaning a freshly installed Jellyfin server reachable on the network can be completely destroyed without any credentials. After setup, the endpoints require administrator privileges, reducing the post-setup risk to a hardening concern rather than an unauthenticated attack vector (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The attack complexity is rated High (CVSS v3.1) due to the precondition that the server must be in the pre-setup state for unauthenticated exploitation; post-setup exploitation requires administrator credentials. No threat actor attribution has been reported.

1. Reconnaissance: Identify internet-facing Jellyfin instances running versions before 12.0 using tools like Shodan or Censys, searching for the Jellyfin web interface. Determine whether the startup wizard has been completed by attempting to access the setup endpoint — if the server is freshly installed and the wizard is incomplete, unauthenticated access to the vulnerable endpoints is possible.
2. Identify target path: Determine the Jellyfin data directory path (commonly /var/lib/jellyfin/data on Linux or %PROGRAMDATA%\Jellyfin\Server on Windows).
3. Craft malicious DELETE request: Send an HTTP DELETE request to the vulnerable endpoint with a path traversal payload as the library name parameter:

DELETE /Library/VirtualFolders?name=..%2F..%2Fdata HTTP/1.1
Host: <target>:8096

Alternatively, supply an absolute path:

DELETE /Library/VirtualFolders?name=%2Fvar%2Flib%2Fjellyfin%2Fdata HTTP/1.1
Host: <target>:8096

4. Trigger recursive deletion: The server calls Directory.Delete(path, true) on the attacker-controlled path, recursively deleting the target directory including jellyfin.db and all configuration data.
5. Alternatively, use rename endpoint: Send a POST to /Library/VirtualFolders/Name with a traversal payload in the newName parameter to relocate directories to attacker-controlled locations.
6. Result: The Jellyfin service becomes inoperable due to loss of its database and data directory, achieving denial of service (GitHub Advisory, Patch Commit).

• Network: Unexpected HTTP DELETE requests to /Library/VirtualFolders with URL-encoded traversal sequences (.., %2F.., %2Fvar%2Flib) in the name query parameter; unexpected HTTP POST requests to /Library/VirtualFolders/Name with traversal sequences in name or newName parameters from unauthenticated or unexpected source IPs.
• Logs: Jellyfin access logs showing requests to /Library/VirtualFolders with parameters containing .., /, or absolute paths; log entries indicating FileNotFoundException or unexpected directory deletion operations in jellyfin.log.
• File System: Sudden absence of the Jellyfin data directory or jellyfin.db; missing or relocated library directories under the user views root path (typically /var/lib/jellyfin/data/root/default/).
• Process/Service: Jellyfin service failing to start due to missing database file; unexpected Directory.Delete or Directory.Move operations logged at the OS level.

Upgrade Jellyfin to version 12.0 or later, which introduces the FileSystemHelper.GetChildPath() validation method that rejects path traversal sequences and absolute paths in library names (Jellyfin v12.0 Release, Patch Commit). For those unable to upgrade immediately, the following workarounds reduce risk:

• Complete the setup wizard immediately after installation to eliminate the unauthenticated access window.
• Block access to /Library/VirtualFolders at a reverse proxy until setup is complete and the upgrade can be applied.
• Keep the Jellyfin server off untrusted networks during initial setup.
• Run the Jellyfin server process as an unprivileged account with filesystem access limited to its own data and media directories.
• Maintain regular backups of the Jellyfin data directory (GitHub Advisory).

The vulnerability was published by the Jellyfin project maintainer crobibero via a GitHub Security Advisory rated Critical (9.1 CVSS v3 by GitHub's scoring). The advisory clearly delineates the unauthenticated pre-setup risk as the primary concern and notes that post-setup exploitation is a hardening issue only, since administrators already have library deletion capabilities. No significant independent researcher commentary or broad media coverage has been identified beyond automated vulnerability tracking feeds (GitHub Advisory).