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
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The FTP and FTPS server -- if enabled -- would allow uploading to any folder that the copyparty process had permission to write to. The FTP-server is default-disabled, and must be explicitly enabled in the config with global-option ftp or ftps to be affected. Additionally, SFTP was not affected at all; only FTP and FTPS. This was not a full read/write path-traversal; it had the following limitations: Only applied to uploads; it was not possible to read/download existing files in this manner. The output filename was not fully controllable; a randomized suffix would always be appended to the filename. Existing files could not be overwritten or appended to; only new files could be created. Filesystem-permissions would prevent writing to system folders, as copyparty surely does not run as root in most deployments. Copyparty itself will not execute arbitrary files as code by default, so this vulnerability could not be used to execute arbitrary code through copyparty. The main concern is…
Recommended action: Upgrade to 1.20.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A valid filekey could potentially be converted into a dirkey, granting read-access to the containing folder. This issue only affected volumes which simultaneously enable both filekeys and dirkeys, with volflag dk or dks combined with fk or fka. Both required features are default-disabled, and must be explicitly enabled in the volflags (the "flags" section of a volume).
Recommended action: Upgrade to 1.20.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If an attacker has been given both read- and write-permissions to the server, they can upload a malicious file with the filename .prologue.html and then craft a link to potentially execute arbitrary JavaScript in the victim's context. Note that it is intended behavior that the JavaScript would execute if the target clicks a link to the HTML file itself; "https://example.com/foo/.prologue.html". The vulnerability is that "https://example.com/foo/?b" would also evaluate the file, making the behavior unexpected. There are existing preventative measures (strict SameSite cookies) which makes it harder to leverage this vulnerability in an attack; in order to gain control of the target's authenticated session, the link must be clicked from a page served by the server itself -- most likely by editing an existing resource, which would require additional access permissions. Finally, for this attack to be successful, the attacker's target must click the specific crafted link given by the…
Recommended action: Upgrade to 1.20.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There was a missing permission-check in the shares feature (the shr global-option). This vulnerability only applies in the following scenario: The shares feature is used for the specific purpose of creating a share of just a single file inside a folder Either the FTP or SFTP server is enabled, and also made publically accessible If a share is password-protected, then SFTP was not vulnerable unless the sftp-pw global-option was also enabled Given these conditions, when a user is browsing a share through either FTP or SFTP (not http or https), they can gain read-access to the remaining files inside the shared folder by guessing/bruteforcing the filenames. It was not possible to descend into subdirectories in this manner; only the sibling files were accessible. This issue did not affect filekeys or dirkeys. This vulnerability is CVE-2025-58753 which was previously fixed for HTTP and HTTPS, but not for FTP. The FTPS server did not yet exist at that time.
Recommended action: Upgrade to 1.20.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The nohtml config option, intended to prevent execution of JavaScript in user-uploaded HTML files, did not apply to SVG images. Details A user with write-permission could upload an SVG containing embedded JavaScript, which would execute in the context of whichever user opens it. This in itself is not a vulnerability; it is intended behavior according to the SVG spec. The vulnerability is that the nohtml volflag, when enabled, did not prevent this. nohtml, intended for use on volumes which contains untrusted files, would correctly prevent execution of javascript in HTML files, but did not consider SVG images. This has been fixed in v1.20.11. Impact The malicious JavaScript could move or delete existing files on the server, or upload new files, using the account of the person who opens the SVG.
Recommended action: Upgrade to 1.20.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An XSS allows for reflected cross-site scripting via URL-parameter ?setck=... Details A reflected cross-site scripting (XSS) vulnerability could allow an attacker to execute malicious javascript by tricking users into accessing a malicious link. The worst-case outcome of this is being able to move or delete existing files on the server, or upload new files, using the account of the person who clicks the malicious link. Indicators of Compromise All attempted attacks (successful or not) would be logged to both the copyparty serverlog and the accesslog of the reverseproxy, and are detected by grep -E '[?&]setck=[^&"]%' (the text setck= eventually followed by the % character).
Recommended action: Upgrade to 1.20.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There was a missing permission-check in the shares feature (the shr global-option). When a share is created for just one file inside a folder, it was possible to access the other files inside that folder by guessing the filenames. It was not possible to descend into subdirectories in this manner; only the sibling files were accessible. This issue did not affect filekeys or dirkeys.
Recommended action: Upgrade to 1.19.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The filter parameter for the "Recent uploads" page allows arbitrary Regexes. If this feature is enabled (which is the default), an attacker can craft a filter which deadlocks the server. PoC https://127.0.0.1:3923/?ru&filter=(.+)+x Impact The server becomes fully inaccessible for a long time.
Recommended action: Upgrade to 1.18.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthorized reflected Cross-Site-Scripting when accessing the URL for recent uploads with the filter parameter containing JavaScript code. Details When accessing the recent uploads page at /?ru, users can filter the results using an input field at the top. This field appends a filter parameter to the URL, which reflects its value directly into a <script block without proper escaping. This vulnerability allows for reflected Cross-Site Scripting (XSS) and can be exploited against both authenticated and unauthenticated users, enabling unwanted actions in the victims browser. PoC A URL like this will execute alert(1):
Recommended action: Upgrade to 1.18.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated attacker is able to execute arbitrary JavaScript code in a victim's browser due to improper sanitization of multimedia tags in music files, including m3u files. Details Multimedia metadata is rendered in the web-app without sanitization. This can be exploited in two ways: a user which has the necessary permission for uploading files can upload a song with an artist-name such as <img src=x onerror=alert(document.domain) an unauthenticated user can trick another user into clicking a malicious URL, performing this same exploit using an externally-hosted m3u file The CVE score and PoC is based on the m3u approach, which results in a higher severity. PoC 1. Create a file named song.m3u with the following content. Host this file on an attacker-controlled web server. 2. Craft and share the malicious URL: Impact Any user that accesses this malicious URL is impacted.
Recommended action: Upgrade to 1.18.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A DOM-Based XSS was discovered in copyparty, a portable fileserver. The vulnerability is considered low-risk. Details By handing someone a maliciously-named file, and then tricking them into dragging the file into copyparty's Web-UI, an attacker could execute arbitrary javascript with the same privileges as that user. For example, this could give unintended read-access to files owned by that user. The bug is triggered by the drag-drop action itself; it is not necessary to actually initiate the upload. The file must be empty (zero bytes). Note: As a general-purpose webserver, it is intentionally possible to upload HTML-files with arbitrary javascript in <script tags, which will execute when the file is opened. The difference is that this vulnerability would trigger execution of javascript during the act of uploading, and not when the uploaded file was opened. Proof of Concept (POC) 1. Create an empty file named <img src=x onerror="alert(1)" 2. Drag-and-drop the file into the…
Recommended action: Upgrade to 1.16.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The application contains a reflected cross-site scripting via URL-parameter ?k304=... and ?setck=... Details A reflected cross-site scripting (XSS) vulnerability exists in the web interface of the application that could allow an attacker to execute malicious javascript code by tricking users into accessing a malicious link. The worst-case outcome of this is being able to move or delete existing files on the server, or upload new files, using the account of the person who clicks the malicious link. It is recommended to change the passwords of your copyparty accounts, unless you have inspected your logs and found no trace of attacks. Checking for exposure if copyparty is running behind a reverse proxy, you can check the access-logs for traces of attacks, by grepping for URLs containing ?hc= with < somewhere in its value, for example using the following command: nginx: the above commands also check for attacks against GHSA-cw7j-v52w-fp5r PoC…
Recommended action: Upgrade to 1.8.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The application contains a reflected cross-site scripting via URL-parameter ?hc=... Details A reflected cross-site scripting (XSS) vulnerability exists in the web interface of the application that could allow an attacker to execute malicious javascript code by tricking users into accessing a malicious link. The worst-case outcome of this is being able to move or delete existing files on the server, or upload new files, using the account of the person who clicks the malicious link. It is recommended to change the passwords of your copyparty accounts, unless you have inspected your logs and found no trace of attacks. Checking for exposure if copyparty is running behind a reverse proxy, you can check the access-logs for traces of attacks, by grepping for URLs containing ?hc= with < somewhere in its value, for example using the following command: nginx: PoC http://127.0.0.1:3923/?hc="<scriptalert(1);</script http://127.0.0.1:3923/?pw=<scriptalert(1);</script
Recommended action: Upgrade to 1.8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All versions before 1.8.2 have a path traversal vulnerability, allowing an attacker to download unintended files from the server. Details Unauthenticated users were able to retrieve any files which are accessible (according to OS-level permissions) from the copyparty process. Usually, this is all files that are readable by the OS account which is used to run copyparty. The vulnerability did not make it possible to list the contents of folders, so an attacker needs to know the full absolute path to the file, or the relative path from where copyparty is installed. Some methods of running copyparty (prisonparty, the nix package, and docker) had a mitigating effect, mostly reducing the attack scope to files inside copyparty volumes, and possibly the copyparty config file. Checking for attacks Please keep in mind that, if an attacker were to find a way to overwrite the logs, for example by discovering the password to another service with sufficient privileges, then the following…
Recommended action: Upgrade to 1.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.