GHSA-9p5f-5x8v-x65m is a high-severity (CVSS 8.8) Path Traversal vulnerability in Jellyfin.Controller. 2 public exploit references exist, so weaponization risk is real. A fix is available for Jellyfin.Controller — see the affected versions and patch details below.
Directory traversal + file write causing arbitrary code execution
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-9p5f-5x8v-x65m.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-9p5f-5x8v-x65m plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
Jellyfin.ControllerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
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/
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Jellyfin.Controller | ≥ 10.8.0&&< 10.8.10 | 10.8.10dotnet add package Jellyfin.Controller --version 10.8.10 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Jellyfin.Controller, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update Jellyfin.Controller to 10.8.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9p5f-5x8v-x65m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-9p5f-5x8v-x65m can be triaged on real exposure rather than presence alone.
Tailored to GHSA-9p5f-5x8v-x65m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9p5f-5x8v-x65m in your dependencies?
O3 Security finds GHSA-9p5f-5x8v-x65m across NuGet dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.