Fortra GoAnywhere MFT SFTP Login Limit Bypass Enables SSH Key Brute Force

The login limit is not enforced on the SFTP service of Fortra's GoAnywhere MFT prior to 7.10.0 if the Web User attempting to be logged in to is configured to log in with an SSH Key, making the SSH key vulnerable to being guessed via Brute Force.

• Fortra GoAnywhere MFT: affected in versions less than 7.10.0 when the Web User is configured to log in with an SSH Key.
• The normalized record lists the product default status as unaffected while identifying the version range less than 7.10.0 as affected under the stated configuration condition.
• The record does not separately enumerate later or parallel release branches, so their status should be verified with Fortra.

The weakness is classified as CWE-307, improper restriction of excessive authentication attempts. The defect is in login-limit enforcement for the SFTP service when the target Web User is configured to log in with an SSH Key. The attacker-controlled input is a sequence of SSH authentication attempts and candidate values used to guess the key. The supplied attack characteristics indicate that the service can be reached over the network without prior privileges or user interaction. The required condition is that the targeted Web User uses SSH Key login. The record does not disclose the precise implementation path, intended rate threshold, or key representation involved.

• Reachability: The issue is reachable through the SFTP service over a network.
• Authentication and interaction: The supplied record indicates that no prior privileges or user interaction are required.
• Condition: The targeted Web User must be configured to log in with an SSH Key.
• Complexity: Missing login-limit enforcement permits repeated key-guessing attempts without the intended restriction.
• Exploitation status: The supplied record does not establish that the issue has been exploited in the wild. It also does not identify a public exploit; that does not prove that exploitation has not occurred.

If the SSH key is successfully guessed, an attacker may gain access to the associated Web User and perform actions permitted to that account. Possible consequences include data disclosure, unauthorized file modification or deletion, and disruption of file-transfer processes, depending on account permissions. The record does not establish administrative privilege escalation, compromise of the underlying host, or automatic access to other accounts. The practical scope is therefore determined by the account's permissions and the exposure of the SFTP service.

• A successful SSH-key guess could enable unauthorized access to the associated SFTP Web User.
• Depending on the account's permissions, transferred data could be read, modified, or deleted without authorization.
• Unauthorized logins and actions could also disrupt file-transfer workflows or consume service resources.
• The practical impact depends on each Web User's permissions, the data accessible through the account, and the network exposure of the SFTP service.

1. Upgrade deployments in the affected range to 7.10.0, the version boundary identified by the affected-version data, or to another release that Fortra confirms is patched for the relevant release branch.
2. Before and after the upgrade, inventory Web Users that use SSH Key login and identify accounts with access to sensitive data or permissions to write or delete files.
3. Verify the post-update version and recheck the SFTP configuration of affected Web Users.
4. The supplied record provides upgrade guidance but no vendor-specific temporary mitigation. Do not treat unconfirmed configuration changes as a replacement for the patch.

1. Inventory Fortra GoAnywhere MFT instances and SFTP endpoints that are exposed publicly or reachable from untrusted networks.
2. Check deployed versions against the affected range in the record.
3. Identify Web Users configured for SSH Key login, especially accounts with permission to read, write, or delete files.
4. Review available SFTP authentication telemetry for repeated failed attempts against those accounts. Repeated failures are a precautionary signal for investigation, not a vendor-confirmed indicator of compromise.
5. After updating, verify the deployed version and recheck the login configuration of affected Web Users.