Threats affecting pkg:github/forceu/Gokapi

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, 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. This vulnerability is fixed in 2.2.4.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, 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. This vulnerability is fixed in 2.2.4.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, 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. This vulnerability is fixed in 2.2.4.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to version 2.2.3, 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. This issue has been patched in version 2.2.3.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to version 2.2.3, 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. This issue has been patched in version 2.2.3.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to version 2.2.3, 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 there are no users with access to the admin/upload menu, there is no impact. This issue has been patched in version 2.2.3.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to version 2.2.3, if a malicious authenticated user uploads SVG and creates a hotlink for it, they can achieve stored XSS. This issue has been patched in version 2.2.3.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to version 2.2.3, 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. This issue has been patched in version 2.2.3.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. 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. Prior to version 2.0.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 same for all users of versions prior to 2.0.0. If a user is the only authenticated user using Gokapi, they are not affected. This issue has been fixed in v2.0.0. A workaround would be to not open the API page if it is possible that another user might have injected code.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. When using end-to-end encryption, a stored cross-site scripting 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. Prior to version 2.0.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 same for all users using a version prior to 2.0.0. If a user is the only authenticated user using Gokapi, they are not affected. This issue has been fixed in v2.0.0. A possible workaround would be to disable end-to-end encryption.