Low Issues

The main application page is delivered without the Content-Security-Policy protection the app intends to apply. The policy is added by middleware that only runs for matched routes, but the main page is served through the router's not-found handler, which that middleware never touches.

New user folders are created with the most permissive access setting instead of the stricter one the application is configured to use. On a shared machine, other local users could read or change those folders.

When a user deletes a folder, the app also deletes share links whose stored path merely starts with the same text — including unrelated folders and links belonging to other users. Those users' share URLs silently stop working.

If the Redis connection string used for upload caching is misspelled in a way that makes it fail basic URL parsing, the server prints the whole string — including the username and password — into its startup output and logs.

When the app lists a folder that contains a video, it automatically looks for matching subtitle files and returns their names — even for files that the folder's own visibility rules were supposed to hide. Someone browsing the folder can therefore learn that hidden files exist and see their names.

The application never tells browsers it should not be embedded in a frame. A malicious site can load the logged-in interface inside a hidden frame and trick a user into clicking controls that perform real file actions without realizing it.

The server writes the requested URL straight into its log without cleaning it up. Because a URL can contain hidden newline characters, anyone sending requests can inject fake lines into the log or embed control characters that mislead whoever reads it.

Users who are explicitly denied the ability to download files can still ask the server for a file's cryptographic hash. That lets them confirm whether a file has specific known contents or detect when it changes, even though they were never supposed to read the file.

The login and related sign-in endpoints accept unlimited attempts with no throttling, temporary lockout, or bot protection. An attacker can automate high-volume guessing against accounts, limited only by how long each password check takes.

Password-protected share links can be guessed at without limit: the server never throttles or locks out repeated wrong guesses, and it never enforces a minimum length for share passwords. A weak share password can be brute-forced online by anyone holding the share link.

A specially crafted subtitle file can crash the request that converts it. When a user requests conversion of such a file, the parser hits a malformed timestamp line and aborts that one connection. The damage is limited to the single failed request.

When a file request fails, the server writes the requested file name straight into its log. An attacker can put line breaks in that name, letting them inject fake lines into the log file. This works even with no login when a public folder share is enabled.

A file download URL lets a caller slip newline characters into the requested path. When the download fails, the server writes that path straight into its log without cleaning it, so an attacker can add fake lines to the log. On a password-less public share this works without even logging in.

A user uploading a file can put newline characters into the upload path. If the upload is abandoned, a background cleanup timer later writes that path into the log without escaping it, letting the user inject fake log lines. It only needs upload permission and works on the default setup.

When reCAPTCHA is enabled, each login waits for a reply from the reCAPTCHA service using a connection that has no time limit. If that service is slow or unreachable, login requests can hang indefinitely and stack up.

For copy and rename requests, the server runs the admin-configured 'before' hook command first and only afterward checks whether the user is allowed to copy or rename. A user lacking those permissions can still make the hook run with a filename and destination they control.

When someone requests a subtitle file, the server reads the whole file into memory and builds the converted output entirely in memory before sending anything, with no limit on file size. Large or crafted subtitle files, requested repeatedly, can drive up memory use and strain the server.

Under proxy authentication the app takes the username straight from a request header without checking it is present or non-blank. If the header is missing, it can auto-create a blank-named account with default permissions and hand out a login token for it.

When making a small preview of a JPEG, the app can send back a thumbnail that is stored inside the uploaded file, exactly as the uploader wrote it, without the safety headers that similar download endpoints add. On an unusually configured server this raw content could be misinterpreted by the browser as a web page.

The recursive folder-listing feature skips the access check on the folder you point it at, unlike every other file operation. In certain rule configurations this lets a user list the names, sizes, and dates of items inside a folder they were supposed to be blocked from.

When a user sends a file-management request, the server reads the requested action straight from the URL and runs the matching admin-configured 'before' command first, before checking whether that user is even allowed to do it. A user can trigger commands they were never permitted to run.

When the optional login CAPTCHA is turned on, the server only trusts that Google said the puzzle was solved, but never checks that it was solved on the real site. An attacker could collect solved puzzles from a page they control and reuse them to get past the CAPTCHA on the login form.

The search feature ignores errors while walking the file tree. If a file disappears at the wrong moment during a search, the code uses an empty file record and crashes that one search request. Only the single request fails; the server keeps running.

A password-protected share can be opened with a secret token instead of the password, and that token travels in the web address. Web addresses commonly end up in server logs, browser history, and forwarded links, so anyone who sees the address can reopen the share without knowing the password.

When importing users with the --replace option, the tool writes a backup to a fixed, predictable filename in the current directory using an open call that follows symbolic links. If someone pre-plants a symlink there pointing at another file, running the command overwrites and destroys that other file.

When a user runs a command over the WebSocket endpoint, the server does not tie the command's lifetime to the connection. If the user disconnects, the command keeps running and its goroutine stays parked, so repeatedly starting and dropping long-running commands can pile up abandoned processes.

When the server makes a thumbnail of a TIFF image, it can be tricked into loading a huge amount of the file into memory before any size limit applies. A user with a very large crafted TIFF can spike server memory and, with a few concurrent requests, risk crashing it.

The file-move endpoint accepts an 'action' name from the URL without checking it against a list of allowed actions. That name is used to fire configured shell hooks, so a user with no permissions can trigger hooks for operations they are not allowed to perform, such as a delete hook.

When the app is configured to check passwords through an external hook, a login attempt for a real username takes measurably longer than one for a username that does not exist. An attacker timing these responses could learn which usernames are valid, even without guessing any password.

Anyone can download files from password-less public share links without logging in, and the server has no time limit on how long a download response may take. A client that reads very slowly can tie up server connections and memory, hurting availability.