Medium Issues

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.