Jellyfin is a Free Software Media System for managing and streaming media. In affected versions there is an argument injection in the VideosController, specifically the /Videos/<itemId>/stream and /Videos/<itemId>/stream.<container> endpoints which are present in the current Jellyfin version. Additional endpoints in the AudioController might also be vulnerable, as they differ only slightly in execution. Those endpoints are reachable by an unauthenticated user. In order to exploit this vulnerability an unauthenticated attacker has to guess an itemId, which is a completely random GUID. It’s a very unlikely case even for a large media database with lots of items. Without an additional information leak, this vulnerability shouldn’t be directly exploitable, even if the instance is reachable from the Internet. There are a lot of query parameters that get accepted by the method. At least two of those, videoCodec and audioCodec are vulnerable to the argument injection. The values can be traced through a lot of code and might be changed in the process. However, the fallback is to always use them as-is, which means we can inject our own arguments. Those arguments land in the command line of FFmpeg. Because UseShellExecute is always set to false, we can’t simply terminate the FFmpeg command and execute our own. It should only be possible to add additional arguments to FFmpeg, which is powerful enough as it stands. There is probably a way of overwriting an arbitrary file with malicious content. This vulnerability has been addressed in version 10.8.13. Users are advised to upgrade. There are no known workarounds for this vulnerability.

In Jellyfin 10.8.x through 10.8.3, the name of a playlist is vulnerable to stored XSS. This allows an attacker to steal access tokens from the localStorage of the victim.

In Jellyfin 10.8.x through 10.8.3, the name of a collection is vulnerable to stored XSS. This allows an attacker to steal access tokens from the localStorage of the victim.

jellyfin-web is the web client for Jellyfin, a free-software media system. Starting in version 10.1.0 and prior to version 10.8.10, a stored cross-site scripting vulnerability in device.js can be used to make arbitrary calls to the REST endpoints with admin privileges. When combined with CVE-2023-30626, this results in remote code execution on the Jellyfin instance in the context of the user who's running it. This issue is patched in version 10.8.10. There are no known workarounds.

Impact Frederic Linn (@FredericLinn) has reported a series of vulnerabilities that can result in directory traversal, file write, and potential remote code execution on Jellyfin instances. The general process involves chaining several exploits including a stored XSS vulnerability and can be used by an unprivileged user.

The general process is (using the example of setting an intro video as the payload):

Create a session as a low-priviledged user with a crafted authorization header Upload an executable that contains a malicious plugin inline via /ClientLog/Document (Admin hovers over our device in dashboard -> XSS payload gets triggered) XSS Payload tries to set encoder path to our uploaded "log" file via /System/MediaEncoder/Path The request fails, but in the process our executable actually runs (I guess for verifying if the path points to a valid ffmpeg version) The executable will create a plugin folder and place the inlined plugin DLL inside it The XSS payload shuts down the server via /System/Shutdown (separate CVE in jellyfin-web) After (manually) starting the server, the plugin gets loaded and will: write a new video into the Jellyfin temp folder and register it register this video as the new intro and finally provide a malicious endpoint that simply executes system commands and sends back the results

The ability to write arbitrary content to log files was added in #5918 to allow flexibility to client logging.

The following two sections detail Frederic's exact determinations regarding the two vulnerabilities.

Directory traversal and file write

I've been reading the codebase here and there for a couple of days and found a directory traversal inside the ClientLogController, specifically /ClientLog/Document.

The GetRequestInformation method retrieves the name and version of the client from the HttpContext.User object.

Those values are attacker controlled when authenticating against the API. Both values are interpolated into a string, which ultimately ends up as an argument to Path.Combine().

Setting a client name to the relative path "\..\..\..\..\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\test" will write a file with completely attacker controlled content to the executing user's autostart directory.

However, because the attacker only partially controls the filename, exploitation proves to be tricky. That's because the resulting file will always end in ".log", which means putting something in the autostart directory is only going to open notepad on startup. I mean, we can at least insult the user :^).

Anyway, the next logical step would be to write into Jellyfin's plugins directory, but the sub-directories there (of which the already existing configurations directory conveniently counts as one!) are only getting scanned for ".dll" files.

This stops an attacker from providing malicious DLLs that implement the correct interfaces in order to be recognized as legitimate plugins.

On Linux, there might be more options. Running as the standard root user inside a container, an attacker could of course write anywhere. There's the very interesting "/etc/cron.d" directory, where an attacker can place cron jobs that get picked up automatically. Those files, however, can't contain a dot. Moreover, inside the container the cronjobs are probably not being executed, as the Jellyfin process should be only one running.

For the stored XSS component, see https://github.com/jellyfin/jellyfin-web/security/advisories/GHSA-89hp-h43h-r5pq

Patches 10.8.10

Workarounds N/A

References

A complete write-up is available here: https://gebir.ge/blog/peanut-butter-jellyfin-time/

Jellyfin is an open source self hosted media server. The Jellyfin user profile image upload accepts SVG files, allowing for a stored XSS attack against an admin user via a specially crafted malicious SVG file. When viewed by an admin outside of the Jellyfin Web UI (e.g. via "view image" in a browser), this malicious SVG file could interact with the browser's LocalStorage and retrieve an AccessToken, which in turn can be used in an API call to elevate the target user to a Jellyfin administrator. The actual attack vector is unlikely to be exploited, as it requires specific actions by the administrator to view the SVG image outside of Jellyfin's WebUI, i.e. it is not a passive attack. The underlying exploit mechanism is solved by PR #12490, which forces attached images (including the potential malicious SVG) to be treated as attachments and thus downloaded by browsers, rather than viewed. This prevents exploitation of the LocalStorage of the browser. This PR has been merged and the relevant code changes are included in release version 10.9.10. All users are advised to upgrade.

Jellyfin is a free software media system that provides media from a dedicated server to end-user devices via multiple apps. Verions prior to 10.7.3 vulnerable to unauthenticated Server-Side Request Forgery (SSRF) attacks via the imageUrl parameter. This issue potentially exposes both internal and external HTTP servers or other resources available via HTTP GET that are visible from the Jellyfin server. The vulnerability is patched in version 10.7.3. As a workaround, disable external access to the API endpoints /Items//RemoteImages/Download, /Items/RemoteSearch/Image and /Images/Remote via reverse proxy, or limit to known-friendly IPs.

Jellyfin is a Free Software Media System. In Jellyfin before version 10.7.1, with certain endpoints, well crafted requests will allow arbitrary file read from a Jellyfin server's file system. This issue is more prevalent when Windows is used as the host OS. Servers that are exposed to the public Internet are potentially at risk. This is fixed in version 10.7.1. As a workaround, users may be able to restrict some access by enforcing strict security permissions on their filesystem, however, it is recommended to update as soon as possible.

In Jellyfin before 10.8, the /users endpoint has incorrect access control for admin functionality.

In Jellyfin before 10.8, stored XSS allows theft of an admin access token.