Jellyfin Vulnerability Report: New GitHub Issue
A newly filed GitHub report alleges that Jellyfin contains an argument injection vulnerability involving .strm media shortcut files and its use of FFmpeg and ffprobe. The report was opened on September 30, 2026 and claims the flaw could allow someone with limited control over a Jellyfin media library to cause arbitrary file writes and potentially execute code under the Jellyfin service account. The technical claim is specific, but the security classification remains disputed because a Jellyfin maintainer argues that the required access falls outside the project's intended threat model. The researcher disputes that interpretation and points to earlier Jellyfin advisories that treated comparable media library write access as a meaningful attacker capability.
At the time of writing, GitHub issue #18244 remains open and Jellyfin has not published a security advisory confirming the report. There is also no CVE attached to this specific issue yet, so the alleged remote code execution path should not be described as a confirmed Jellyfin vulnerability. The stronger claim supported by the current discussion is that the researcher has identified a concrete input handling discrepancy and traced a plausible route from a crafted .strm file to manipulated FFmpeg arguments. The remaining dispute concerns whether that route crosses a security boundary Jellyfin accepts as part of its model.
What the Jellyfin vulnerability report found
Jellyfin uses FFmpeg and ffprobe to inspect, transcode, and process media. Before either program receives a file or remote stream, Jellyfin constructs the arguments that will be passed to it. The report identifies a difference between the handling of local files and remote media addresses, with local file paths passing through an escaping function while nonlocal inputs are allegedly wrapped in quotation marks without the same escaping step. That difference becomes relevant when Jellyfin processes .strm files, which act as small media shortcuts containing a remote address rather than the media itself.
The researcher reports that Jellyfin accepts protocols including HTTP, HTTPS, RTSP, and RTP for these shortcuts, then preserves the original address for later processing. According to the issue, a quotation mark can survive the URI validation and eventually reach the FFmpeg argument construction logic. If that behavior is reproduced as described, the input can affect the structure of the arguments Jellyfin intended to send rather than remaining confined to the media address. The report therefore frames the weakness as an argument injection problem rather than a simple malformed URL bug.
How the reported FFmpeg argument injection works
Quotation marks have structural meaning when command line arguments are assembled. Jellyfin expects the remote media address to remain one complete argument supplied to FFmpeg or ffprobe, but the researcher claims that an embedded quotation mark can terminate that argument earlier than intended. Text following the quotation mark could then be interpreted as additional FFmpeg or ffprobe options rather than remaining part of the remote media URL. The researcher classifies this behavior as CWE-88, which covers argument injection.
This is distinct from a conventional shell command injection scenario. The allegation is not that Jellyfin directly hands an arbitrary shell command to the operating system, but that attacker controlled text can alter the option list received by FFmpeg. FFmpeg is a capable media processing program with many output and file handling features, so controlling its arguments can have consequences beyond simply causing a failed playback request. The researcher argues that those capabilities can be redirected toward writing files as the operating system account running Jellyfin.
How a file write could become remote code execution
An arbitrary file write does not automatically produce remote code execution. A second condition is required, since the attacker would need to place or replace a file somewhere that Jellyfin or the operating system later interprets as executable, loadable, or otherwise trusted. The researcher proposes several possible targets, including Jellyfin plugin locations, configuration files, startup related files, and SSH authorization data where permissions permit access. If a file is written into a location that Jellyfin later loads as code, the impact could progress from file creation to execution under the Jellyfin service account.
This makes the reported attack considerably narrower than an ordinary unauthenticated Internet RCE. An attacker cannot simply discover a Jellyfin server and invoke the alleged flaw with no previous foothold. The attack begins with the ability to influence the contents of a .strm file inside a media library that Jellyfin processes. That prerequisite is now the central point of disagreement between the reporter and Jellyfin.
Jellyfin disputes whether this crosses a security boundary
A Jellyfin maintainer responded that someone capable of supplying the contents of a .strm file already has access to the server's filesystem. The maintainer characterized the scenario as resembling a malicious administrator problem and stated that it does not fit Jellyfin's intended security model. Under that interpretation, the behavior may still deserve hardening, but it would not represent privilege escalation across a boundary the project promises to defend. The security consequence would therefore be treated very differently from an attack that begins with no existing storage access.
The researcher argues that media directory access is not equivalent to administrative control of the Jellyfin host. A media library can reside on a NAS, Samba share, NFS mount, WebDAV location, guest writable directory, or another storage system where users may add media without gaining access to Jellyfin's plugins, configuration, or service account. A user permitted to place a movie or shortcut file on shared storage may therefore have no ability to alter Jellyfin itself. If a crafted media file causes Jellyfin to perform writes using broader service account permissions, the attacker has crossed from one privilege domain into another.
Previous Jellyfin vulnerabilities complicate that position
The researcher cited two earlier Jellyfin security advisories while challenging the maintainer's interpretation. The first was CVE-2026-35031, identified by GitHub advisory GHSA-j2hf-x4q5-47j3, which the researcher says involved subtitle upload path traversal and .strm handling with an attacker capable of placing files inside a Jellyfin media library. The second was CVE-2026-48793 under GHSA-wwwm-px48-fpvq, which the researcher says also contemplated shared storage scenarios and received a high severity rating. The point being made is that Jellyfin has previously treated media library write access as an attacker prerequisite rather than as equivalent to trusted administrative control.
Those earlier advisories do not automatically prove issue #18244 is exploitable or that it deserves the same severity. They do make the security model disagreement more difficult to dismiss with a simple statement that media directory access already implies server ownership. If the project's threat model has changed, the current response may reflect that shift. If it has not changed, the distinction between untrusted media storage and privileged Jellyfin directories still needs a more explicit explanation.
The report identifies a specific implementation difference
The GitHub report does more than speculate that FFmpeg may receive unsafe input. It identifies the functions involved and contrasts the treatment of local and remote inputs, noting that local file paths go through explicit escaping while the nonlocal path described in the issue is wrapped in quotation marks without the same operation. The researcher then traces .strm processing through Jellyfin's media probing logic, where the remote address is checked against an allowed protocol list before being retained for later use. The allegation is that URI validation and command line escaping solve different problems, so passing one check does not guarantee safety when the same string is later embedded inside process arguments.
That distinction gives the report more substance than a generic warning about malformed input. A string can be valid enough to satisfy URI parsing while still containing characters that have structural meaning when placed inside a command line. The reported weakness therefore depends on how the same value moves between subsystems with different parsing rules. The unresolved question is whether Jellyfin's current implementation actually permits the claimed file write under realistic permissions and whether the project considers that scenario inside its security model.
This is not currently a confirmed Jellyfin RCE vulnerability
The available evidence supports describing issue #18244 as a credible vulnerability report with a concrete proposed mechanism. It does not yet support describing every Jellyfin installation as remotely exploitable, since Jellyfin has not issued an advisory confirming the flaw and the maintainer response currently disputes the attack model. No CVE has been assigned to this specific report at the time of writing. The remote code execution claim therefore remains dependent on both the argument injection working as described and the Jellyfin service account having access to a location that can convert arbitrary file writes into execution.
The researcher has nevertheless identified a meaningful implementation asymmetry and connected it to an attack path that deserves scrutiny. If Jellyfin accepts media library content as potentially untrusted, the absence of equivalent escaping on the remote input path becomes difficult to dismiss as merely theoretical. If the project instead defines media library write access as fully trusted, then the argument shifts from exploitability toward whether that trust assumption is appropriate for shared storage and automated media ingestion environments. The GitHub discussion has not yet resolved that question.
Who would be exposed if the report is confirmed?
A Jellyfin installation where only a trusted administrator can modify media directories would present relatively little additional opportunity through this particular path. Anyone who already has unrestricted administrative access to the host would not need an FFmpeg argument injection route to modify Jellyfin files or configuration. The exposure becomes more relevant when media storage is intentionally less trusted than the Jellyfin service, which is common in shared NAS installations, automated media import systems, IPTV workflows, collaborative media directories, and remote mounts. In those environments, the person or process supplying media may have fewer privileges than Jellyfin itself.
Those configurations are exactly where the security boundary described by the researcher becomes meaningful. A media server frequently processes files originating outside the account that ultimately runs the service, so the difference between file placement rights and service account rights is not merely theoretical. If the report is eventually confirmed, administrators using shared or externally populated media storage would have a stronger reason to review who can create or modify .strm files. The practical risk would depend heavily on permissions, storage architecture, and whether untrusted parties can influence files that Jellyfin scans.
What Jellyfin issue #18244 has established so far
Issue #18244 identifies an apparent difference in how Jellyfin escapes local and remote FFmpeg inputs and describes a route through which .strm content may reach the less protected path. The researcher claims the resulting argument injection can be converted into arbitrary file writes and, under suitable permissions, code execution. Jellyfin's initial response does not primarily challenge the existence of the input path described in the issue, but instead disputes whether someone able to place the malicious .strm file should be considered an attacker within the project's security model. That makes the present disagreement as much about trust boundaries as about command construction.
The strongest conclusion available today is narrower than a confirmed RCE headline. Jellyfin issue #18244 presents a detailed argument injection report with a plausible path toward higher impact, but the project has not accepted it as a confirmed security vulnerability. The next meaningful development will be whether Jellyfin rejects the report on threat model grounds, changes the relevant argument handling, or publishes a formal advisory. Until then, the report is technically substantive but still unresolved.
Jellyfin GitHub vulnerability report
GitHub issue #18244: https://github.com/jellyfin/jellyfin/issues/18244
Jellyfin GitHub: https://github.com/jellyfin/jellyfin
Download Jellyfin for Windows
Official Jellyfin Windows download:
Download Jellyfin for Mac
Official Jellyfin Mac download:
Download Jellyfin for Linux
Official Jellyfin Linux download:
Comments