Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Impact Any guest with access to a shared file request link can upload files far larger than the administrator-configured size limit, up to the server's global MaxFileSizeMB. This allows unauthorized storage consumption, circumvention of administrative resource policies, and potential service disruption through storage exhaustion. No data exposure or privilege escalation occurs.
Recommended action: Upgrade to 2.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Any authenticated user can crash the Gokapi server by sending concurrent large payloads.
Recommended action: Upgrade to 2.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Any authenticated user with PERMREPLACE (replace own files) and PERMLIST (view other users' uploads) can delete any other user's file without needing PERMDELETE.
Recommended action: Upgrade to 2.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Impact An attacker can force a victim browser into a session associated with an existing user account where the attacker knows the credentials, causing user confusion, activity misattribution, and potential misuse of trusted user actions.
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Any user who previously held Admin rank and had API keys with ApiPermManageFileRequests or ApiPermManageLogs retains those capabilities after demotion. This allows offboarded or demoted users to: - Create, list, and delete upload requests - Read application logs and system status
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This CVE is patched in v2.2.3
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If a malicious authenticated user uploads SVG and creates a hotlink for it, they achieve stored XSS. Details The hotlinking functionality fails to properly handle scripts included in the SVGs, allowing authenticated attackers with the ability to upload and hotlink file to execute arbitrary JS. Issue found by aisafe.io Impact Authenticated attackers with the ability to upload and hotlink files can execute arbitrary JavaScript.
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The upload status SSE implementation on /uploadStatus publishes global upload state to any authenticated listener and includes fileid values that are not scoped to the requesting user. Impact Any authenticated user can observe other users' file identifiers and retrieve unauthorized content, causing cross-tenant data exposure and loss of confidentiality for uploaded documents. Issue found by aisafe.io
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 had to be the same for all users with <v2.0. Nethertheless with XSS, other attack vectors like redirection or crypto mining would be possble. Patches This CVE has been fixed in v2.0.0 Workarounds If you are the only authenticated user using Gokapi, you are not affected. A workaround would be to disable end-to-end encryption.
Recommended action: Upgrade to 0.0.0-20250530191232-343cc566cfd7 (pre-release); some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 same for all users with <v2.0. Nethertheless with XSS, other attack vectors like redirection or crypto mining would be possble. Patches This CVE has been fixed in v2.0.0 Workarounds If you are the only authenticated user using Gokapi, you are not affected. A workaround would be to not open the API page if you suspect that another user might have injected code.
Recommended action: Upgrade to 0.0.0-20250530185940-65ddbc68fbfd (pre-release); some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.