Cross Site Scripting vulnerability in copyparty before 1.9.2 allows a local attacker to execute arbitrary code via a crafted payload to the WEEKEND-PLANS function. NOTE: this is disputed because WEEKEND-PLANS is accessible only to actors who already have write access to the server, and they can more simply upload HTML files containing JavaScript.

Summary 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.

Copyparty is a portable file server. In versions prior to 1.19.8, there was a missing permission-check in the shares feature (the shr global-option). When a share was 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. Version 1.19.8 fixes the issue.

Summary 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 approaches cannot be trusted.

if copyparty was only accessible through a reverse proxy, then all attacks would be visible in the webserver access-log as URLs which contain both .cpr/ and %2F nginx: bash (gzip -dc access.log.gz; cat access.log) | sed -r 's/" [0-9]+ .//' | grep -E 'cpr/.%2[^0]' | grep -vF data:image/svg

However, if copyparty was directly accessible from the internet, then any successful attacks (file retrievals) would unfortunately leave no trace. That said, it is very probable that an attacker would make at least one invalid attempt, which would become apparent in the copyparty server log, detectable with grep -aE '(Errno|Permission).\.cpr/' revealing the following: python2 example: [IOError] [Errno 13] Permission denied: '/etc/shadow', .cpr//etc/shadow python3 example: [PermissionError] [Errno 13] Permission denied: b'/etc/shadow', .cpr//etc/shadow

Providing an exact command for this approach is difficult, as it depends on how copyparty is deployed; if copyparty was running as a systemd service: journalctl -am | grep -aE '(Errno|Permission).\.cpr/' if copyparty was logging to a compressed file: xz -kdc thefilename.xz | grep -aE '(Errno|Permission).\.cpr/' if the copyparty log is available in a plaintext file: grep -aE '(Errno|Permission).\.cpr/' thefilename.txt

PoC / attack example bash curl -sik http://127.0.0.1:3923/.cpr/%2Fetc%2Fpasswd curl -sik http://127.0.0.1:3923/.cpr/..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd

Summary 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): https://127.0.0.1:3923/?ru&filter=</script><script>alert(1)</script>

Summary 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: bash (gzip -dc access.log.gz; cat access.log) | sed -r 's/" [0-9]+ .//' | grep -iE '%0[da]%0[da]%0[da]%0[da]|?&=.[<>]' the above commands also check for attacks against GHSA-cw7j-v52w-fp5r

PoC https://localhost:3923/?k304=y%0D%0A%0D%0A%3Cimg+src%3Dcopyparty+onerror%3Dalert(1)%3E

Summary

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 browser to initiate an upload 3. The alert(1) is executed

Summary

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.

m3u #EXTM3U #EXTINF:1,"><img src=x onerror=alert(document.domain)> - "><img src=x onerror=alert(document.domain)> http://example.com/audio.mp3

2. Craft and share the malicious URL:

http://127.0.0.1:3923/#m3u=https://example.com/song.m3u

Impact Any user that accesses this malicious URL is impacted.

Summary 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).

Summary 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.

Copyparty is a portable file server. Prior to 1.20.12, 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 attacker. This vulnerability is not activated by normally browsing the web-UI on the server. This vulnerability is fixed in 1.20.12.

Copyparty is a portable file server. Prior to 1.20.12, there was a missing permission-check in the shares feature (the shr global-option). This vulnerability only applies when the shares feature is used for the specific purpose of creating a share of just a single file inside a folder or either the FTP or SFTP server is enabled, and also made publicly accessible. 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 vulnerability is similar to 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. This vulnerability is fixed in 1.20.12.