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

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.

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