There was a missing permission-check in the shares feature (the `shr` global-option). This vulnerability only applies in the following scenario: * The [shares](https://github.com/9001/copyparty/#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](https://nvd.nist.gov/vuln/detail/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.
Update copyparty to 1.20.12 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCopyparty ftp/sftp: Sharing a single file did not fully restrict source-folder access affects copyparty (pip). Severity is low. There was a missing permission-check in the shares feature (the `shr` global-option). This vulnerability only applies in the following scenario: * The [shares](https://github.com/9001/copyparty/#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](https://nvd.nist.gov/vuln/detail/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.
AI coding agents often install or upgrade packages automatically in pip. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
There was a missing permission-check in the shares feature (the `shr` global-option). This vulnerability only applies in the following scenario: * The [shares](https://github.com/9001/copyparty/#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](https://nvd.nist.gov/vuln/detail/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.
Update copyparty to 1.20.12 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCopyparty ftp/sftp: Sharing a single file did not fully restrict source-folder access affects copyparty (pip). Severity is low. There was a missing permission-check in the shares feature (the `shr` global-option). This vulnerability only applies in the following scenario: * The [shares](https://github.com/9001/copyparty/#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](https://nvd.nist.gov/vuln/detail/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.
AI coding agents often install or upgrade packages automatically in pip. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|
| copypartypip | <1.20.12 | 1.20.12 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard| Package | Affected range | Fixed version |
|---|
| copypartypip | <1.20.12 | 1.20.12 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard