Dokima Report

When file-event hooks are turned on, the server pastes the name of the file a user just uploaded, renamed, or deleted directly into a command that runs on the server. A user who simply names their file with shell tricks can make the server run their own commands, even without permission to run commands.

Usernames are stored exactly as typed, but the folder for each user is named after a cleaned-up version of the username. Two different usernames can clean to the same folder name, so someone can register a look-alike name and end up sharing another person's private files.

Each user is meant to stay inside their own folder, but the confinement check only compares text, it does not resolve symbolic links. If a shortcut pointing outside the folder exists inside a user's area, the user can read or overwrite files anywhere the server can reach — including the app's database.

With the built-in default settings, anyone who signs up for an account is placed at the very top of the server's file tree instead of a private folder of their own. That gives every self-registered user permission to read, change, and delete all served files.

When a user deletes a file or folder, the app trusts the path text but does not check whether any folder along the way is a shortcut that points outside the user's allowed area. If such a shortcut exists, the delete can wipe out unrelated files elsewhere on the server, including the app's own login database.

When a user renames or moves a file, the app checks the path as plain text but doesn't verify that folders along the way are real folders rather than shortcuts pointing elsewhere. An attacker can use such a shortcut to pull a file from outside their allowed area into it and then download it, or push their files out.

A user who is allowed to create and modify files but not to delete them can still wipe out an entire folder. Uploading over an existing directory triggers an error-cleanup step that recursively deletes that directory, doing exactly what the missing delete permission was supposed to prevent.

A specially crafted image can make the server try to reserve several gigabytes of memory just from reading its metadata. Any logged-in user allowed to download files can request a thumbnail of such an image and exhaust the server's memory, potentially crashing it for everyone.

Listing shares can crash the request whenever two or more shares in the queried set have expired, because a cleanup loop deletes entries while looping over the list incorrectly. A low-privilege user can trigger this on demand and also break the admin view that lists everyone's shares.

A single request to update a user account can name the same field thousands of times, and the server performs one separate disk-syncing database write for each entry (and a full password hash for each 'Password' entry). One authenticated user can turn one request into massive disk and CPU work.

The preview feature caps image dimensions but the check is off by one, so a picture that is exactly 10000x10000 (100 million pixels) is accepted and fully loaded into memory. A user can request several such previews at once and consume large amounts of server memory.

When someone shares a folder with a public link, the app is supposed to keep honoring any "block access to this subfolder" rules the owner set. Because the code changes how paths are named once the share opens, those block rules stop matching, so a visitor could reach a subfolder the owner intended to keep private.

When generating an image preview, the app opens the file first and then waits for a free worker slot using a wait that ignores the client hanging up. Pending or abandoned requests keep holding open files and background tasks that nothing releases, so many at once can exhaust server resources.

Changing your password or logging out does not actually cut off sessions that are already signed in. An old login token keeps working until it expires, and it can be repeatedly refreshed to stay alive, so someone who got hold of a token is not locked out by a password change.

Anyone on the internet can hit the login and signup pages without an account, and the server reads their entire request into memory before checking any password. There is no limit on how big or how slow that request can be, so an unauthenticated attacker can push the server to consume excessive memory or hold…

When a logged-in user uploads a file in chunks, the server keeps the connection, an open file, and a background helper alive for as long as the upload lasts, with no time limit and no cap on how many can run at once. A user who opens many deliberately slow uploads can tie up the server's resources.

A password-protected share whose stored access token is empty can be opened without the password by supplying an empty token in the URL. This affects older shares created before the token feature existed, letting anyone with the share link view protected content without knowing the password.

Any logged-in user can open the command WebSocket even without permission to run commands, and the server will hold the connection open forever or accept an unlimited-size message before it checks their permission. Repeating this can tie up server memory and connections until the service degrades.

Access rules that block a folder or file compare names letter-for-letter, but on Mac, Windows, and some network drives the filesystem treats different capitalizations as the same file. So a blocked path like /secret can be reached by asking for /Secret.

When file-uploads are configured to use Redis (for multi-server setups), abandoned or incomplete uploads are never cleaned off disk. The memory-based setup deletes them automatically, but the Redis one has no such cleanup, so leftover files pile up until the disk fills.

When an external login hook is used, logging back in can quietly wipe the custom access restrictions an administrator set on that user account. A rule meant to block the user from certain files can silently disappear, giving the user more access than intended.

When the administrator has set up commands that run automatically on file changes, any user allowed to create or edit files can trigger those commands over and over with no limit. Rapid file operations can pile up unlimited background processes and slow down or crash the server.

For password-protected public share links, anyone who has the link can try passwords as fast as the server can check them, because there is no limit, delay, or lockout on failed attempts. This allows both password guessing and turning cheap requests into heavy server CPU load.

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.