Security

New in version 54, FluentFTP introduces a secure path sanitizer to protect against FTP command injection, traversal, encoding bypasses, and parser confusion attacks.

It is a mandatory feature and cannot be disabled for the protection of your application/server. If you feel certain security features are overtuned and wish to have them turned off, submit an issue and we will look into it.

The exact policies used by FluentFTP APIs are documented below.

Background

TLDR: FTP commands can contain attack-sequences which can executed unintended commands on your FTP server. A new feature in FluentFTP protects against such attacks, using a process called "sanitization".

In FTP, file paths and file names are inserted directly into the plaintext FTP commands. If those values come from outside your code such as from user interface or an external file, they cannot be trusted. Without proper sanitization, the client can end up sending unintended commands which can end up attacking your FTP server.

Attackers can abuse this in simple ways. Newline characters can terminate one command and start another. Encoded values can hide dangerous input. Path traversal can move operations outside the intended directory. These inputs do not look harmful at first glance and can pass basic checks.

The client is often the place where these values are assembled. That makes it responsible for enforcing safe input. Relying on the server alone is not enough. The client may talk to different servers with different levels of validation. It may also be used in scripts, automation, or integrations where input is not controlled.

Developers should care because the impact is direct. A bad path can lead to file deletion, overwrite, or access to unintended locations. These issues are easy to introduce and hard to detect later.

Sanitizing FTP paths at the FTP client level is a simple way to prevent this entire class of problems, which is why FluentFTP has introduced these security measures.

FTP Path Policy

The following policy applies to the majority of APIs:

1. You cannot use directory traversal commands in FTP file paths (like /../../myFolder/myFile.txt), if you do it will be converted to the current directory (like /myFolder/myFile.txt)
2. You cannot use sensitive unix-terminal characters in FTP file paths (;,|,&)
3. You cannot use ASCII control chars in FTP file paths (\0 and 0-32 ASCII)
4. You cannot send multiline FTP paths to any API function
5. You CAN use URL-encoded characters in FTP file paths, however they will be decoded and sent to the server
6. You CAN use any slash (forward slash/backslash) in FTP file paths, however they will be normalized
7. You CAN use whitespace around FTP file paths (like myFile.txt ), however it will be trimmed
8. You CAN use whitespace in FTP file names, it will be preserved (like My File.txt)

Applies to the following APIs:

1. FileExists
2. DeleteFile
3. MoveFile
4. CompareFile
5. TransferFile
6. DirectoryExists
7. CreateDirectory
8. DeleteDirectory
9. EmptyDirectory
10. MoveDirectory
11. TransferDirectory
12. DownloadBytes
13. DownloadDirectory
14. DownloadFile
15. DownloadStream
16. UploadBytes
17. UploadDirectory
18. UploadFiles
19. UploadStream
20. GetChecksum
21. GetFilePermissions
22. GetFileSize
23. GetListing
24. GetModifiedTime
25. GetNameListing
26. GetObjectInfo
27. SetFilePermissions
28. SetModifiedTime
29. SetWorkingDirectory
30. Rename
31. OpenAppend
32. OpenRead
33. OpenWrite

FTP Command Policy

The following policy only applies to the Execute API:

1. You cannot send multiple commands by using multiple lines in a single Execute call
2. You CAN use sensitive unix-terminal characters, ASCII control chars in custom commands
3. You CAN use URL-encoded characters in custom commands

Security Features

Following is a list of FTP attacks and the means FluentFTP uses to protect against it.

1. Prevents command injection via CRLF or control chars

   • Attackers can inject newlines to break the FTP command and append a new one (e.g. DELE file)
   • This strips those characters -> stops command chaining completely

2. Neutralizes encoded attacks (double-encoding bypass)

   • Payloads like %0D%0A or %2E%2E hide malicious input
   • Decoding first ensures these are revealed and then sanitized, not bypassed

3. Blocks directory traversal (..)

   • Prevents escaping intended directories (e.g. accessing parent folders)
   • Stops attacks like ../../etc/passwd on FTP servers

4. Eliminates path confusion tricks (slashes)

   • Mixed or repeated slashes (\\, //) can bypass naive checks
   • Normalizing ensures validation is applied to a consistent path format

5. Prevents Unicode-based spoofing attacks

   • Invisible/control Unicode chars can make paths look safe but behave differently
   • Removing them stops deception and parsing inconsistencies

6. Avoids injection via whitespace manipulation

   • Leading/trailing spaces can break parsing or be used to hide payloads
   • Trimming ensures no ambiguity in how the path is interpreted

7. Prevents malformed path exploitation

   • Collapsing redundant separators and cleaning structure avoids edge-case parser bugs
   • Reduces attack surface from weird-but-valid path formats

8. Ensures consistent post-sanitization state

   • Re-normalizing after decoding closes gaps where decoding reintroduces unsafe patterns
   • Prevents sanitize -> decode -> exploit bypass chains

9. Fail-safe fallback to root (/)

   • If input becomes invalid/empty after cleaning -> defaults to /
   • Avoids undefined behavior or accidental execution on unintended paths