Two vulnerabilities in Jellyfin, which is a media server fork of Emby. They focused on the REST API in the server, and they noticed that the Authorization header seemed to be implicitly trusted in many endpoints despite the fact it could be attacker-controlled.

Bug #1: Directory traversal in logging endpoint The logging endpoint was one such area that used the Authorization header values carelessly. It would take a clientName and version to create the log file name, but these are ultimately controllable via the header. You can simply directory traverse out and get an almost-arbitrary file write, as contents were controlled entirely via the POST body. Unfortunately, the filename ending in .log presented a problem that they weren’t able to solve.

Bug #2: Stored XSS in devices page The admin panel’s devices panel similarly trusted values from Authorization, and echoed the device ID into the page with no sanitization, yielding stored XSS. Furthermore, inline scripts were allowed by the CSP, so they could eval() in combination with the classic String.fromCharCode() trick to execute code despite not being able to get quotes through the Authorization header.

To get RCE, they used the logging endpoint to create a malicious executable that they could get processed through the media encoder via adding the path to the encoder through the admin access they acquired with the stored XSS. This would also be triggered during the validation phase which would launch the file as a process, meaning the original media encoder wouldn’t be replaced which works to the attacker’s favor.