The chunked upload completion path for file requests does not validate the total file size against the per-request MaxSize limit. An attacker with a public file request link can split an oversized file into chunks each under MaxSize and upload them sequentially, bypassing the size restriction entirely. Files up to the server's global MaxFileSizeMB are accepted regardless of the file request's configured limit.
An insufficient authorization check in the file replace API allows a user with only list visibility permission (UserPermListOtherUploads) to delete another user's file by abusing the deleteNewFile flag, bypassing the requirement for UserPermDeleteOtherUploads.
An API endpoint accepts unbounded request bodies without any size limit. An authenticated user can cause an OOM kill and complete service disruption for all users.
If a malicious authenticated user uploads SVG and creates a hotlink for it, they achieve stored XSS.
A registered user without privileges to create or modify file requests is able to create a short-lived API key that has the permission to do so. The user must be registered with Gokapi. If you do not have any other users with access to the admin/upload menu, you are not impacted.
A privilege escalation vulnerability in the user rank demotion logic allows a demoted user's existing API keys to retain ApiPermManageFileRequests and ApiPermManageLogs permissions, enabling continued access to upload-request management and log viewing endpoints after the user has been stripped of all privileges.
The upload status SSE implementation on /uploadStatus publishes global upload state to any authenticated listener and includes file_id values that are not scoped to the requesting user.
The login flow accepts credential-bearing requests without CSRF protection mechanisms tied to the browser session context. The handler parses form values directly and creates a session on successful credential validation. Issue found by aisafe.io
When using end-to-end encryption, a stored XSS vulnerability can be exploited by uploading a file with JavaScript code embedded in the filename. After upload and every time someone opens the upload list, the script is then parsed. With the affected versions <v2.0, there was no user permission system implemented, therefore all authenticated users were already able to see and modify all resources, even if end-to-end encrypted, as the encryption key …
By renaming the friendly name of an API key, an authenticated user could inject JS into the API key overview, which would also be executed when another user clicks on his API tab. With the affected versions <v2.0, there was no user permission system implemented, therefore all authenticated users were already able to see and modify all resources, even if end-to-end encrypted, as the encryption key had to be the …