Anonymous RNFR/RNTO permission bypass allows unauthorized overwrite of privileged files (CVE request)

[ZhangFsn]

Hi @giampaolo,

I hope you are doing well.
I previously reported a documentation-related concern about --write, but after deeper analysis, I realized that the issue is not just about documentation — it is a functional security vulnerability that allows anonymous users to overwrite privileged files via RNFR/RNTO, even when normal write paths should prevent it.

I am reopening this as a new issue because the impact is security-critical and relevant for CVE consideration.

🔍 Summary of the Vulnerability

Even when running the server with:

python3 -m pyftpdlib --write

anonymous users are not supposed to overwrite existing files unless explicitly permitted.
However, due to insufficient permission checks inside RNFR/RNTO, anonymous users can:

upload any temporary file

rename it into an existing file

overwrite files owned by root or other users

This bypasses normal write restrictions and results in privilege-bypass file modification.

🧪 Steps to Reproduce

Start pyftpdlib:

python3 -m pyftpdlib --write

Connect as anonymous:

ftp 127.0.0.1 2121
Name: anonymous

Upload and overwrite:

ftp> put temp.txt
ftp> rename temp.txt existing_file.txt
250 Renaming ok.

Result:
The anonymous user overwrites existing_file.txt, regardless of ownership or permissions.

This also works even when the overwritten file is originally owned by:

root:root

other privileged users

files pre-existing in the FTP root before startup

🎯 Security Impact

This allows an unauthenticated attacker to:

tamper with files served by other processes

plant malicious data

replace configuration files inside the FTP root

perform persistence (e.g., replace .sh, .txt, or other consumed files)

cause denial of service

This bypass happens because RNFR/RNTO currently does not validate target file permissions.

The --write flag enables upload, but not overwrite of arbitrary existing files.

This is a classical insufficient authorization / file overwrite vulnerability, similar to:

CWE-22 (path traversal)

CWE-59 (TOCTOU by rename)

CWE-73 (improper file overwrite)

🛡 Expected Behavior

Anonymous users should not be able to overwrite existing files unless explicitly configured via:

dedicated permission flags, or

custom authorizer rules

🚫 Actual Behavior

Anonymous users can overwrite any existing file as long as they can upload a temporary file first.

This constitutes a permission-bypass file overwrite vulnerability.

🧷 Why this is not only “opt-in behavior”

While --write is indeed opt-in, administrators generally interpret “write” as:

allow upload of new files

but not:

allow overwriting of pre-existing privileged files

No documentation warns that enabling --write allows RNFR/RNTO overwrite.

This gap creates a real-world vulnerability because many users launch pyftpdlib using the README examples.

📝 CVE Request

Since this is a privilege-bypass file overwrite issue with real impact,
I would like to ask:

Would you consider assigning a CVE ID for this vulnerability?

If you agree, I can prepare:

Full technical write-up

PoC

Affected versions

CVSS scoring proposal

Patch suggestion

I’m happy to collaborate in the coordinated disclosure process.

Thank you again for maintaining pyftpdlib — it’s an excellent project.
I appreciate your time and look forward to your thoughts.

[giampaolo]

Ni hao @ZhangFsn.

it is a functional security vulnerability that allows anonymous users to overwrite privileged files via RNFR/RNTO, even when normal write paths should prevent it

Note that the FTPd process runs with the same permissions of the user launching it, so you won't be able to write/rename files owned by root or another user. You'll just be able to operate on files of that user.

Also, I see RNFR/RNTO no different than STOR. They are both write operations, and the --write flag covers both of them (and also MKD, DELE, etc.). You are already able to overwrite existing files with STOR, so RNFR/RNTO is no different, really.

Finally, note that the FTP server locks you in a chroot-ed filesystem. E.g. if you're launching the FTPd from your home directory (/home/zhang), that's gonna be your chroot, meaning you won't be able to operate on paths outside of /home/zhang/*. When you LIST files in your home, the FTP will present /home/zhang as /.