CVE-2026-70657: Logical Authorization Bypass in Copyparty Directory and File Key Handling

Copyparty is a portable file server environment offering web-based directory exploration, uploading, and administration. It relies on a modular volume structure where administrators can configure access permissions using fine-grained flags. Among these flags are directory keys (dk or dks) and file keys (fk or fka), which control localized access for untrusted clients. The directory keys grant listing and read permissions for directory hierarchies, whereas file keys restrict client access exclusively to a single designated file.

The attack surface is localized within the web-browser engine component of the file server, specifically handled in the tx_browser handler inside copyparty/httpcli.py. This handler serves as the entry point for formatting directory trees, managing download listings, and handling browser requests. When directory keying and file keying are mixed on a single storage volume, the logical access boundary collapses.

This issue is categorized under CWE-863 (Incorrect Authorization). It permits an authenticated user with low privileges (possession of a single valid file key) to step outside their authorized scope and list directory tree nodes. This logical flaw bypasses the granular boundary that developers implemented to isolate single-file assets from neighboring resources in the same path.

The logical collapse is caused by state tracking confusion when processing the connection context in copyparty/httpcli.py. The HTTP daemon establishes a boolean tracker named use_filekey to identify whether a given connection has authenticated strictly via a file-level key. If use_filekey is active, the request lifecycle should restrict execution endpoints from executing directory-level listings or returning indexes of container folders.

When the server handles a directory-rendering routine, it queries the volume flags to populate configuration attributes for the current workspace. In vulnerable versions, the initialization of the add_dk variable—responsible for checking if directory keys should be processed—was performed via add_dk = vf.get("dk"). This assignment solely checked if the configuration flag was enabled for the storage volume, completely ignoring whether the current session's key validation context was limited to a file key.

Because the server verified that the user presented a valid cryptographic or token key (the file key itself), the key checking loop completed successfully. However, when rendering the directory interface, the unconditional initialization of the directory-key mechanisms (add_dk = True) allowed the server to treat the file key as a valid credential for directory operations. This logical promotion enabled a client to request index trees because the backend failed to isolate the scope of the active file key.

A direct analysis of the patch highlights the exact mechanical failure of the authorization check. The critical vulnerability window existed inside the HTTP client request handler when preparing volume attributes for display.

# Vulnerable implementation in copyparty/httpcli.py prior to v1.20.17
# The software loaded the directory key flag directly from the volume structure (vf)
# without verifying if the active user was restricted by a file key constraint.
 
add_dk = vf.get("dk")

This evaluation meant that if the volume configuration possessed directory keys (dk), the backend enabled directory-key logic for the request. The patch corrected this issue by enforcing a logical conjunction that requires the request not to be a restricted file key session.

# Patched implementation in copyparty/httpcli.py inside commit e40755331ba9449993ff482456e6bdd2c6deb950
# The fix couples the directory key activation flag to the negation of the file key restriction variable.
 
add_dk = not use_filekey and vf.get("dk")

This addition ensures that if use_filekey is True (meaning the client has authenticated with an fk or fka key), add_dk is forced to False regardless of whether directory keying (dk or dks) is enabled on the storage volume. This fix is complete; it directly blocks the initialization of the directory index routine for any thread constrained by a file-level token.

Exploitation of CVE-2026-70657 requires no specialized tools and can be executed via basic HTTP clients. The primary requirement is that the target copyparty volume is configured to use both file keys and directory keys. Additionally, the attacker must have obtained a valid file key string, which might be distributed to low-privilege users or guests for accessing specific media assets or logs.

The attack sequence begins with a standard request to download or view the authorized file. This request validates the key and sets the server's session state. The attacker then modifies the request path to point to the containing directory instead of the specific file, whilst retaining the exact same file-key query parameter.

In a vulnerable version, the directory browser processes this request. Instead of returning an access control error, it evaluates the volume-level flags, sees that dk is active, and matches the authenticated credentials. The server lists all files, directories, and metadata residing in the folder, granting full visibility to neighboring resources.

The impact of this vulnerability is a breach of confidentiality on affected copyparty storage volumes. In multi-tenant or multi-user file storage setups where file keys are distributed to isolate different files (such as database backups, user documents, or proprietary logs), a low-privileged client can view and download all adjacent assets. This circumvents the access controls that administrators rely on to secure multitenant file systems.

The CVSS v3.1 base score of 4.3 reflects this localized, medium-severity risk. Since write permissions or code execution capabilities are not granted through this specific logic flaw, Integrity and Availability scores remain at zero. However, in environments hosting highly sensitive data, this can lead to data exposure and lateral discovery.

Because the vulnerability requires an explicit, non-default configuration (mixing dk and fk on the same volume), the overall threat landscape is specialized. This explains its current status on CISA's KEV catalog (not listed) and its low EPSS score. However, for organizations that rely on Copyparty for public-facing assets, the exploit complexity remains low once a key is acquired.

Remediation requires upgrading the Copyparty software to version 1.20.17 or higher. The patch strictly separates the validation scopes of file keys and directory keys, preventing the logical promotion of restricted credentials. Upgrading can be completed by downloading the updated package from the official repository or pulling the latest container image.

If immediate patching is impossible, defensive engineers should audit copyparty configurations. Review the volume flags to ensure that dk/dks and fk/fka are never combined on the same virtual root or storage directory. Segregating resources into separate volumes based on access key types will nullify the vulnerable code path.

Additionally, network-level monitoring or web application firewalls can be configured to inspect query parameters. If a request targets a directory index while presenting parameters historically associated with file-level authentication, it should be dropped. ModSecurity and other modern engines can enforce rules to detect and alert on anomalous traversal requests targeting Copyparty directories.