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